Custom rules for Code Analysis feature in 2010

Initially we were using FxCop for code analysis i.e, coding standards, best practices, etc.

Thanks to MS!! Now Team Foundation Server's check-in policies can be an excellent solution for this kind of scenario. One of the policies TFS ships with out of the box is the "Code Analysis Check-In policy", which runs your Code Analysis rules every time someone attempts to check-in code. If the rules fail, the check-in does not succeed. (For those of you that haven't heard of Code Analysis, it is basically FxCop integrated into Visual Studio, version 2005 onwards).

So one of the things we had to do to enforce our own  rules not already covered by FxCop/Code Analysis. It turns out that this is a relatively easy task with FxCop 1.36, which provides a new API called Introspection to perform the code analysis.

One important detail is that FxCop works against compiled Intermediate Language. This means that a huge advantage is that the rules are not dependant on the language of your code, as long that it targets the .NET Framework.
Enough for the introduction, let's go to the coding and create a simple rule: private varible should start with "_" and first letter should small in caps like "private string _studentID".

The steps involved to implement such a rule are:

1) Create a new C# class library project and add references to Microsoft.FxCop.Sdk.dll and       Microsoft.CCi.dll. Both come with FxCop.
You can find these refrence at (\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop)

2) Add an xml file, which will contain the description about your rules; the name of the file is not important. This information will be used by FxCop/Code Analysis to show your rule on the UI. It will have the following structure:

Most of the information here is pretty self-explanatory, with exception of the Resolution field, wich I will cover later.

3) Add a class to your project, and make it inherit from BaseIntrospectionRule. You should add a parameterless contstructor to your class, but that calls a base constructor and provides three parameters:
a) Name: name of the rule, must match the TypeName specified in the rule metadata XML.
b)Xml config: the name of the metadata XML resource. It is the name of the assembly plus the name of the xml created on step 2 but without the extension.

c)Xml assembly: the assembly containing the metadata XML resource.

When the analysis is run, this method gets called by the runtime every time a type is found (such as a class, delegate, enum, struct or interface). If you are interested in checking other elements, such as methods, there are other overloads of the Check method that you can override.

When a rule violation is found, we must add a Problem to the Problem collection inherited from the base rule class. We must supply a Resolution object to the problem constructor. This object just builds the description that will be shown to the developer about how to fix the rule violation. Remember that in the config xml we supplied the description and placed a positional placeholder such as the one's used in String.Format?

Well, in the Resolution constructor we are supplying the parameters to fill the placeholders, in our rule we are passing-in the private variable's name.

Multiple resolutions can be defined which are assigned with a Name attribute in the xml and then accessed by code with the this.GetResolutionByName() method.

4)The last step is to build the assembly and copy it to c:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules. In case that you are using FxCop standalone exe, copy the dll to C:\Program Files\Microsoft FxCop 1.36\Rules.

And that's it. Open the tool (Visual Studio Code Analysis or FxCop), and you will see your newly defined rule.

Enjoy!!!

for any suggestion write on k.manojt1@gmail.com.