Using VS2010 integrated fxcop in continuous integration

In our projects we heavily rely on the Microsoft FxCop engine. FxCop prevents us from making stupid programming mistakes like forgetting to dispose a disposable object etc. For a long time we used the FxCop engine 10.0 which has a command line integration for continuous integration environments. Lately we discovered that the VS2010 integrated FxCop has a much stronger analysis engine and more rule sets which could improve our code base even further. But how do you get the VS2010 integrated fxcop running on continuous integration without having to install VS2010 on the build machine? I’ll show you how!

For the steps described in this tutorial I’m assuming you are familiar with the following tools:

  • NAnt
  • MsBuild

I’m also assuming that you have the following project structure:

-- scripts
    -- your nant scripts
-- sources
    -- your source files
-- tools
    -- NAnt
    -- etc.

First we need all the files to be able to run the integrated fxcop.

  1. Create a new folder “FxCop” under tools (from now on I call this folder FXCOPDIR)
  2. Copy all files and folders from %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop to FXCOPDIR
  3. Copy all files and folders (except *.pdb) from %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\DIA SDK\bin to FXCOPDIR
  4. Create a new folder “MsBuild” under FXCOPDIR (from now on I call this folder FXCOPMSBUILDDIR)
  5. Copy all files from %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis to FXCOPMSBUILDDIR
  6. Copy file “Microsoft.VisualStudio.CodeAnalysis.Sdk.dll” from C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.CodeAnalysis.Sdk\v4.0_10.0.0.0__b03f5f7f11d50a3a to FXCOPMSBUILDDIR

The final folder structure should look like:

Then create in your sources directory a rule set file. You should name it after your project and the file extension should be .ruleset. The content must contain a hint path to the rules.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="" Description="" ToolsVersion="10.0">

This tells msbuild where to look for the fxcop executable. Checkin all the required files into your VCS and you are set. When you compile your solution with NAnt and msbuild.exe the MSBuild will automatically use the fxcop in your tools folder! But you need to make sure that you use msbuild.exe directly and not the CSC task from NAnt. An example could look like:

    <property name="msBuild.exe" value="${framework::get-framework-directory('net-4.0')}/msbuild.exe" />
	<exec program="${msBuild.exe}" failonerror="true">
	  <arg value="${sources}/${}.sln"/>
    <echo message="Completed compilation of solutions" />

Attention: The NAnt script above is not complete and not meant for production.

Word to the wise

Code analysis really slows down your build process. You should have separate build configurations with and without code analysis enabled. For exampe in our project we have a special “Debug with Code Analysis” build configuration which enables the developer to quickly check if there are FxCop rule violations in his code. The normal debug configuration does not do code analysis.

Be aware of

You also need to make sure that you are compliant to microsoft license agreements. I have not checked whether copying the internal fxcop engine is a copyright infrightment. I think for internal purpose as long as you don’t deploy it and when you have valid MSDN subscriptions license this is OK. But I will not take responsibility for that. You do and use it at your own risk!

About the author

Daniel Marbach


  • Hi Dani

    That is great to hear, that you’re using code analysis and push it continuously further. The new engine is called Phoenix and only the DFA rules (I haven’t figured out yet what DFA means) are related to the new engine. It costs you about twice the code analysis time as without the DFA rules. As you pointed out, the rules shall be run occasionally with their own settings.

    Unfortunately the code analysis comes only with the Premium and Ultimate editions of Visual Studio 2010; I currently have only Professional edition :(.

    Details see here

    Keep it up!

  • In the project file, you can dfinee a custom variable in the PropertyGroup section for each build configuration. Just add a tag such as C:\Windows\Microsoft.NET\Framework64 and then use the macro to dfinee the reference path:You can dfinee MyCustomPath to a different location for different build configurations (platform and/or debug/release). The problem would not exist if MS would support this in the VS UI, but until then this will work. I use this technique to reference different versions of the same assemblies in my debug & release builds. Works great!

By Daniel Marbach

Recent Posts