NAnt or MSBuild, which one to choose and when?

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.

When should one choose NAnt over MSBuild? Which one is better for what? Is NAnt more suitable for home/open source projects and MSBuild for work projects? What is the experience with any of the two?

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.

One of the major draws of MSBuild for me (on Windows platforms) is that it comes as part of .NET itself. That means that any Windows machine that is up-to-date with Windows Update will have MSBuild available. Add to this the fact that C# compiler is also part of .NET itself and you have a platform that can build projects on clean machines. No need to install Visual Studio behemoth. NAnt, on the other hand, has to be explicitly installed before a build can be triggered.

Just for the record, I've used NMake, Make, Ant, Rake, NAnt and MSBuild on non-trivial builds in the past (in that order). My favourite is MSBuild, hands down (and I do not favour it because "that's what Visual Studio uses"). IMHO, it is a very under-appreciated build tool.

I would compare NAnt vs. MSBuild to the difference between procedural and functional programming. NAnt is quite straightforward and you-get-what-you-see. MSBuild on the other hand requires a bit more thought. The learning curve is steeper. But once you "get it", you can do some amazing things with it.

So I would recommend looking at MSBuild if you also gravitate towards functional or logical style programming - if you are willing to invest a bit of time and effort before seeing tangible results (of course, I also strongly believe that the investment eventually pays off and you can do more powerful things more efficiently).

Personally, I use both - for the same project.

MSBuild is great at building Visual Studio solutions and projects - that's what it's made for.

NAnt is more easily hand-editable, in my opinion - particularly if you already know Ant. NAnt can call MSBuild very easily with NAntContrib. So, I hand-craft a NAnt script to do things like copying built files, cleaning up etc - and call MSBuild to do the actual "turn my C# source code into assemblies" part.

If you want an example of that, look at my Protocol Buffers build file. (I wouldn't claim it's a fabulous NAnt script, but it does the job.)

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)

KISS = Use MSBuild.

Why add something else into the mix when you have something that will do a reasonable job out of the box? When MSBuild arrived, NAnt died. And Mono will have an MSBuild implementation, (xbuild).

DRY = Use MSBuild.

Ask yourself what do you want out of a build system? I want a build system that is also used by my IDE rather than the maintaining two different configurations.

Personally, I'd love to hear some real arguments for NAnt, because I just can't think of any that really hold water.

One thing I noticed several posters mention was having to hand edit the .csproj (or .vbproj, etc.) files.

MSBuild allows customization of these .*proj files through the use of .user files. If I have a project named MyCreativelyNamedProject.csproj and want to customize the MSBuild tasks inside of it, I can create a file named MyCreativelyNamedProject.csproj.user and use the CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets to customize those files.

Also, both NAnt and MSBuild can be customized to the heart's content through custom MSBuild tasks and through NantContrib extensions.

So, using NAnt or MSBuild really comes down to familiarity:

• If you are already familiar with Ant, use NAnt. The learning curve will be very easy.
• If you are not familiar with either tool, MSBuild is integrated with Visual Studio already and requires no additional tools.

It is also worth adding that MSBuild is pretty much guaranteed to work with all new versions of .NET and Visual Studio as soon as they are released, whereas NAnt may have some lag.

I use both in that my NAnt scripts call MSBuild. My main reason for staying with NAnt is isolation. Let me explain why I feel this is important:

1. Adding dependencies to your project. The NAnt build file is alien to Visual Studio (in my case I consider this a pro) so Visual Studio does not attempt to do anything with it. MSBuild tasks are embedded so part of the solution and can refer to other MSBuild tasks. I've received source code from someone else only to find out I could not build, because the MSBuild community tasks were not installed. What I find particularly frustrating is that Visual Studio just would not build and threw a bunch of errors that made me loose time debugging. This, despite the fact that the build being requested could have gone ahead (as a debug build for instance) without some of the extras of the MSBuild task. In short: I don't like adding dependencies to my project if I can avoid it.

2. I don't trust Visual Studio as far as I could throw its development team. This stems back to the early days of Visual Studio when it would massacre my HTML. I still do not use the designer for instance (at a conference recently I found colleagues did the same). I have found that Visual Studio can screw up dependencies and version numbers in the DLL file (I cannot replicate this, but it did happen in a project consistently and caused a lot of grief and lost time). I have resorted to a build procedure that uses Visual Studio to build in debug mode only. For production, I use NAnt so that I control everything externally. Visual Studio just cannot interfere any longer if I build using NAnt.

PS: I'm a web developer and do not do Windows Forms development.

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:

• http://msbuildtasks.tigris.org/">MsBuildTasks</a></li>
• http://nantcontrib.sourceforge.net/">NantContrib</a></li>

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.

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.

I have switched from NAnt to MSBuild recently because of its ability to build VS solutions. I still use NAnt occasionally, though.

You may also want to check out [MSBuild Community Tasks][1] which is like NAntContrib.

[1]: http://msbuildtasks.tigris.org/ "MSBuild Community Tasks"

The documentation and tutorials available for NAnt make it easier to begin learning build scripts with NAnt. Once I got the hang of NAnt and creating build scripts I started translating that knowledge to MSBuild (I did X in NAnt, how do I do X in MSBuild?). Microsoft's documentation usually assumes a pretty high level of knowledge before it is useful.

The reason for switching from NAnt to MSBuild is because MSBuild is more current. Unfortunately the last release of NAnt was in December 8 2007, while MSBuild 4.0 (.NET 4.0) isn't far off. It looks like the NAnt project has died.

If you find good documentation for someone just beginning to learn creating build scripts using MSBuild, then skip NAnt and go straight for MSBuild. If NAnt ever comes out with a new release then I'd consider sticking with NAnt, but they're lagging behind now.

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:)

YDeliver by Manoj is a build framework built on top of PSake. It has a rich set of library functions, ability to define workflows, and we have used it to deliver over six enterprise projects to production.

Use it in conjunction with TeamCity, CruiseControl, or anything that can run PowerShell.

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