Build Tools Roundup For .NET Systems

It seems there is not shortage of build tools that are available for the .NET developer these days. Of course I’m quite partial to the Ruby + Rake + Albacore solution, being the big tuna behind albacore and all… but quite honestly that amount of choice makes me very happy. It seems there is a good tool for just about every different comfort zone in the .NET developer world. At this point in time, there’s not one right answer of which build tool to use. You don’t need to choose which tool to use based on what features and functionality it supports anymore. Rather, you can make the choices based on what your comfortable with – be it the runtime environment, the language to create build steps, the data specification, etc. Choice is good. Understanding what each choice offers is even better. Here’s my take on the current set of tools that I’m aware of and what the comfort zone of these tools are.


Nant: The Godfather Of .NET Build Systems

Runtime: .NET

Build Configuration Language: XML with extensions written in .NET


Nant is the old-school guy on the .NET block, having grown up over on Java road. This is the original .NET build tool that so many others wanted to be or wanted to be better than. If you’ve used any build tools for more than a few years in .NET, you’ve probably used Nant at least once. There are a lot of extensions and add-ons to Nant, including a user contributions project, several visual tools designed to abstract away the xml, some conventions based add-ons that make nant easier, etc. If you need to do it in your build process, chances are there is a plugin or a blog post that tells you how to do it with Nant.

Nant was originally a copy of the Java Ant build tool but quickly took its own directions in implementation becoming the defacto build tool in .NET for several years. With it’s heavy reliance on xml and its roots tracing back to java, most “enterprise” developers chose Nant because of it’s familiarity from the Java world.

Example: Build a solution

   1: <target name="compile">

   2:        <echo message="Build my solution!" />

   3:        <msbuild project="src/mysolution.sln">

   4:               <arg value="/property:Configuration=release" />                                  

   5:               <arg value="/t:Rebuild" />

   6:        </msbuild>

   7: </target>


UppercuT: You Won’t Know What Hit You

Runtime: .NET (Nant) with extensions to call out to other platforms such as Ruby/Rake.

Build Configuration Language: None for simple builds. XML/Nant, Ruby, and Powershell for extended scenarios


If you’re going to use Nant and you don’t need to do anything “unusual”, then you should be using UppercuT. This is an add-on that makes Nant so easy to use, you don’t even need to know how to use Nant. UppercuT makes good on it’s promises, too. It really is that easy to get a build up and running because you don’t need to know anything other than the basic conventions that it uses to find your solutions, tests, etc.

From the project’s homepage:

It seeks to solve both maintenance concerns and ease of build to help you concentrate on what you really want to do: write code. Upgrading the build should take seconds, not hours. And that is where UppercuT will beat any other automated build system hands down.

UppercuT is targeted at those who want all of the power and stability that Nant provides, but don’t want to deal with a ton of XML and build script definitions.

Example: No, really… this project makes building with Nant so easy, you don’t need to configure any tasks for most things. Check out the website for more information.


MSBuild: Bringing ‘One Microsoft Way’ To Your Build System

Runtime: .NET

Build Configuration Language: XML with extensions written in .NET


Microsoft’s own build tool – if you’re using visual studio, you’re already using MSBuild. Unless you’re calling directly into the compiler for your language – such as csc.exe for c# – you are probably using MSBuild in your build process. With VS2005 and later, all .sln and .proj files are msbuild files… or, at least they can be interpreted by msbuild. MSBuild is more than just a solution builder for visual studio, though. It is a complete build system in the same vein as Nant. As much as I love to hate msbuild and it’s associated tools (such as Team Foundation Server and MSTest) I have to give Microsoft credit for getting a build tool into the hands of every .NET developer on the planet.

In recent years, MSBuild has become the standard build tool for shops that are not allowed to use open source, or want to stick with paid-for-support tools from Microsoft.

Example: Clean and build your solution (“borrowed” from RhysC)

   1: <Project DefaultTargets="Clean" xmlns="" ToolsVersion="3.5">

   2:   <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>


   4:   <PropertyGroup>

   5:     <ApplicationName>MySolutionApplicationName>

   6:     <SolutionFile>..$(ApplicationName).slnSolutionFile>

   7:   PropertyGroup>

   8:   <Target Name="Clean">

   9:     <MSBuild Targets="Clean" Projects="$(SolutionFile)"/>

  10:   Target>

  11:   <Target Name="Build" DependsOnTargets="Clean;" >

  12:     <MSBuild Targets="Rebuild" Projects="$(SolutionFile)" Properties="Configuration=Release;" />

  13:   Target>

  14: </Project>


