MSBuild with Cruise Control .NET

You want to set up a customizable, fully automated build process. You want your build process to incorporate FxCop, NUnit, NCover, etc. but you do not have the license for Team System. No problem.  You can do all of this with free tools leveraging MSBuild and Cruise Control .NET (CCNet) as the basis of your solution. This is not new news.  In fact, CCNet is probably the best known tool today to do automated builds. However, there are lots of different ways to implement your build process. I'm going to do a series of posts that provide a start to finish implementation of one way to set up your build server. The posts will eventually include custom MSBuild tasks, custom CCNet add-ins, 32 bit / 64 bit considerations, and building MSI files with MSBuild.  In this post, I will just start with the primary structure and build process.

To kick off the MSBuild process, you'll use the standard "msbuild" task provided by CCNet pointing to the custom MSBuild project file that we'll construct "ccnetMSBuild.proj":

<tasks>  
  <msbuild>  
      <executable>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</executable>  
      <workingDirectory>C:CCNetArtifactMyProjectNameWorking</workingDirectory>  
      <projectFile>C:Program FilesCruiseControl.NETMSBuildScriptccnetMSBuild.proj</projectFile>  
      <timeout>600</timeout>  
      <buildArgs>/p:ProjectFile=$SolutionFile$</buildArgs>  
      <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>  
  </msbuild>  
</tasks>

The basic outline of the msbuild script will be this:

1. Version assemblies in the current solution (details to come in a later post)
2. Do a Debug build (if compile fails, stop build)
3. Run FxCop on the solution
4. Run NUnit on the solution
5. Run NCover on the solution
6. If everything has run successfully, do a Release build

First, we utilize the standard msbuild task to do a Debug build.  Why do a Debug build before a Release build?  There are a couple of reasons.  First, Debug is the default mode for the developer on their local systems.  We encourage the developers to run FxCop locally before checking in - it's most convenient for them to be able to do this straight from Debug mode without having to first rebuild in Release mode.  Additionally, we typically will set our NUnit projects to build only in Debug mode but not in Release mode because we do not want to deploy NUnit projects out to a production environment.  Again, keeping it in Debug mode simplifies everything here.

This is the standard structure - in the interests of keeping this post a reasonable length, I will expand on the details on my next post...