NAnt or MSBuild, which one to choose and when?

Question

I am aware there are other NAnt and MSBuild related questions on Stack Overflow, but I could not find a direct comparison between the two and so here is the question.

Answer 1

I ended up using both. When redesigning our build system, I was facing a tricky problem. Namely, I couldn't get rid of .vcproj (and family) because we everybody was using VS to update the project files, settings, and configurations. So without a huge duplication and error prone process, we couldn't base our build system on a new set of files.

For this reason, I decided to keep the 'proj' files of VS and use MSBuild (they are MSBuild files, at least VS2005 and VS2008 use MSBuild project files). For everything else (custom configuration, unit testing, packaging, preparing documentation...) I used NAnt.

For continuous integration, I used CruiseControl. So we had CC scripts that triggered NAnt jobs, which for building used MSBuild.

One final note: MSBuild does NOT support Setup projects! So you're stuck with calling DevEnv.com or using Visual Studio directly. That's what I ended up doing, but I disabled the setup project by default from all solution configurations, since developers wouldn't normally need to build them, and if they do, they can manually select to build them.

Answer 2

NAnt has more features out of the box, but MSBuild has a much better fundamental structure (item metadata rocks) which makes it much easier to build reusable MSBuild scripts.

MSBuild takes a while to understand, but once you do it's very nice.

Learning materials:

• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
  by Sayed Ibrahim Hashimi (Jan, 2009)
• Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
  by Y. Hashimi (Sep, 2008)

Answer 3

I've done a similar investigation this week. Here's what I've been able to determine:

NAnt:

• Cross-platform (supports Linux/Mono). It may be handy for installing a web site to multiple targets (that is, Linux Apache and Windows IIS), for example.
• 95% similar in syntax to Ant (easy for current Ant users or Java builders to pick up)
• Integration with NUnit for running unit tests as part of the build, and with NDoc for producting documentation.

MSBuild:

• Built-in to .NET.
• Integrated with Visual Studio
• Easy to get started with MSBuild in Visual Studio - it's all behind the scenes. If you want to get deeper, you can hand edit the files.

Subjective Differences: (YMMV)

• NAnt documentation is a little more straightforward. For example, the MSBuild Task Reference lists "Csc Task - Describes the Csc task and its parameters. " (thanks for the "help"?), vs the NAnt Task Reference "csc - Compiles C# programs." UPDATE: I've noticed the MSBuild documentation has been improved and is much better now (probably on par with NAnt).
• Not easy to figure out how to edit the build script source (*.*proj file) directly from within Visual Studio. With NAnt I just have Visual Studio treat the .build script as an XML file.
• Apparently, in Visual Studio, Web Application Projects don't get a *.*proj file by default, so I had great difficulty figuring out how to even get MSBuild to run on mine to create a deployment script.
• NAnt is not built-in to Visual Studio and has to be added, either with an Add-In, or as an "External Tool". This is a bit of a pain to set up.
• (Edit:) One of my coworkers brought this up--if you want to set up a build machine using CruiseControl for continuous integration, CruiseControl integrates with NAnt nicely out of the box. UPDATE: CruiseControl also has an MSBuild task.
• Please see comments below for full and up-to-date discussion of subjective differences.

Answer 4

We use FlubuCore. It's an open source C# library for building projects and executing deployment scripts using C# code.

Simple example of how flubu is used:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

You can find more information about flubu and how to get started here: choice-for-build-tool-msbuild-nant-or-something-else

Answer 5

While I'm not very familiar with MsBuild, I'm under the impression that some of key differences on both sides can be supplemented by additions:

• MsBuildTasks
• NantContrib

I recently had to build a Silverlight project in Nant. I discovered that life would be easier if I just did this with MsBuild - I ended up calling a MsBuild task from within a Nant script so I suppose it's not too out of the ordinary to mix and match the two.

Beyond that, I suppose it's going to be a question of personal preference - obviously you can manage some/most of MsBuild's functionality from within Visual Studio, if that's your thing. Nant seems more flexible and better suited if you prefer to write scripts by hand, and if you come from the Java world you'll likely be right at home with it.

Answer 6

We use both. NAnt is responsible for all "scripting" stuff, like copying, deploying on IIS, creating packages and MSBuild is responsible for building the solution. Then we can avoid problems with non-supported .NET 4.0 by a new version of NAnt.

NAnt is also more scalable. If we want to migrate the deployment scripts to production servers, we only copy the build file and install a proper version of .NET - no Visual Studio problems with csproj files:)