Psake: The PowerShell Drink Of Choice

Runtime: Powershell / .NET

Build Configuration Language: Powershell Script (C#)


Psake (pronouced like the Japanese rice wine alcohol) is a suite of PowerShell scripts that lets you write .NET code as powershell scripts (.ps1 files) and modules. Since powershell is built into current versions of windows server and desktop operating systems, it is quick and mostly painless to get up and running. It leverages the existing command line knowledge and code writing capabilities of developers by integrating both of those skillsets into one solution. If you want a native windows command line that provides power and capbilties along the lines of a bash shell in *nix, with a build system geared toward the power user, powershell and Psake are your solution.

Example: Clean your solution then build it (“borrowed” from Alan Bradley)

   1: task default -depends Build


   3: task Build -depends Clean{

   4:   msbuild "C:UsersAlanCodePowerShellpsakeHelloWorldHelloWorld.sln"

   5: }


   7: task Clean {

   8:   msbuild "C:UsersAlanCodePowerShellpsakeHelloWorldHelloWorld.sln" /t:clean

   9: }


Rake: The ‘Cool’ Kid

Runtime: Ruby, IronRuby for .NET, JRuby for Java, etc

Build Configuration Language: Ruby / Rake DSL


… I’ll be the first to tell you that I can’t give an objective opinion about ruby… so keep that in mind. :)

Ruby and Rake have been shaking up the .NET world for a few years now, with many of .NET’s best and brightest jumping ship away from the classic .NET build systems for this one. It seems that all the ‘alt’ kids and cool cats are heading for these green pastures and with Microsoft having released IronRuby v1.0 recently, there is even more potential for the popularity of this system in .NET. With the flexibility of the Ruby language, the built in gem system and the thousands of available libraries, the potential functionality within a rake build script is staggering.

Rake, like Psake, is targeted at the command-line-junky that wants to get things done quickly but doesn’t feel constrained to the Microsoft-only tools.

Example: Calling out to MSBuild to build a solution

   1: task :default do

   2:   msbuild = "C:/Windows/Microsoft.NET/Framework/v3.5/msbuild.exe"

   3:   return_code = system "#{msbuild} src/example.sln /p:configuration=release /target:clean;build /asdfasdf"

   4:   fail "msbuild failed!" unless return_code == 0

   5: end


Albacore: Dolphin-Safe Rake Tasks For .NET Systems

Runtime: Ruby / Rake + various command line tools

Build Configuration Language: Ruby / Rake Tasks


… Do I really need to say anything, here? I suppose I should, being the big tuna behind this project. :)

Albacore is a suite of Rake tasks that targets the most common needs for .NET systems at build-time, including some configuration management and package & deployment tools. What started as a “hey wouldn’t it be cool if…” conversation has quickly turned into a growing community of contributors and users around the world. There’s a lot of cooperation between the albacore tasks and the other popular build systems, too, with tasks that call out to nant and msbuild for example. The UppercuT project even has rake / albacore integration built into it. This cooperation with other systems makes the choice of which tool to use less important, as you can use the right tool for the job at hand, all from one central location.

Albacore is targeted at the Rake users that want to get their .NET system builds up and running quickly, while still allowing the full flexibility and capabilities of the Rake system.

Example: Build and test a solution

   1: require 'albacore'


   3: task :default => [:build, :unittests]


   5: msbuild :build do |msb|

   6:   msb.solution = "src/example.sln"

   7:   msb.targets :clean, :build

   8: :configuration => :release

   9: end


  11: nunit :unittests do |nunit|

  12:   nunit.path_to_command = "nunit/nunit-console.exe"

  13:   nunit.assemblies "src/tests/bin/release/tests.dll"

  14: end


Bake: The Sexy Little DSL; and Phantom: So Simple, It’s Scary

Runtime: .NET

Build Configuration Language: Boo DSL for builds

URL: and 

… At this point, I’m not sure about the state of this project or it’s adoption in the real world. Does anyone know if it’s still alive and/or being used anywhere? You may be better off looking at the Phantom build system, which is similar to Bake, but appears to be an active project.

Bake is “A build system written in Boo, inspired by Rake.”. It’s based on the Boo language – an object oriented DSL creation language for the .NET runtime. Also known as the “Boo Build System”, this particular project was subject to quite a bit of potty humor for a while, before being renamed to Bake. :) The Boo language allows you to write your own Domain Specific Language (DSL) to run on the .NET platform, and Bake provides a DSL specifically for builds.

