Ok I took upon myself to update an old sample I had for VSTS 2005 so it would run in the new VSTS 2008 since some things have changed such as the required assemblies and classes that are needed to build a custom code analsys rule for Team Developer.  Writing a custom code analysss rule is actually quite simple.  What makes it difficult is it is undocumented.  This will hopefully change in the Rosario time frame but until then hopefully this sample will get your going. 

You can download the source code here: http://www.codeplex.com/almspecialisttoolkit/Release/ProjectReleases.aspx?ReleaseId=14315

This sample is a very basic rule that checks for the word "pass" as a data member of a class (ignoring) case -- if it isn't obvious already it is simply trying to see you have a data member that could be construed as a password thus it will ask that you do something about it such as encrypt it.  Like I said simple! 

 

Your job is create new class for every rule and add it to the sample project I gave you.  I've already given you one called CustomSecurityRule.cs.  Once you have that you need to add the rule to a self describing xml file that will be an embedded resource in the assembly that will eventually be deployed to good ole VSTS 2008.

  

To add a new rule you add a rule element to the Rules.xml file as so....  This should be self explanatory once you open up the rules.xml file included in the project 

 

<?xml version="1.0" encoding="utf-8" ?>

<Rules FriendlyName="Custom Security Rule">

<Rule TypeName="PossiblePasswordDisclosure" Category="Custom" CheckId="JS0001">

<Name>Possible Password Disclosure</Name>

<Description>The field '{0}' in your application may be a password field and could be vulnerable to password disclosure if the value is visible and unencrypted.</Description>

<Url></Url>

<Resolution>If the field "'{0}'" is a password field, it should be protected through encryption and obfuscation.</Resolution>

<Resolution Name="Prefix">If the field "'{0}'" is a password field, it should be protected through encryption and obfuscation.</Resolution>

<MessageLevel Certainty="95">Error</MessageLevel>

<FixCategories>NonBreaking</FixCategories>

<Email></Email>

<Owner></Owner>

</Rule>

</Rules>

 Figure 1.1  Rules.xml file

 

Now you can create your rule in code.  See the example rule classes in the project for reference.  I've created a class called BaseRule that inherits from BaseIntrospectionRule that allows you to pass in a rule name either statically or through a constant.  You simply have to inherit your rule class from BaseRule such as the following:

 

public class PossiblePasswordDisclosure : BaseRule {

public PossiblePasswordDisclosure() : base("PossiblePasswordDisclosure") { }

public override ProblemCollection Check(Member m) {  

Field field = m as Field;

          if (field != null) {

string name = field.Name.Name;

          string uppername = name.ToUpper();

          if (uppername.IndexOf("PASS") != -1 ) {

                    Problems.Add(new Problem(GetResolution(name)));

                    return Problems;

                }

                else {

                    return null;

                 }

         }

            return null;          

  }

}

Figure 1.2  Rule Class

 

Next, figure out what scope the new rule applies to since it can apply to several different levels (e.g. Field, Property, Parameter, Method, etc.) 

For whatever levels your rule applies, override the appropriate Visit methods from the BaseIntrospectionRule class.  The BaseRule class extends the BaseIntrospectionRule class, which in turn extends another class in the FxCop framework.  There are over 140 Visit methods (we use the Check(Member m) method) that the base 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 allows you to focus on the part of the code you care about e.g. methods, or fields (such as our case), etc. 

 

Finally, 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 order to deploy the this rule, the CustomSecurityRule.dll file must be copied to the C:\Program Files\Microsoft Visual Studio 9\Team Tools\Static Analysis Tools\FxCop\Rules directory on each machine where the rules are to be run.  You can even have VStudio open when you deploy the rule - you simply need to re-open the project properties to see the rule in the rules list in the code analysis section.

 

Happy rule writing.....