February 2007 Entries
MSBuild with Cruise Control .NET - Part 2 (NUnit)

In a previous post, I laid out our standard structure for MSBuild with Cruise Control.  Now I will show the details of FxCop and NUnit.

Now you want to run FxCop:
<Target Name="FxCop" DependsOnTargets="Build">
Command="fxcopcmd /p:&quot;$(CCNetWorkingDirectory)\SolutionAnalysis.FxCop&quot; /out:&quot;$(CCNetArtifactDirectory)\SolutionAnalysis-Fxcop.xml&quot;"
WorkingDirectory="C:\Program Files\Microsoft FxCop 1.35"
Text="This solution does not contain a SolutionAnalysis.FxCop file in the solution root." />
<Message Text="TestVar = $(TestVar)"/>

You'll notice that this is looking for a "well-known" file called "SolutionAnalysis.fxcop" location in the root of our solution.  You may have 20 projects on CCNet - this enables a standard structure across all solutions.  If it doesn't find this file, it simply skips the step via the Condition attribute on the Exec task. This Exec task simply calls

Posted On Saturday, February 24, 2007 8:37 PM | Comments (0)
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":

<projectFile>C:\Program Files\CruiseControl.NET\MSBuildScript\ccnetMSBuild.proj</projectFile>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>

 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...

Posted On Friday, February 23, 2007 7:17 PM | Comments (7)

View Steve Michelotti's profile on LinkedIn

profile for Steve Michelotti at Stack Overflow, Q&A for professional and enthusiast programmers

Google My Blog

Tag Cloud