Get started using FxCop against your nightly build without first resolving all the violations

FxCop is one of the best known free static code analysis tools available for .NET software. Version 10.0 of FxCop was published in June of 2010 and is available for download here). FxCop is easy to install and use to analyse your code for potential problems, but I think the real value of FxCop is when you run it every night against your nightly build and receive a report via email of new violations recently introduced in your code. I have long believed this to be the best use and value of FxCop, but only recently implemented it. And the reason I only recently implemented nightly scans of our code using FxCop is because when I run the tool I get a report with thousands of violations. Ouch! Are all these violations things I really need to fix? The answer for me, and likely the answer for you, is no. However, a lot of the violations should be fixed.

I think of the violations in these groups:

• Violations like misspelled words that are not misspelled, but just need to be added to a custom dictionary so that they are no longer flagged as violations.
• Violations that could, and would, cause problems if that bit of code was ever used in ways others than intended, but I know that won’t happen.
• Violations that would be problems if the software runs in other countries using different languages, different date/time formatting, etc.
• Violations that really are problems we should fix.
• Violations that represent waste such as methods that are never called.

So, as I stated we have thousands of violations across all of our code, but I didn’t want to implement the nightly FxCop scan until all of those were resolved. If you look at the categories I used for the problems, many of the violations are not worth our time to resolve because we have more valuable work to do right now. So how could we begin using FxCop regularly, without fixing all the problems? We did it by disabling rule checking for all the rules that were currently failing. Then we set up the automated job to run FxCop every night against our compiled assemblies. Doing it this way gives us a starting point, and it keeps us from violating many of the rules defined in FxCop. Our next step is to begin turning on rules and fixing them one by one. Of course, we will start with the important or easy violations and work our way down the list until we have them all re-enabled.

From a high-level perspective, you have to perform just two steps:

1. Build your FxCop project files that analyze your assemblies and ignore failing rules.
2. Build your nightly batch job to run against all the assemblies and email results to you.

Some tips before you begin:

• Tip #1 – Use the same directory path for the DLLs you analyze with FxCop on both your developer PCs and your build machine. FxCop stores the path to the DLLs you select in the .FxCop configuration file. If the path is the same between your developer PC and the build PC, then you can easily configure FxCop on your PC and it will run without modification on the build computer.
• Tip #2 – Do not plan to use one .FxCop project to scan all your assemblies unless you have just 10 or 20 assemblies. At some point, .FxCop fails to work when too many assemblies are loaded.
• Tip #3 – FxCop does not work on Silverlight projects.

Here are the steps I recommend:

• Step #1 – Add all the assemblies for your logical group into the .FxCop project and analyze them. Logically group the DLLs and executables you analyze.
• Step #2 – Copy the CustomDictionary.xml file provided by FxCop into the folder with your FxCop projects, modify the CustomDictionary to recognize some of your acronyms and names as valid – not violations.
• Step #3 – Sort the results of the analysis by Rule, then from the Rules tab, go through and deselect all the rules that you have violations for. Save the .FxCop project file.
• Step #4-n – Use the .FxCop file you saved as the starting point for the next group of assemblies you desire to analyze (save it with a different name of course). Exclude all the targets from the first analysis and add your new set of targets.
• Step #5 – We use nant in our nightly processes, and nant includes a task specifically for running FxCop. Here is how we do it. Create a batch file to run nant:

  cd\
  cd\dev\fxcop
  REM This next line appends the FxCop directory to the existing path 
  so we can run FxCop from any folder
  PATH %path%;c:\program files\microsoft fxcop 10.0
  C:\WINDOWS\system32\nant.bat fxcop -logger:NAnt.Core.MailLogger

• Step #6 – Configure an nant .build file for executing FxCop. Ours looks something like this:
  XML

  <?xml version="1.0" encoding="utf-8" ?>
  <project name="FXCOP" default="build"  
  xmlns="http://nant.sourceforge.net/release/0.86-beta1/nant.xsd">
      <property name="MailLogger.mailhost" value="smtp.ourdomain.com" />
      <property name="MailLogger.from" value="build@ourdomain.com" />
      <property name="MailLogger.success.notify" value="true" />
      <property name="MailLogger.success.to" value="developers@ourdomain.com" />
      <property name="MailLogger.failure.to" value="developers@ourdomain.com" />
      <property name="MailLogger.success.subject" value="FXCop Violations" />
      <property name="MailLogger.failure.subject" value="FXCop Build Failure" />
      <property name="MailLogger.success.attachments" 
          value="MailLogger.success.files" />
  
      <fileset id="MailLogger.success.files">
          <include name="ProjectGroup1.html" />
          <include name="ProjectGroup2.html" />
      </fileset>
  
      <!-- this loads any required dependencies that 
      nAnt needs to do all of our tasks-->
      <loadtasks assembly="C:\Program Files\nAnt\
      Contrib\bin\NAnt.Contrib.Tasks.dll" />
  <target name="fxcop">
      <fxcop analysisReportFilename="ProjectGroup1.html" 
      applyOutXsl="true" includeSummaryReport="true" 
      projectFile="MinimalRulesGroup1.FxCop"/>
      <fxcop analysisReportFilename="ProjectGroup2.html" 
      applyOutXsl="true" includeSummaryReport="true" 
      projectFile="MinimalRulesGroup2.FxCop"/>
  </target>
  </project>

• Step #7 – Over time, enable rules in FxCop and resolve the violations that arise. Eventually, hopefully, you will be able to get all of your code to pass all FxCop rules.

On a final note, I’d like to make sure you are aware that you can also write your own FxCop rules to ensure the code your team is written follows your shop standards.