Static code analysis is a valuable tool to find many errors in your code. What is static code analysis? It’s a process to analyze the code or assemblies themselves rather than testing the application by running the code. Hence, the analysis is static. There are a couple of free tools that allow you to do static code analysis on .Net code. The first, FxCop analyzes the generated assemblies. It checks assemblies for correctness, library design, internationalization and localization, naming conventions, performance, and security issues. The second tool, StyleCop analyzes that actual source code. I’ll discuss it in a future post.
To get FxCop, you need to download and install the Windows SDK. Once that is done, run %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FXCop\FxCopSetup.exe to install FxCop. You should do this on both your development machine and your build server. You’ll now have an FxCop entry on your start menu. Use it to launch the FxCop GUI.
I won’t go into how to use FxCop or interpret the results. This is will docmented in the FxCop help file and also here and here. You should create a new FxCop project for each Visual Studio solution that you analyze. You should save the FxCop project file with your solution and check it into version control. We put it in the same folder as the Visual Studio solution file.
We also set a few FxCop project options. To so this, right-click on the FxCop project and select Properties.
On the General page, you should enter the name of your project. This keeps things need and tidy. You may be tempted to check Apply style sheet when saving report. However, when you check this option, it will cause TeamCity to not include the analysis report in its HTML output. You can still get to the report, but it will be presented as raw XML.
The next settings we made are on the Spelling & Analysis page. We checked all the options.
Next you need to select the Targets to add. These are the assemblies generated when you build the solution. There is no need to include Microsoft and third-party assemblies. That will generate too much clutter in your results. Just select the assemblies generated as part of your code. Remember that the location of the assemblies may be different on the build server than on your development machine. For example, our build process does not generate a Debug version, only Release. If you create MVC applications, you can point to the assemblies in the Bin folder. Because this location is saved with the FxCop project, you need to save a location that’s avalailable on the build server. The location saved is relative to the FxCop project file.
When you have everything working, make sure to save your FxCop project file and then check it into your version control system. Now it’s time to setup Team City to run the analysis.
You probably don’t want to run code analysis with every build, especially if you are doing Continuous Integration (CI) with every checkin. Static code analysis is a good candidate for your nightly build. It should also run only after the build successfully completes and unit tests pass.
Modify the TeamCity project and add a build step. Here’s how we have things setup.
The Installation root is where FxCop was installed on the build server. We are using the FxCop project file because this makes it easier to manage. The developer is responsible for their Visual Studio project and by referencing the FxCop project, we don’t have to modify the TeamCity project when assemblies are added.
Now when you run the build in TeamCity, you’ll get FxCop results as part of the build. The TeamCity home page reports the results. When you drill-down into the Code Analysis, you’ll find a complete list of issues that were found.
And there you have it. The basics of running FxCop as part of your TeamCity CI process.