I'm currently helping the Robertson Research Institute convert their large C# Visual Studio .NET 2003 applications to Visual Studio 2005 ("Whidbey") Beta 1. For the past year-and-a-half, we've used CruiseControl.NET (CC.NET), NAnt, NUnit, and FxCop to automate our build, unit testing, and static code analysis. Now that we're running under the .NET Framework 2.0, we'd like to leverage the MSBuild tool in our processes (unfortunately, the most recent version of NAnt doesn't understand the new file formats). Fortunately, the new formats can be directly consumed by MSBuild.So, I spent some time today trying to figure out how to get the latest versions of these tools to work together. Although I wasn't able to achieve a perfect solution, I did find a configuration that is workable until CC.NET adds native MSBuild support. Here are some of the ideas I considered:
Because I wanted a simple solution, I decided to try the commandLineBuilder. Additionally, since the CC.NET team is already planning MSBuild support, it should be an easy transition when the new feature finally arrives. So, the setup I'll describe uses NUnit 2.2, FxCop 1.30 for .NET 2.0, and the latest nightly build of CruiseControl.NET.
Before you do anything else, you should modify your NUnit 2.2 configuration file to prefer the .NET Framework 2.0. You'll need to do this for CC.NET to successfully run your unit tests. Open the nunit-console.exe.config file and find the following section:
<startup> <supportedRuntime version="v1.1.4322" /> <supportedRuntime version="v2.0.40607" /> <supportedRuntime version="v1.0.3705" /> <requiredRuntime version="v1.0.3705" /></startup>
Then, move the version 2.0.40607 element to the front of the list and save:
<startup> <supportedRuntime version="v2.0.40607" /> <supportedRuntime version="v1.1.4322" /> <supportedRuntime version="v1.0.3705" /> <requiredRuntime version="v1.0.3705" /></startup>
As a side note, if you plan to use the NUnit 2.2 GUI for manual testing, you'll have to make the same change to the nunit-gui.exe.config file.
MSBuild scripts can range from the very simple to the very complex. For this example, we'll stick with something easy. Whether you know it or not, the solution and project files that Visual Studio 2005 produces can be directly fed into MSBuild. So, for a solution called Bank.sln, I can build all of its projects by typing MSBuild Bank.sln. Although this works with solution files, they are not actually in the official MSBuild XML format. But, project files are. And the best part is that you can manually modify the project/MSBuild file and Visual Studio 2005 will respect your changes. Okay...I'm getting off-topic...let's get back on track...
If you don't want to run FxCop analysis as part of your CC.NET build, you do not need to create your own build file. However, if you'd like to include FxCop analysis, you can create your own build file in the same directory as your solution file. For example, I created the following Bank.msbuild file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Target Name="Build">
<!-- Clean, then rebuild entire solution --> <MSBuild Projects="Bank.sln" Targets="Clean;Rebuild" />
<!-- Run FxCop analysis --> <Exec Command="FxCopCmd.exe /project:C:\depot\Bank\Bank.FxCop /out:C:\depot\Bank\Bank.FxCop.xml" WorkingDirectory="C:\Program Files\Microsoft FxCop 1.30" />
This file has a single target called Build. The first thing it does is call MSBuild on the Bank.sln file. The Targets attribute says that we'd like to execute the Clean task first (which deletes all of the old build output), then execute the Rebuild task. I run Clean so that there are no old files from the last build left sitting in the output folders. It can be confusing if your build fails but the unit tests pass. This is usually because the old unit test assembly is still hanging around from a prior successful build. Using Clean eliminates that problem.
Next, the Exec command executes FxCop. I have it execute against an FxCop project file, but you can call it directly against an assembly if that works better for you. I've directed the output to an xml file that will later be merged into the build and NUnit output so it can be reported by CC.NET.
Now we need to tell CC.NET to call our MSBuild file (or, if you don't need to run FxCop, you can directly call the solution file). Although there are many sections in the ccnet.config file, these are the elements that we're interested in:
<build type="commandLineBuilder"> <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\MSBuild.exe</executable> <baseDirectory>C:\depot\Bank</baseDirectory> <buildArgs>Bank.msbuild /p:Configuration=Debug</buildArgs> <buildTimeoutSeconds>60</buildTimeoutSeconds></build> Notice that instead of using a build type of NAnt, we've specified the commandLineBuilder. This allows us to call anything we'd like at the command line. The baseDirectory points to the directory containing the Bank.msbuild file that we created earlier. The buildArgs specifies the name of the build file and any other command-line options we'd like to send to MSBuild. If you don't plan to run FxCop, you can simply call MSBuild on the solution file by replacing the buildArgs with the following line:
<buildArgs>Bank.sln /t:Clean;Rebuild /p:Configuration=Debug</buildArgs>
Since our MSBuild script doesn't get the latest source from the source repository, you'll want to let CC.NET do it by setting autoGetSource to true in your sourcecontrol tag.
To run the NUnit tests, use the nunit task by specifying the path to the NUnit console application, and list the assemblies that you'd like to test. Because we're using CC.NET's nunit task, we don't need to worry about merging the test output (like we might normally have to do if we were using NAnt).
<tasks> <!-- No file merging necessary if using CC.NET's NUnit task --> <nunit> <path>C:\Program Files\NUnit 2.2\bin\nunit-console.exe</path> <assemblies> <assembly>C:\depot\Bank\BankTest\bin\debug\BankTest.dll</assembly> </assemblies> </nunit> <!-- Merge FxCop output --> <merge> <files> <file>c:\depot\Bank\*.FxCop.xml</file> </files> </merge> </tasks>
Last, we do need to tell CC.NET to merge our FxCop output. This lets us see the FxCop detail on the CC.NET web site.
Although this isn't a perfect solution, it's a great temporary solution that doesn't take a lot of effort. By using this configuration, you'll be able to use MSBuild, run your NUnit 2.2 tests, and leverage the latest version of FxCop all under the control of CruiseControl.NET. The only downside is that—because CC.NET doesn’t know how to capture useful build output from the commandLineBuilder—you won't see your build warnings and errors in the CC.NET e-mail or on the web site. Although this sounds like a show-stopper, you can use the original log link on the web site, and it is trivial to quickly find the last failure.
If you're curious about MSBuild, you can find a three-part MSDN article here, here, and here. If you'd like to know more about CruiseControl.NET, continuous integration, and the Ambient Orb, check out my other article.