Bake and Phantom are targeted at the .NET developer that wants a simple DSL for creating builds, want a Rake like syntax, but want to keep the runtime dependency limited to the .NET platform.

Example: Using Phantom to build and test a solution

   1: target compile:

   2:   msbuild(file: "path/to/somefile.sln", configuration: "release")


   4: target test:

   5:   test_assemblies = ("path/to/testassembly.dll", "path/to/AnotherTestAssembly.dll")

   6:   nunit(assemblies: test_assemblies, toolpath: "path/to/nunit.console.exe" })


Fake: The Functional Build System

Runtime: .NET

Build Configuration Language: F#


Fake is the F# build system – a functional language that run on the .NET platform with a DSL for builds on top of it. Fake provides “all benefits of the .NET Framework and functional programming can be used, including the extensive class library, powerful debuggers and integrated development environments like Visual Studio 2008 or SharpDevelop, which provide syntax highlighting and code completion.

Fake is targeted as developers who like the simplicity and elegance of a functional language and still want the powerful and capabilities of the .NET runtime and tooling.

Example: Running NUnit tests

   1: (* define test dlls *)

   2: let testDlls = !+ (testDir + @"/Test.*.dll") |> Scan


   4: Target? NUnitTest <-

   5:     fun _ -> 

   6:         testDlls

   7:           |> NUnit (fun p -> 

   8:                       {p with 

   9:                          ToolPath = nunitPath; 

  10:                          DisableShadowCopy = true; 

  11:                          OutputFile = testDir + "TestResults.xml"})


Make: The One. The Original.

Runtime: everywhere (usually associated with C/C++ though)

Build Configuration Language: Make files

URL (the best one I know of):

Make isn’t old-school… that’s like saying cave drawings are old school email letters or instant messages. No, Make isn’t old school… it’s the original. Make is the grand daddy of all the build systems and deserves our respect. Although I doubt that the original make system could do much more for a .NET developer than shell out to a command line tool, there are dozens (if not hundreds or thousands) of Make ancestors that are likely to be very capable in building .NET code. The namesake alone is still alive and well, with Rake – the “Ruby Make” system, Bake – the “Boo Make” system, Fake – the “F# Make”, etc. All of us – every developer that works in any modern language – owe a lot to Make for getting us started way back when. Whether or not you realize it, you are using a tool that has it’s roots in Make.


How Do I Know Which To Choose?!

