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

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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 which is like NAntContrib.