Why create Custom Rules?
FxCop already contains a lot of inbuilt rules. Now the question arises why would we need to create custom rules? Simply put, we need to create our own custom rules in order to enforce our own standards. For example, we may want to follow a particular naming convention for controls, variables, namespaces, classes and so on. Hence the beauty of FxCop is that we are not limited to just the inbuilt rules but it allows us to define our own rules.
In the file named VariableNamingConvention.cs I have written a custom rule for the naming convention of variables. For example, integer variable should start with ‘i’, Boolean variables should start with ‘b’, object type variable should start with ‘obj’ and so on. Connection.xml is the rule description file.
Download:
VariableNamingConvention.cs
How to write custom rules?
The following are the steps required to create custom rules:
Step I: Create a new class library project in Visual Studio.
Step II: Add the following two references
• FxCop Sdk.dll
• Microsoft.Cci.dll
These two assemblies are located in the Program FilesMicrosoft FxCop 1.36 folder:
Also import the namespace Microsoft.FxCop .Sdk.
Step III: Create a class for a custom rule, thisclass should inherit from BaseIntrospectionRule class. (See BaseIntrospectionRule Class section).
Step IV: Override the Check method to implement custom rule’s logic. The code snippet for avoiding ToString() for string type object is available in the file AvoidToStringForString.cs . Other Check overloads are also available, for checking members, types, modules, etc. For any violation of a rule a new Problem is added to the Problems collection, and this collection is returned by the Check method. The GetResolution method is responsible for fetching a resolution from the rules xml file. (see Different overloaded check method section )
Step V: Add rule descriptor XML file as an embedded resource into the project. (See Screen shot below and Rule Descriptor File section)
Add custom rules into Visual Studio Code Analysis:
FxCop 1.36 will run under and analyze programs written for .NET Framework versions 2.0, 3.0, and 3.5.
To add a custom rule assembly to Visual Studio Code Analysis, copy the DLL to c:
Program FilesMicrosoft Visual Studio 9.0Team ToolsStatic Analysis Tools
FxCop Rules.( Visual Studio installation path).
The below screen shot shows the custom rule added in Code Analysis:
Different overloaded check method:
• Check (ModuleNode module):
This checks a .NET module (an assembly consists of one or more modules).
• Check (Resource resource):
This checks a resource (e.g., a Bitmap) defined in a module.
• Check (String namespaceName, TypeNodeCollection types):
This checks types in a namespace.
• Check (TypeNode type):
This checks a type (e.g., ClassNode, Struct, EnumNode etc.).
• Check (Member member):
This checks a member (e.g., a PropertyNode, Method, Field, or others).
• Check (Parameter parameter):
This checks a parameter for a member.
Rule Descriptor File:
Here is the sample of our rule descriptor file:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<Rules>
<Rule TypeName=”AvoidToStringForString” Category=”Dot Net” CheckId=”Rule1″>
<Name>ToString not req. for String object </Name>
<Description>ToString not req. for String object</Description>
<Owner> Sanjit</Owner>
<Url></Url>
<Resolution> Remove ToString </Resolution>
<Email></Email>
<MessageLevel Certainty=”99″> Warning</MessageLevel>
<FixCategories> Breaking </FixCategories>
</Rule>
</Rules>
The Rule tag may be repeated when there is more than one rule.
TypeName: The name of the .NET class that implements the rule.
Category : The category of the rule.
CheckId : An identifier that distinguishes the rule from all others in the same Category.
Name : The rule name which will appear in the FxCop GUI rules tree.
Description : A description of rule.
Owner : The person who “owns” the rule for display to the user. Often left empty.
Url : A URL associated with the rule to provide even more information about the
Rule as compared to Description. It can be left empty if not required.
Resolution : A short suggestion on how to fix the violation
Email :An email address to be associated with the rule for display to the user. Often left empty.
MessageLevel : The severity of the error: CriticalError, Error, CriticalWarning, or Warning.
Certainty : The certainty is an integer from 0 to 100 that indicates how often the rule typically detects
a real problem in the code. This tag is purely informational.
FixCategories : Characterizes the impact of fixing the rule: Breaking, NonBreaking, or DependsOnFix.
BaseIntrospectionRule Class:
Custom rules inherit from the BaseIntrospectionRule class. Its constructor takes three arguments:
public AvoidToStringForString()
: base(“AvoidToStringForString”, “CustomRules.XMLFile”, typeof(AvoidToStringForString).Assembly)
{ }
• The name of the rule, which is also same as the Type Name specified in the rule metadata XML.
• The name of the rule descriptor file.
• The assembly that contains the rule.
Debugging FxCop Rules
To debug custom rules, the following steps need to be followed (see screen shot VIII also):
· Run FxCop
· Open the FxCop custom rule .net project
· In Visual Studio Choose Debug -> Attach To Process(see below screen shot)
· Select FxCop .exe in the available process
· Click on Attach (see the below screen shot).
· In code behind put a break point in FxCop custom rule .net project
· In FxCop , click Analyze
Conclusion:
We have seen that FxCop not only has inbuilt rules but also allows us to implement custom rules to enforce our own standards. It provides a very useful rule violation report and also highlights the exact line of offending code making it a very user friendly tool. FxCop’s inbuilt rules and the option of adding custom rules along with user friendly rule violation report really make it an essential tool in today’s application development.
]]>