With all of these options available making choices can be a daunting task. What it ultimately comes down to, though, is what you and your team are comfortable with. I love to push albacore as a build too for .NET as anyone that knows me will attest. However, I have also been known to say that it’s the wrong choice for some teams. Getting a build script and an automated build in place, combined with a Continuous Integration server, is the goal. Picking the build tool to do that is an implementation detail that should not get in the way of the goal. If your team does not have ruby / rake experience, albacore might not be the right tool for you. If your team does not like xml, Psake might be the right tool for you. You need to understand what your team is capable of today and what they want to be capable of tomorrow, to understand which tool is right for you.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in .NET, Build Tools, Continuous Integration, Pragmatism, Product Reviews, Tools and Vendors. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • What I want to know is ‘where is cake’? I’ve actually been playing around with executing c# linqpad scripts, calling out to msbuild tasks. Doesn’t have all the targets stuff, but the intellisense sure is nice.

  • Don’t forget the fabulous FinalBuilder (!

  • Rob

    @Harry could tell it was you just by the comment :)

    Can’t remember where, but someone has written cake. Can’t find the blog article on google though.

    I use ruby which is nice. I do miss intellisense, although there are ruby IDE’s out there with intellisense. Something nice and familiar about writing it in C# I guess.

    As much as I like Ruby, the pain was learning it. In that the earlier build scripts are a bit crap, so having to return to them. If there was a C# equivalent I may not have had that pain.

    Don’t use albacore, although I use it for reference. Big fan of build conventions at the moment. Give rake a directory, and with code in place to apply conventions, it’ll figure out how to build your solution.

  • Very nice post. I always wanted to find a round-up of all the build tools for .NET.

    One question for you though… Once MSBuild came out, I had always just assumed MSBuild was now the best solution, because having the same exact build on a dev machine as on the build machine is pretty important.

    But looking at the examples you show for each of these, it looks like they end up calling MSBuild anyway. I don’t see any CSC.exe in there. Is that true? And if so, are you just using MSBuild to do the C# compilation, but doing the other stuff like copying files, calling NCover etc in the other part of the build script?

  • Bonder

    There is a huge technical gaffe in this article.

    Sake is rice beer, not rice wine. Many people classify it as wine based on it’s color and opacity, but should really pay more attention to the fact that it is mafe by fermenting starches (like beer), not sugars (like wine).

    Please double-check your research for your next article about alcohol.


  • @bonder – D’OH! I have been shamed by my lack of booze related prowess. :D

    @harry – ‘the cake is a lie!’ ok, i couldn’t resist. :) … haven’t heard of that one, though. sounds interesting.

    @rob – want to contribute some of those conventions to albacore?! :)

    @john – most of the build tools out there in the world call out to msbuild.exe in order to build a vs solution or project file. this is done because it’s easy. so… yeah… that’s why i said ‘one microsoft way’ in my comment about msbuild :)

    i am working on a csc task for albacore, though. hope to have that useable in the next few weeks… maybe month… not sure.

  • Just because it fits in here… : I played with providing an MSBuild overlay that isn’t XML – This is possible beause there is an API to call into. This is not much more than a Proof of Concept but it gives easy access to the MSBuild Tasks available out there as well as having a nice Powershell script integration. For the last one, psake is certainly my recommendation, being the real thing in PowerShell terms…

  • Check out my project at ;)
    (It’s in a very early stage at the moment. I have been started working on it just a couple of days ago.)

    By the way this is a very good post, thanks.

  • I personally use Phantom because it is .NET and does not have XML. MSBuild/NAnt are too full of XML, and Rake needs me to install whole new language (and doesn’t natively work with managed assemblies).

    By the way, latest version of Phantom supports NAnt tasks natively.

  • Good post.

    Would have been better if you had examples of doing the same task(s) for each build tool.

  • @jag – thanks. yeah, i agree about getting hte same task. i tried to find the same thing for them all, but had a hard time finding good examples for some of the tools. i suppose i could have put a little more effort into it. :P

  • CDHDeveloper

    This was great!

    Love to see the same as far as deployment tools. We’re in the midst of trying to get a handle on that fiesty monster of deployment now and many have many differing concepts.

  • Did you look at Automated Build Studio ( or FinalBuilder ( I’ve been using FinalBuilder for about 5 years and it’s pretty powerful and simple to use.

  • ok… HUGE oversight on my part!!! I forgot about FinalBuilder, Automated Build Studio and VisualBuild… again… i don’t know why I constantly forget about those tools.

    can anyone provide some info / target audience / comfort zones for these tools?

  • @Derick

    Regarding Finalbuilder, it truly is and was (back before even MSBuild/Nant was widely known), a build system on steroids. A lot of people discard it because of the visual aspect of it (forgetting that it’s commercial for a moment), but in terms of productivity and the sheer amount of actions (tasks in MSBuild terms) it offers, is unbelievable. It also offers conditionals, branches, exception handling (better than what MSBuild does). It is also extensible since it allows you to create your own actions. I’ve done everything from it from compiling and building installers, to actually automating deployment and notification of new product versions to customers.

  • RhysC

    Good article.
    For people getting in to build tools heres how i decide what im going to use ( have used all with the exception of fake):
    - If we have SyAdmins that use Powershell and we only do M$ development I use Psake
    -If we do varied dev (ie M$ plus ruby etc) use rake/albacore
    -If we only do M$ dev but the team will freak out with PShell then use MSbuild with Community Extensions and custom taks and teach them powershell so you can migrate to Psake
    PSake replaced NAnt as an option for me when it came out, i wish ChuckNorris would move to it as it is the dogs bollocks of utility projects. IMO Nant has all the negatives of MSBuild (well, with a few bonus feature) but lacks all the flexibility of PS. Plus PS keeps Sysdamins happy if they can read you deployment scripts


  • RhysC

    oh and i hate the finalbuilder stuff due to the insane misuse of the products. The products themselves are fine (they really are!) the people that use/abuse them is what peeves me off. Learning to scripts is a valuable skill

  • @RhysC (and all others for that matter): UppercuT (of ChuckNorris framework) is moving to a code based solution v2. We are starting work on that soon. We are completely removing NAnt except for allowing you to still create NAnt custom tasks, just like we do now in addition to PSake and Rake custom tasks.
    One thing we will be adding is CSharp custom tasks as well.

    And it will still be a conventional build tool.