Continuous Integration with TFS: Pre-compiling a Web Application Project

If you are looking to pre-compile your web application projects with TFS 2008 Team Build, here are some tips.

First, you'll want to add the following to your TFSBuild.proj:

<Target Name="AfterDropBuild">
  <AspNetCompiler
     PhysicalPath="$(DropLocation)\$(BuildNumber)\Release\_PublishedWebsites\web_project_name"
     Debug="false"
     Force="true"
     TargetPath="C:\path_to_copy_precompiled_web_to"
     VirtualPath="/Path_to_your_web"
/>
</Target>

There a few things to note here.  First, the Target Name is crucial; this Target will get executed after the drop is made, i.e. after the build successfully runs and your files are copied to the drop folder you specified when you created the build.  Secondly, remember that this is running from the machine where your build agent runs.  The AspNetCompiler MSBuild tag shown here will launch aspnet_compiler.exe on that build agent machine, and so "/Path_to_your_web" points to the virtual directory on the default web site of your build agent machine.  Please note that "/Path_to_your_web" would be "/" in the case of your application being in the root directory.  Finally, the Force parameter is required since we will be writing over the existing pre-compiled web on subsequent builds.

If you want setup a build agent on another machine, perhaps a development web server where you would prefer to deploy the pre-compiled web application, you'll need to configure that agent according to these instructions.  This is a good idea when running verification tests that drive the web UI.

Happy Coding!

Getting MbUnit working with CruiseControl.NET

This is not exactly a straightforward process.  If you are having problems, here are a few hints about the bumps in the road.

• If you are having trouble managing the dependencies of MbUnit on your build server, then just include the "bin" folder of your test project in source control.  That way, all of those locally copied assemblies will get pulled out of source control along with the rest of your project.
• In addition to this information, there are a couple more steps to ensure your MbUnit output makes it into the web dashboard.  Make sure you put your file merge task into the publishers section of your project configuration in the ccnet.config file.  This will ensure the output of your MbUnit tests are always merged with the project configuration.  However, if you specify a publishers section, you must also specify a project xmlLogger.  Order matters here! The xmlLogger should be after your merge task to get your file merged in before the project log gets published to the dashboard.  So, your publisher section might look something like this:
  <publishers>
    <merge>
      <files><file>C:\path\to\mbunit-results.xml</file></files>
    </merge>
    <xmlLogger />
  </publishers>
• Speaking of your results file, you can use command-line switches of MbUnit.Cons.exe to specify that the file name is the same everytime you run it.
• MbUnit.Cons.exe can load an .exe assembly as easily as a .dll, so keep your tests project a console application so developers can step through their tests.