CruiseControl.NET for Running Static Analysis – Part 1
Sunday, October 8, 2006 – 3:04 PMSo I’ve been playing around with CruiseControl.NET this week. What I’d like it to do is run a bunch more static analysis tools in background on my machine. We have some similar tools at Microsoft for doing static analysis on developer machines so the code is constantly checked. This allows you to catch some errors during coding rather than on your continuous integration server after they’ve been checked in. The nice thing about this is that it doesn’t get in the way of the frequent recompilations that happen when doing TDD.
Sure, I could create another solution configuration that runs all these additional steps as part of a build but using CruiseControl.NET to do this automatically means I don’t have to remember to do it and I can reuse the same setup on the real integration machine – defense in depth. I’m planning to add some more tools over time and log the results so I can track long term changes in the codebase. This is just a first step.
The first tools I wanted to try and hook up were FxCop and CCMetrics. They’re pretty straightforward and lightweight. FxCop is covered in the documentation that comes with CruiseControl.NET. Here’s how I got CCMetrics hooked up…
Getting CCMetrics to run from CruiseControl.NET
All you really need to do is configure CCMetrics to run as part of your build and merge it into the reports. This involves setting up MSBuild and getting CCMetrics running correctly inside your MSBuild project and finally creating an XSL to reformat the CCMetrics output and adding this to the Build Roport page. Setting up MSBuid is covered by the documentation, you need to download and configure the XML logger for MSBuild and hook up and additional XSL to format the MSBuild output.
Once you have MSBuild running you need to add a target to run CCMetrics. The MSBuild file looks something like this:
<PropertyGroup>
<CCMetricsExe>“$(ProgramFiles)\CCMetrics\CCMetrics.exe“</CCMetricsExe>
<CCMetricsArgs>/b /m 10</CCMetricsArgs>
<ProjectFolder>$(UserProfile)\My Documents\Visual Studio Projects\MyProject\</ProjectFolder>
<LogFolder>$(CCNetArtifactDirectory)\$(CCNetProject)\</LogFolder>
</PropertyGroup>
…
<ItemGroup>
<TargetAssembly Include=“MyProject.dll“>
<WorkingDirectory>$(ProjectFolder)MyProject\bin\$(Configuration)\</WorkingDirectory>
</TargetAssembly>
</ItemGroup>
…
<Target Name=“Metrics“>
<Exec Command=“del /f/q “$(LogFolder)*-CCMetrics-Results.xml““ ContinueOnError=“true“ />
<Exec ContinueOnError=“false“ Command=“$(CCMetricsExe) “@(TargetAssembly)“ $(CCMetricsArgs) /x > “$(LogFolder)@(TargetAssembly->’%(filename)’)-CCMetrics-Results.xml““
WorkingDirectory=‘%(WorkingDirectory)‘ >
</Exec>
</Target>
A couple of the links at the end of this post cover some of the tricks to getting MSBuild working just right.
Finally you have to merge and convert the output from CCMetrics into a report section on the CruiseControl Build Report page. This is covered in the documentation, its basically three steps. You can download the XSL I wrote for transforming the XML output from CCMetrics into a CruiseControl Build Report from here.
- Merge CCMetrics’ XML output into the build output by adding it do the <merge> section of the <publishers> confuguration section of ccnet.config.
- Copy the XSL into the webdashboard\xsl\ folder.
- Add an <xslFile> entry to the <buildReportBuildPlugin> section for the ccmetrics.xsl.
The only thing to really watch is that the merge picks up the correct files. Its quite easy to write the files to one folder but try and merge them from another – in which case no report gets displayed and no warnings either. Double check the paths in the build logs.
In my next post I’ll cover writing a custom trigger to kick of integrations when the machine processor utilization is low.
Other useful links…
- http://www.dougrohm.com/blog/post/2006/01/29/Integrating-MSBuild-with-CruiseControlNET.aspx – Tutorial on using MSBuild with CruiseControl.NET.
- http://weblogs.asp.net/kdente/archive/2005/07/19/419973.aspx – Handling exit codes correctly within MSBuild.
Welcome to my blog on software development and probably a whole lot more.
2 Responses to “CruiseControl.NET for Running Static Analysis – Part 1”
useful link of dougrohm is broken, updated link is
http://www.dougrohm.com/blog/post/2006/01/29/Integrating-MSBuild-with-CruiseControlNET.aspx
By Umesh Venkatachala on Nov 14, 2008
Thanks! I’ve updated it.
Ade
By Ade Miller on Nov 14, 2008