Building .NET Solution with Rake and TeamCity

I’ve been reading through my Ruby books and came across Rake. Rake is a Ruby build program similar to NAnt or MSBuild but instead of writing XML, you use Ruby instead. Now that opens all sorts of doors, so I thought I’d see if I could get Rake to build a .NET solution and take it from there.

First things first, if you want to do this you will need to download and install Ruby, luckily for us, Rake is included. You will need to reboot after to ensure your PATH is updated.

Now we are ready to rumble. First thing I wanted to try was just compiling a solution – nice and simple. There were a few samples around the interweb, and I soon created the following:

DOT_NET_PATH = "#{ENV["SystemRoot"]}\\Microsoft.NET\\Framework\\v3.5"
SOURCE_PATH = "../src"
CONFIG = "Release"

task :default => ["build:all"]

namespace :build do

    task :all => [:compile]

    desc "Build solution using MSBuild."
    task :compile do
        puts "Compiling Solution..."
        solutions = FileList["#{SOURCE_PATH}/**/*.sln"]
        solutions.each do |solution|
          sh "#{DOT_NET_PATH}/msbuild.exe /p:Configuration=#{CONFIG} #{solution} /t:Rebuild"


Save this file as “rakefile.rb” and put it in a folder called “build” which is at the same level as the “src” folder. Then at a command prompt, navigate to the build folder and use the following command:


It worked!

Inside the Rake file we define the default build task as the :all task that is inside our build namespace. This task currently consists of one task :compile. The :compile task searches the src folder for any solution files and the builds them using MSBuild in release.

That was pretty easy and worked without a hitch. So next, I wanted to list the things I wanted my new build script to do:

  1. Get the current SVN revision number
  2. Update all AssemblyInfo.cs files with a new version number that contains this SVN rev number
  3. Build the solution (as above)
  4. Run NUnit tests
  5. Create test coverage report
  6. Copy all the files that need to be deployed (excluding those that don’t)
  7. Zip up these files into a deployment package
  8. Integrate as much as possible with TeamCity
  9. Should be able to run the same build script locally as well as with TeamCity

It took a little but I got it working. You can see the full file here. Below is a breakdown of each section:

Getting the current SVN revision number

First off, you’ll need to get the SVN command line client downloaded and installed. You will need to reboot after to ensure your PATH is updated.

I decided to add a new :init task that should clean up, create folders and get the SVN HEAD revision number. So here is the new code I’ve added:

require 'rexml/document'


OUTPUT_PATH = "output"
SVN_LOG_PATH = "#{OUTPUT_PATH}/svn_log.xml"
SVN_URL = "http://aardvark-cms.googlecode.com/svn/trunk/"

namespace :build do

    task :all => [:init, :compile]


    desc "Perform the required initial tasks."
    task :init do
        puts "Performing Initialization..."

        puts "Creating folders..."

        puts "Getting SVN revision number and saving to #{SVN_LOG_PATH}..."

        sh "svn log --xml --revision HEAD #{SVN_URL} > \"#{SVN_LOG_PATH}\""

        log = REXML::Document.new File.new(SVN_LOG_PATH)
        logEntry = log.root.elements["logentry"]
        $svn_revision = logEntry.attributes["revision"]
        $svn_message = logEntry.elements["msg"].text
        VERSION = "#{VERSION_MAJOR_MINOR_BUILD}.#{$svn_revision}"

        puts "Revision #{$svn_revision} found with message: #{$svn_message}"

There are a bunch of new constants and I’ve included the an xml parser at the top. Then I’ve added a new task called :init and added it to the :all task before the :compile task.

Inside the :init task we create some folders, then we use the SVN command line tool to request the HEAD revision information from the repository url and save it as xml to the output folder that is inside our build folder.

Once there, we can read the details from this xml file and create a version number for our application.

Updating AssemblyInfo.cs with new version number

Now that we have the SVN revision number and have generated a version number for the current build we need to apply it to our assemblies. We do that by rewriting the AssemblyInfo.cs file for each assembly in our solution. That calls for a new task:

PROJECT_NAME = "Aardvark"
COPYRIGHT = "Copyright 2009 1minus1 Ltd. All rights reserved."

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile]


    desc "Write AssemblyInfo.cs with current svn revision."
    task :writeAssemblyInfo => [:init] do
    puts "Writing AssemblyInfo Files..."

        assemblyInfoFiles = FileList["#{SOURCE_PATH}/**/AssemblyInfo.cs"]
        assemblyInfoFiles.each do |filePath|
            puts "AssemblyInfo file found at: #{filePath}"
            file = File.new(filePath, "w")

            file.puts "//This file was generated by the rakefile.rb build script"
            file.puts "using System.Reflection;"
            file.puts "using System.Runtime.InteropServices;\r\n"

            file.puts "[assembly: AssemblyTitle(\"#{PROJECT_NAME} for .NET 3.5\")]"
            file.puts "[assembly: AssemblyDescription(\"\")]"
            file.puts "[assembly: AssemblyConfiguration(\"\")]"
            file.puts "[assembly: AssemblyCompany(\"\")]"
            file.puts "[assembly: AssemblyProduct(\"#{PROJECT_NAME}\")]"
            file.puts "[assembly: AssemblyCopyright(\"#{COPYRIGHT}\")]"
            file.puts "[assembly: AssemblyTrademark(\"\")]"
            file.puts "[assembly: AssemblyCulture(\"\")]"
            file.puts "[assembly: ComVisible(false)]"
            file.puts "[assembly: AssemblyVersion(\"#{VERSION}\")]"
            file.puts "[assembly: AssemblyFileVersion(\"#{VERSION}\")]"


This is pretty straightforward, we search for all the AssemblyInfo.cs files and then loop through them overwriting them as we go with a new set of attributes. We’ve defined a couple of new constants at the top to use, but the important thing is the use of the newly generated version number.

We add this new :writeAssemblyInfo task to the :all build task before we compile to ensure that every build will include the correct revision number.

Run NUnit Tests

Now we have built our solution, we need to run the tests. Here we need to do something a bit extra as we want to use the TeamCity NUint runner if it is TeamCity running the build. Otherwise we want to use the normal NUnit console for when we are running the build locally.

