This build script compiles all of the code, creates a new database from scratch, runs the unit tests (including the silverlight tests), publishes the testresults into Genesis, and updates our lavalamp.  In case a particular build needs to divert from the standard operation procedure, you can override whatever target you want in the build process to customize it (or disable it).

Now ask yourself: is there any reason why you should tolerate duplication in your build scripts?

There was one issue at work that was somewhat hard to fix though. TeamCity has fantastic integrated support for NUnit, but unfortunately it doesn’t write NUnit’s output to XML files like nunit-console.exe does. After a bit of browsing, i found a post on the TeamCity forums that discussed a workaround on how to get the output. Unfortunately the workaround is a bit cumbersome as it requires you to you create an XML file which contains the arguments that TeamCity would pass to its NUnitLauncher task.

I believe in ‘script reuse’ as much as i believe in ‘code reuse’, so every project’s build script merely imports a generic build script and then it just overwrites some variables that the generic script uses and then it kicks off the usual build process. Since all of our projects will now be built by TeamCity Build Agents, and we definitely need to have NUnit’s results xml file i wanted to automate this whole thing as much as possible.

So instead of having to create (and thus, maintain) a cumbersome xml file for each project, i wrote an MSBuild task that would generate the xml file containing the arguments on the fly during the build, and would then pass those xml arguments to TeamCity’s NUnitLauncher. This way we get to keep all of TeamCity’s NUnit integration goodness, while still keeping the NUnit result files around as well.

So now in my MSBuild file, i can just do this:

As you can see, there is nothing project-specific in there so this just integrates nicely into each build that we need. The only limitation to this approach is that TeamCity’s NUnitLauncher will write one NUnit result file for each assembly containing tests. Apparently there is no way in the current version of TeamCity to get it to combine those results. We use an extra tool to analyze the NUnit output after the tests have run, and unfortunately it requires all of the results to be in one file. I looked around for a way to merge the output of several NUnit result files, but i didn’t find something that was already available. So i wrote another MSBuild task that would merge the output into one xml file:

Now we finally have all of TeamCity’s goodness while we still get to run our post-test analysis on the NUnit result file that contains the testresults of all the test assemblies

You can find the code of the MSBuild tasks here. They are BSD-licensed so feel free to use them if you need them.

it uses the MSBuild Community tasks btw… Like i said, this is a very basic script. It only builds your solution and it runs all of your tests. That’s it. No packaging of the output, no code coverage (if you’re really doing TDD, code coverage is useless anyway), no whatever else you can think of. But you can easily add all of that stuff of course

Now watch me get flamed for not using nant