Game Development Reference
In-Depth Information
For an extremely simple yet practical example, we will make a custom FxCop rule
that requires all namespaces to be prefixed with Nexus.WorldBuilder .
We need to start by creating an XML file in the project that will eventually be com-
piled as an embedded resource during the build process. This file defines all the
rules that FxCop will load, including configuration and resolution information. It
is here that you can set the warning level, description, and resolution for each rule.
The name of the file at this point is fairly flexible.
<?xml version=”1.0” encoding=”utf-8” ?>
<Rule TypeName=”NamespacePrefix” Category=”Nexus.Naming” CheckId=”NX0001”>
<Owner>Graham Wihlidal</Owner>
<Name>Namespaces must be prefixed with Nexus.WorldBuilder</Name>
<MessageLevel Certainty=”95”>Error</MessageLevel>
<Description>All namespaces should be prefixed with Nexus.WorldBuilder
for consistency</Description>
<LongDescription>All namespaces should be prefixed with Nexus.WorldBuilder
for consistency</LongDescription>
<Resolution Name=”Default”>The namespace '{0}' is not prefixed with
You must set the Build Action property to Embedded Resource so that this XML file
will be embedded in the rule assembly file; otherwise FxCop will not be able to
find it and will report that there are no rules to load.
The best approach to structuring the code for a rules assembly is creating a base
rule from which other rules can inherit. This is because there are a few arguments
that must be repeated for each rule, and proper class design urges the normaliza-
tion of repeating data.
Here is the code for the base rule class:
using System;
using Microsoft.Cci;
using Microsoft.Tools.FxCop.Sdk;
using Microsoft.Tools.FxCop.Sdk.Introspection;
Search Nedrilad ::

Custom Search