TEAMCITY_NUNIT_RUNNER = ENV["teamcity.dotnet.nunitlauncher"]
NUNIT_EXE = "../tools/NUnit/nunit-console.exe"

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test]


    desc "Runs tests with NUnit only (without coverage)."
    task :test => [:compile] do
        puts "Running Tests..."
        tests = FileList["#{SOURCE_PATH}/**/#{CONFIG}/*.Tests.dll"].exclude(/obj\//)

        #Select the correct test runner
        if(TEAMCITY_NUNIT_RUNNER == nil)
            sh "#{NUNIT_EXE} #{tests} /nologo /exclude:Acceptance /xml=#{OUTPUT_PATH}/TestResults.xml"
            sh "#{TEAMCITY_NUNIT_RUNNER} v2.0 x86 NUnit-2.4.6 /category-exclude:Acceptance #{tests}"


In this task we first get a list of all the test assemblies based on our naming convention (they end in .Tests.dll) and make sure we exclude any from the obj folders. Then if the TeamCity NUnit runner environment variable is available we use that to run the tests, otherwise, use the NUnit console program that we store in a tools folder. At present we are excluding out WatiN acceptance tests, but more on this later.

Using the TeamCity NUnit runner is important to us as it will ensure that the TeamCity test UI and data are updated correctly.

Create test coverage report

This is where it gets interesting for me. Adding test coverage reports is a good way to ensure that you (or someone else) hasn’t been lazy and written some code without a test first. I don’t think that you should have a fixed percentage that must be covered, be pragmatic.

NCOVER_EXE = "../tools/NCover/NCover.Console.exe"
NCOVER_EXPLORER_EXE = "../tools/NCoverExplorer/NCoverExplorer.Console.exe"
COVERAGE_ASSEMBLIES = "OneMinusOne.Aardvark.Web;OneMinusOne.Aardvark.Framework;OneMinusOne.Aardvark.Entities;OneMinusOne.Aardvark.Core"

task :default => ["build:all"]

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test, :coverage]


    desc "Run tests with NUnit and NCover for coverage. NCoverExplorer is used to format the coverage results into html."
    task :coverage => [:compile] do
        puts "Running Tests with Coverage..."
        tests = FileList["#{SOURCE_PATH}/**/#{CONFIG}/*.Tests.dll"].exclude(/obj\//)
        sh "#{NCOVER_EXE} #{NUNIT_EXE} #{tests} /nologo /exclude:Acceptance /xml=#{OUTPUT_PATH}/TestResults.xml //reg //x #{OUTPUT_PATH}/Coverage.xml //l #{OUTPUT_PATH}/Coverage.log //ea System.CodeDom.Compiler.GeneratedCodeAttribute //a #{COVERAGE_ASSEMBLIES}"
        sh "#{NCOVER_EXPLORER_EXE} #{OUTPUT_PATH}/Coverage.xml /r:ModuleClassFunctionSummary /p:#{PROJECT_NAME} /q /h /so:2 /m:80 /h:#{OUTPUT_PATH}/CoverageReport.html"

This is a pretty short task. First we use NCover to profile the code while it’s tests are run, then we use NCover Explorer to generate a nice html report. We’ve stored these two programs in our tools folder so you don’t need them installed and it’s easier to get the build running.

You need to do a few extra things in TeamCity to get this to work and show up on a new tab. Here’s what you need to do:

  1. Ensure that the build agent service is logged in as an administrator. Otherwise NCover will not be able to profile the tests and you’ll see the error “Profiler connection not established” in your build log.
  2. Add the html report that NCover Explorer generates to your TeamCity artifacts under a folder called Reports.
  3. Edit the TeamCity main-config.xml file as shown here to add a tab for your html report.

Create a deployment package

The last thing that I want my Rake build to do is to collect together the files I need to deploy and zip them up for me.

WEB_PROJECT_PATH = "../src/OneMinusOne.Aardvark.Web"
ZIP_EXE = "../tools/7Zip/7za.exe"

task :default => ["build:all"]

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test, :coverage, :package]


    desc "Package the required artifacts."
    task :package => [:compile] do
        puts "Preparing package files..."

        Dir.mkdir "#{ARTIFACTS_PATH}/bin"

        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/bin/*.dll"], "#{ARTIFACTS_PATH}/bin"
        FileUtils.cp_r "#{WEB_PROJECT_PATH}/Content", "#{ARTIFACTS_PATH}"
        FileUtils.cp_r "#{WEB_PROJECT_PATH}/Views", "#{ARTIFACTS_PATH}"
        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.aspx"], "#{ARTIFACTS_PATH}"
        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.asax"], "#{ARTIFACTS_PATH}"
        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.config"], "#{ARTIFACTS_PATH}"


        puts "Creating zip package"

        zipFolder(ARTIFACTS_PATH, "#{OUTPUT_PATH}/#{PROJECT_NAME}-v#{VERSION}.zip");

    def delete_svn_folders(folder)
        Find.find(folder) do |path|
            if(path =~ /\.svn$/ || path =~ /\_svn$/)
                puts "Deleting: #{path}"
                FileUtils.rm_r path, :force => true

    def zipFolder(folderPath, zipPath)
        sh "#{ZIP_EXE} a #{zipPath} .\\#{folderPath}\\*"

As this is a Castle MonoRail application, I start this new :package task by copying all the required web files to an artifacts folder that is inside the output folder we created earlier. This ensures that we only have the files required to run the application and we exclude all other files.

Once the files are copied I noticed that because we were copying folders, the hidden .svn folders were being copied too. The only way I could see was to then delete these folders from the artifacts folder. This is where the delete_svn_folders function comes in. It just loops through and deletes any path that ends with either .svn or _svn as either can be used.

The final thing is to zip these files up. I use the 7zip command line tool to do this and I’ve added this to the tools folder again to make it as easy as possible to run the build. The zip file is saved to the output folder and is named with the project name and version number.

Finishing up

That’s it really, you can see the full build file here at Google Code. There are some extra bits and pieces in this build like coping the files to the development server, requesting an installer page on the site that will install the database and populate it with data but that was a bit specific for our needs so I didn’t add it here.

The advantage I can see here using Rake over NAnt or MSBuild is that you can program your build using code rather than xml which I find a lot easier and a lot more powerful.

The one thing that is missing from the build is the ability to run our acceptance tests that are written using WatiN. I found this post on Stack Overflow and this post on JetBrains forum which may point me in the right direction.

I hope that has helped, Rake is the future…


9 Responses to “Building .NET Solution with Rake and TeamCity”

  1. August 18, 2009 at 7:36 pm

    This is a great post, you’re doing some funky stuff with Ruby/Rake there! Thanks for sharing the build file too. I’ve also used it to run tests and NDepend stuff, very useful. We’re thinking of trying it with TeamCity too, this will be a great starting point.

    You might be interested to read my post on IronRuby + Rake (click link above). It’s great for doing stuff where you want to interact with your own assemblies (domain model, infrastructure etc).

    Along a similar line, we’re also using Git to do one-click deploy to staging server (eg: git commit -a -m”Blah [deploy:staging]” – we’ve wired up post-commit hooks on github to invoke a remote service which does the checkout etc… I bet TeamCity will handle a lot of this for us.

    Anyway, always nice to .NET devs making the most of Rake + Ruby.

    • 2 Andy
      August 18, 2009 at 9:28 pm

      Thanks for the feedback Tobin. Your posts on Ruby/Rake look really cool, I’ll see if there are some bits in there that I can steal ;o)

  2. 3 Tim
    September 3, 2009 at 2:08 pm

    Hi Andy, nice post, there are some really nice examples-I have recently been involved in writing something similar in NAnt, rake certainly seems to make it more readable than all that XML! I will definitely be taking a look at my project and seeing if rake brings anything to the party!


  3. 4 Jet
    September 17, 2009 at 9:41 am

    Hi Andy,

    Thanks for this it has proved really helpful in getting me going with Rake.

    I am having a little problem however that intermittently, the script that gets the svn revision number fails. The log xml file is empty apart from the root log elements etc. If I recommit the solution to subversion then it works fine again. I get the sense that something is happening in subversion that stops the svn client getting the revision number for my project. Maybe someone committing into another project or something.

    Have you encountered this issue in your usage of the svn command line client to get the revision number.

    Many thanks

    • 5 Andy
      September 17, 2009 at 12:38 pm

      Hi Jet,

      No I haven’t had any problems with that. I’ve had a quick search around but can’t find any related information. What version of the svn client tools do you have installed? Also, could it be down to a connection problem? Sorry I can’t be more help.


  4. 6 Rob
    September 18, 2009 at 12:51 pm

    An easier (less code) way to get the svn revision is:

    revision = %x[svn log –non-interactive –xml –limit 1].scan(/revision=”(\d+)”/).to_s

  5. 7 Andy
    September 18, 2009 at 1:35 pm

    Thanks Rob, nice one :o)

  6. 8 Jet
    September 18, 2009 at 2:02 pm

    Hi All thanks for the replies. I have worked out that it is in fact as I thought it was. If someone working on another project (another trunk) commits the call to get the head revision with this approach fails to return anything and when the rakefile tries to access the xml attributes they do not exist in the log file that is produced.

    Will try Robs approach as an alternative.

    Thanks Guys

  7. 9 Rob
    September 18, 2009 at 5:14 pm

    I think the two methods are effectively the same. Mine is just calling it using one line, and skipping writing to a file by catching the command line output. It still pulls the most recent revision I think, ie the HEAD.

    You want to look at the command you are using. In my example, I haven’t passed in a url, so it’ll pick up where ever the runner is being executed from. You can specify a url if you want though:

    svn log http://my-svn …. etc

    I’m still stuck trying to use the NUnit runner via the Agent, rather than the NUnit we have in our tools repo.

    ENV[“teamcity.dotnet.nunitlauncher”] always seems to come up null depite it showing in the system properties for the build agent.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


  • RT @nodunayo: A friend at a startup is looking for a few engineers (freelance/full-time). They mainly work in Ruby, JS, and Angular. DM me… 1 day ago
  • RT @kyan: We're looking for talented individuals to join our growing team! Could you be our next Senior Web Developer? https://t.co/I81qh67… 2 days ago
  • RT @pollingj: Interested in working with Elixir and Ember on a range of projects? See below :) twitter.com/whitingx/statu… 1 week ago
  • Do any conferences have a "fun" track? For people that go for the social side and are happy to attend something different? 1 week ago
  • Do I know any Rails devs with some availability? Rails 5, fully TDD, CI, WebRTC, all the good stuff. DMs are open. 💖 for RTs! 3 weeks ago

My Archives

My Categories

%d bloggers like this: