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 your experience with any of the two?
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.)
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.
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:
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.
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).
I've done a similar investigation this week. Here's what I've been able to determine:
NANT:
MSBuild:
Subjective Differences: (YMMV)
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:
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.
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 arived, nant died. And Mono will have a 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 configs.
Personally, I'd love to hear some real arguments for NAnt, because I just can't think of any that really hold water.
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:
Adding dependencies to your project. The NANT build file is alien to VS (in my case I consider this a pro) so VS 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 VS 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.
I don't trust VS as far as I could throw its dev team. This stems back to the early days of VS 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 VS can screw up dependencies and version nrs in the dll (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 VS to build in debug mode only. For production I use NANT so that I control everything externally. VS just cannot interfere any longer if I build using NANT.
PS I'm a web developer. No Winforms development.
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.
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:
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.
We use both - nAnt is responsible for all "scripting" stuff, like copying, deploying on IIS, creating packages and MSBuild is responsible for building solution. That we can avoid problems with non supported .Net 4.0 by new version of nAnt. nAnt is also more scalable, if we want to migrate the deployment scripts to Production servers, we only copy build file and install proper version of .Net, no VS's, problems with csproj files:)