Breaking Change in Cruise Control .NET 1.6

Building on my earlier post about Setting up Cruise Control .NET 1.5/1.6 on Windows 7 + IIS7, I have identified a breaking change with CruiseControl .NET 1.6.x.

For readability, I like to place each -D flag in my <buildArgs> definition on a separate line

    -D:LocalDeployRoot=D:cideployMyProject </buildArgs>

however in upgrading to version 1.6.x, I have come across a breaking change. Using the same script in my 1.6.x implementation, I was getting the eror message Target ‘ ‘ does not exist in this project. I confirmed that the NAnt script worked by calling it directly with the same parameters that I was defining via my CCNET project configuration.

After looking into the issue for a while (and even posting a question on StackOverflow) I found a clue when reading through the server log. I noticed that the target was being specified to nant.exe following the <buildArgs> definitions along with the white spaces and newlines. Removing the white space and newlines resolved the issues.

<buildArgs>-D:SolutionFile="$(Batch_WorkingFolderTrunk)MySolution.sln" -D:LocalDeployRoot=D:cideployMyProject</buildArgs>

I have logged a bug report with the Cruise Control .NET team regarding this issue.

Setting up Cruise Control .NET 1.5/1.6 on Windows 7 + IIS7

I have been setting up a new continuous integration system on my laptop for some of my personal projects and thought it would be a good time to upgrade to Cruise Control 1.5. I came across some issues during the setup so I have put up my notes on the process in case anyone else has the same issues.
My Development Environment
Windows 7 (64-bit)
IIS 7.5
Cruise Control 1.6
Nant 0.86, Nant 0.91-alpha2
Visual Studio 2008, Visual Studio 2010
Installation Steps
  1. Download the installation package from
    • The release build of version 1.5 is available here on Source Forge.
    • The nightly build for version 1.6 is available here on CCNet Live.
  2. Run the installer. This will copy the files you need and create the IIS site/virtual directories needed to access Cruise Control .NET from your browser.
  3. Open your Internet Information Services (IIS) Manager (Start -> Run -> inetmgr )
  4. Create a new website point the site to <INSTALL PATH>webdashboard.
  5. Change the bindings for the new site to a unique port. ( I use port 90 and the CCNET is then accessed via http://localhost:90)
  6. Open the application pool created for this site and change the ‘Managed pipeline mode’ to ‘Integrated’.
  7. Open the services manager (Start -> Run -> services.msc) and start the Cruise Control .NET service.

Security& Permissions Issues

The default installation may cause issues due to permissions required to create folder (there are folders created on the fly for each CCNET project). It is best practice to have the CruiseControl.NET service running under a service account with proper permissions in the <INSTALL PATH>server and <INSTALL PATH>webdashboard  directories and subdirectories. The service account needs enough permissions to create new folders and files within the .server folder.


The new version of Cruise Control .NET has an admin dashboard that allows you to manage the plugins to display on the report pages. To enable the login, you need to modify /webdashboard/dashboard.config and add a password for the <administrationPlugin /> element.

As you install and uninstall the plugins, click the View Log button that appears next to the “Package has been installed” message to view the log of the installation. If there were any complications with the installation (usually permissions related), this log is your best source of information).

Visual Studio 2010 Unit Tests

The Visual Studio 2010 unit test results file has changed slightly from 2008. CCNET 1.6 addresses this issue.

Continuous Integration with Cruise Control, .NET (C#, WPF, ASP.NET) Projects, and NAnt

UPDATE: NAnt 0.91 Alpha 2 has been released with support for .NET 4. Download it here.
UPDATE: CruiseControl.NET 1.5 (Final) has been released and is available here.
UPDATE CruiseControl.NET 1.5 RC1 has been released and is available here.

My Cruise Control .NET implementation consists of numerous development projects each with multiple different Cruise Control .NET projects associated with it (one per environment per branch). In order to make the projects more maintainable, I have created a separate configuration file for each development project. Defining variables and separating ccnet.config configuration file into smaller files allows for easier maintenance of each project over their lifetimes.

Defining and using variables

Variables can be defined using the following format

<cb:define KEY=”VALUE” />

To reference that variable later in the configuration file, simply use $(KEY)

Check out the Cruise Control .NET website for complete explanation of variables using the pre-processor.

Separating the configuration files

<!DOCTYPE cruisecontrol [
<!ENTITY PROJECT_NAME SYSTEM “file:project.xml“>
<cruisecontrol xmlns:cb=”urn:ccnet.config.builder”>

project.xml would, then, contain the regular xml configuration for a Cruise Control .NET project:

<?xml version=”1.0″ encoding=”utf-8″?>
<project name=”My Project” category=”A Category”>
<intervalTrigger seconds=”900″ buildCondition=”IfModificationExists” />
<scheduleTrigger time=”04:00″ buildCondition=”ForceBuild” />
<labeller type=”svnRevisionLabeller”>
<pattern>Version {major}.{minor}.{build}.{revision}</pattern>
<sourcecontrol type=”svn”>
<cb:SvnOptions />
<xmllogger />
<cb:include href=”EmailConfig.xml”/>

On caveat with this idea is that changes to the separate configuration files are not recognized until the cruise control is restarted by either restarting the service or modifying the ccnet.config file.

Building and Deploying ASP.NET Web Applications

The NAnt target below is a full parameterized call to MsBuild.exe to compile any solution. ThoughtWorks.CruiseControl.MsBuild.dll provides an MSBuild logger that allows Cruise Control .NET to report the bulid output.

<target name=”build”>
<exec program=”${MSBuildPath}”>
<arg line='”${SolutionFile}”‘ />
<arg line=”/property:Configuration=${SolutionConfiguration}” />
<arg value=”/target:Rebuild” />
<arg value=”/verbosity:normal” />
<arg value=”/nologo” />
<arg line=’/logger:”C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll”‘/>


MSBuildPath – The path to the MsBuild executable.

For .NET Framework versions 2.0 and 3.5  on a 32-bit Windows OS, use C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MsBuild.exe
For .NET Framework version 4.0, use C:WINDOWSMicrosoft.NETFrameworkv4.0.30319MsBuild.exe

SolutionFile – The relative path from the build file to the solution file. Fully qualified paths are also allowed.

SolutionConfiguration – “Release” or “Debug”.