Building New Rules
The first step is to make sure there is not an already existing rule that is doing what you are trying to do!
Use the IK.CodeAnalysis.Rules solution to add new classes to the IK.CodeAnalysis.Rules project inside of the solution. Each new class will correspond to a new rule.
Add a new rule element to the Rules.xml file. Follow the examples from the rules that are already there.
Figure 1.1 Rules.xml file
All new classes must inherit from the BaseRule class. Make sure to add a private static class called “Constants” in the new Rule class. This is where the name of your rule as well as its resolution name will go. See the example rule classes in the project for reference.
Make sure that the Resolution element’s Name attribute is what you reference in the new Rule class as well as the Rule element’s TypeName attribute. These values should correspond to what both of the values are in the RuleName and ResolutionName constants in the private static Constants class of the new Rule. Feel free to put any other string literals into the Constants class.
Figure 1.2 The Constants class
Next, figure out what scope the new rule applies to; it may apply at several levels, such as Field, Property, Parameter, Method, etc. For whatever levels your rule applies, override the appropriate Visit methods from the BaseIntrospectionRule class.
The “Visit” Methods
The BaseRule class extends the BaseIntrospectionRule class, which in turn extends the StandardVisitor class. There are over 140 Visit methods that the StandardVisitor class calls during a rule check operation. What this means is that any Visit methods that are implemented in the new Rule class will be called by the rule framework. This is great because it allows rule developers to only focus on the parts of an assembly’s IL that they care about, such as all methods, or all private fields, etc. In order to trigger an error or warning to appear from a rule that has been broken, a call must be made to the BaseRule.AddProblem method.
In Figure 1.3, a call to AddProblem is made when a private field has been flagged as having a prefix in front of it.
Figure 1.3 An example of overriding the VisitField method
Debugging Rules
Follow the instructions outlined in #13 of the Resources section. In the IK.CodeAnalysis.Rules solution, there is a file named CommandLine.txt which contains a sample command line for debugging the custom rules in the solution. There is also an FxCop project file in the solution, fxcoptest.fxcop, which is necessary for debugging. In order to get debugging working, the rule developer will need to modify the paths referenced in both of these files to point to the correct locations on their machine. Once everything has been modified correctly, copy and paste the text from the CommandLine.txt file into a command-prompt window, and then run it.
Deploying Rules
In order to deploy the IK rules, the IK.CodeAnalysis.Rules.dll assembly file must be copied to the C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules directory on each machine where the rules are to be run. That’s it, Visual Studio will load up and process all of the assemblies in this directory.
Suppressing Rules
There are some cases where it will be necessary to allow a rule violation in your code. A typical example might be a rule violation that is more of a design suggestion, instead of an actual violation, such as having a “GetXYZ” method that returns a certain type. This will result in a rule violation stating that the method be changed to a property, but you may have a very good reason to keep it as a method. In those types of cases the rules can be suppressed, but should be suppressed in code using the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute attribute. Here is an example of what this looks like in code:
Figure 1.4 Suppressing a Rule
More information about this attribute can be found here.
Resources:
The very first resource any new rule developer should look at is #6 (Writing Custom FxCop Rules by Guy Smith-Ferrier) in the list below. This is a pdf version of a PowerPoint presentation that explains the process of building rules very well.
1. http://blogs.msdn.com/fxcop/archive/2006/11/16/faq-how-do-i-share-managed-code-analysis-rule-settings-over-multiple-projects-david-kean.aspx
2. http://blogs.msdn.com/fxcop/
3. http://www.gotdotnet.com/community/usersamples/default.aspx?ProductDropDownList=FxCop&SortDirection=Desc&SortColumnName=CreationDate
4. http://www.gotdotnet.com/team/fxcop/
5. http://blogs.msdn.com/fxcop/archive/2007/01/22/faq-what-exception-should-i-throw-instead-of-the-reserved-exceptions-found-by-donotraisereservedexceptiontypes.aspx
6. http://www.guysmithferrier.com/downloads/FxCop.pdf
7. http://davidkean.net/archive/2004/08/09/145.aspx
8. http://msdn.microsoft.com/msdnmag/issues/04/06/Bugslayer/
9. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1090172&SiteID=1
10. http://davidkean.net/articles/BaseRule.aspx
11. http://www.codeproject.com/cs/algorithms/Not_Used_Analysis.asp?df=100&forumid=332089&exp=0&select=1783417
12. http://dotnetjunkies.com/WebLog/tim.weaver/archive/2005/01/12/43651.aspx
13. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1090172&SiteID=1