Wednesday, May 28, 2008

Hudson adds support for StyleCop

Last week Microsoft released StyleCop (aka Microsoft Source Analysis for C#), a tool that analyzes C# code and enforces a certain code style (similar to Checkstyle). The tool will go through all C# source files and mark the code style violations. Now Hudson (a Continuous Integration server) together with the Violations plugin has added support for parsing the StyleCop XML report and display the results for every build.

The Violations plugin displays a trend graph over builds so it is real easy to see that your project is progressing in the right direction (decreasing the number of violations). As you can see the plugin also supports FxCop reports.

Each build will display a listing of the files that are violating the code style, and it is also possible to see the number of fixed (or introduced) violations for every build.

Clicking on a file will display excerpts from the C# code showing the violations.

Follow the guideline here after downloading StyleCop. Add the <Import Project="$(ProgramFiles)\MSBuild\Microsoft\SourceAnalysis\v4.2\Microsoft.SourceAnalysis.targets" /> to every csproj file that you are building within Hudson. When the VS project is built, StyleCop will store a file named StyleCopViolations.xml [Update, if you are using StyleCop 4.2 enter SourceAnalysisViolations.xml in the project folder. As of now, there is no way to store it elsewhere. The XML file contains all violations that were found in the Visual Studio project.

Hudson Configuration
To configure the violations plugin, enable the "Report violations" check box. If there are several VS projects in the build, you should use **/*/SourceAnalysisViolations.xml as it will find XML files in all sub folders.

After configuration, start a new build to analyze and display the StyleCop results in Hudson. To see a trend graph you need at least two successful builds.

  • Do not enable all rules, choose those that are valid for your organization and make sense for you.
  • Do not activate too many rules at first, as it probably will generate too many violations. Too many violations may be ignored by your co-workers, as it seems to be too much work to fix them all. When the most critical code style violations has been fixed, increase the number of rules.