Create your own custom rules

Create your own custom rules:

The first step in creating a custom FxCop rule is creating a Visual Studio project for the assembly that will contain the rule (assuming, of course, that such a project doesn't already exist for hosting existing custom rules). This project should generally be a plain-vanilla library project. Since you're presumably something of a quality nut if you're bothering to create custom FxCop rules, you'll presumably want to verify that the following options are set for all configurations of your project:

· The warning level is set to 4.

· No warnings are excluded.

· Warnings are treated as errors.

· XML documentation output is enabled.

If you're using a Visual Studio edition that supports static analysis, analysis should be enabled, and all rules should be set to generate errors rather than warnings.

FxCop rules are organized into DLL assemblies (which can be created as Class Library projects in Visual Studio).Each assembly, when loaded into FxCop, displays its rules in the GUI as leaf nodes in a hierarchical tree.Each rule assembly should directly reference two assemblies provided with FxCop. These two assemblies are located in the Program Files\Microsoft FxCop 1.36 folder:

· FxCopSdk.dll

· Microsoft.Cci.dll

The only namespace that needs to be imported to use the API is Microsoft.FxCop.Sdk.

Visual Studio Team System: To add a custom rule assembly to Visual Studio Code Analysis, copy the DLL to c: \Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules, where c:\ reflects the drive where Visual Studio is installed.

To create Custom rule your project should contain following three files – (Third file is optional)

1) Rule metadata xml file

2) Base rule file

3) Actual rule file (Optional-you can implement the rule in base rule also)

1) Rule Metadata XML

Each rule assembly contains an XML resource defining metadata for all of the rules in the assembly. In Visual Studio,the addition of this resource to your project can be accomplished by adding an XML file and then marking the file as an "Embedded Resource" in the Visual Studio properties window.

FriendlyName The display name of the rule library as it will appear in the FxCop GUI rules tree.

TypeName The name of the .NET class that implements the rule. Do not qualify with a namespace.

Category The category of the rule. This should generally be a programmatic version of FriendlyName.

CheckId An identifier that distinguishes the rule from all others in the same Category.

The display name of your rule as it will appear in the leaf level of the FxCop GUI rules tree.

Description A description of your rule.

Url A URL associated with the rule that can be used to provide even more information about thee rule.

Resolution A short suggestion on how to fix the violation. It may contain String.

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.

Email An email address to be associated with the rule for display to the user.

OwnerThe person who "owns" the rule for display to the user. Often left empty.

2) Base rule file

The base rule implementation technique is to override suitable overload(s) of the BaseIntrospectionRule.Check method in order to add code that implements your rule verification logic.

For example

public abstract class BaseRule : BaseIntrospectionRule

{

protected BaseRule(string name):

base(name, "ProjectName.RuleMetadataXMLName", typeof(BaseRule).Assembly{}

}

In this BaseRule is inherited from BaseIntrospectionRule.The actual implemetor class of the rule passes name of the class itself which tells that it has actual implementation of rule. Also BaseRule class passes three parameters to BaseIntrospectionRule are name of the class which actualy implements the rule,name of metadata xml file which contains all the extra information about the rule and third is assebly information of BaseRule.You can implement actual rule here also.

3) Actual rule implementer file

This is optional.We should write actual implementation of rule because for simplicity and exendibility of number of rules.

Most FxCop rules start out by calling either the Check or VisitCall method. Then, once a rule violation has been determined, return a Problem or ProblemCollection after making a call to the GetResolution method to retrieve the rule information such as, message, resolution, certainty level, etc. from the XML file.

For example-

public class ActulImplementerClassOfRule : BaseRule

{

private const string FIELD_PREFIX = "_";

public ActulImplementerClassOfRule ()

: base("ActulImplementerClassOfRule") { }

public override TargetVisibilities TargetVisibility

{

get { return TargetVisibilities.NotExternallyVisible; }

}

public override ProblemCollection Check(Member member)

{

//logic to check member

//which not follows the rule

return Problems;

}

}