Hidden in the code that I uploaded to the CodePlex in our last post was a technique for doing automatic checking on a build. I wanted to share a little about that technique.
Thus far we have been using the GUI version of FxCop. While a great tool for browsing the results, it is not appropriate for an automatic build. Thankfully, Microsoft provides a second FxCop executable: a command line version FxCopCmd.exe.
This command line FxCop obviously takes all of its input on the command line, it automatically performs the analysis, and outputs the results as text, again on the command line. The text output may either as plain text, or XML with an XSLT transformation applied.
For the automatic checking, I used the following command line as a post build step:
if "$(ConfigurationName)" NEQ "Ship" "C:\Program Files\Microsoft FxCop 1.35\FxCopCmd.exe" /console /project:"$(ProjectDir)$(SolutionName)_$(ConfigurationName).FxCop"
The first part of the command line is a check for which project configuration we are building. You’ll recall in Part 3, we added a third configuration to the two standard configurations of Debug and Release: Ship. The Ship configuration is set up just like Release, but without any code verification support. Therefore there is no sense in running FxCop on it.
This additional configuration was necessary so that we could do analysis on code both in #if DEBUG blocks and not. As a matter of principle, we should not add any code that would only be compiled into only the Ship build. It will not be analyzed by FxCop at all!
The next part of the command line, after the actual invocation of FxCop, we identify that we want plain text output with the /console switch, and finally we specify the project file we want to process with the /project switch. The FxCop project name also incorporates the configuration name. This allows us to have separate FxCop projects for both the Debug and Release configurations.
Now, because we are focused on XNA, we must use Visual C# Express Edition, which only has a fairly limited build system. We could add a FxCop command to every configuration of every project, but that poses several problems. The first is that FxCop is not exactly fast. Each FxCop invocation is generally slower than the rest of the build process combined. Secondly, we’d like to have a single CustomDictionary.xml, so all of the FxCop project files should live in the same directory as that file, which means our FxCop project files cannot be added to their corresponding Visual C# 2005 projects. (All project files have a root directory, and the files in the project are relative to that root, with no “..” support.)
To rectify the situation, I added another Visual C# project. This project has a single dummy source file that is built, but does not contain any code that is used. This project is also dependant on all of the projects for the modules of our game, so it builds last, and it contains the FxCop command line above as it’s post-build step. This Visual C# Express Edition project also has both of the FxCop project files (again, on for Debug and one for Release) in it as well. This solves both of the problems. We can keep our single CustomDictionary.xml (also in the Visual C# Express Edition project) and we run FxCop last, and only once. We can also keep all of our custom settings in each of the FxCop project files. That’s our automatic FxCop checking on build.
Now, as a matter of process, I prefer using the GUI FxCop to track down all of the initial issues. The automatic checking is useful to insure that once you’re clean, you stay clean.
That covers the basics of FxCop. Now, if I can only get my desktop fixed and run some XNA code, I’d like to cover some other topics.
OE
