Should I switch from nant to msbuild?

Question

I currently use nant, ccnet (cruise control), svn, mbunit. I use msbuild to do my sln build just because it was simpler to shell out.

Are there any merits to switch

Answer 1

• Don't switch unless you have a very convincing reason (at least).
• NAnt is open source and if it weren't I wouldn't be able to customize our build system, MSBuild is not.
• NAnt can easily run MSBuild, I'm not sure about the other way around.
• MSBuild scripts are already written for you if you use VS2005 or newer (the project files are MSBuild files.)
• If you use NAnt, and you use VS to edit project files, settings and configurations, you'll have to write a converter/sync tool to update your NAnt files from the VS Project files.

Answer 2

MSBuild being integrated with Visual Studio gives programmers less friction to use the build system. It mainly comes down to them only having to go "Build Solution" and it all works, versus having to use Custom Build Steps and other such things, or, worse, forcing developers to build by launching some kind of external script.

Now, I mostly tend to prefer MSBuild over NAnt because it's simpler. Sure, NAnt has a lot more features, is more powerful, etc., but it can quickly get out of hand. If you and your build engineers have the discipline to keep the NAnt scripts simple, then it's all good. However, I've seen too many NAnt-based systems go south to a point where nobody understands what it's doing anymore, and there's no real way to debug it besides doing the equivalent of a good ol' printf. The moment you start using some if/else statement or for loop, that's where, IMHO, it starts smelling.

On the other hand, MSBuild has a solid foundation based on metadata and a less verbose syntax. Its simplicity (or lack of features... depending on how you see it) forces you to write logic in .NET code via new tasks, instead of writing logic in XML markup. This encourages re-usability and, above all things, lets you actually debug your build system in a real debugger.

The only problem with MSBuild is the not-so-occasional bug (especially in the first version) or obscure (although documented) behaviour. And, if that's the kind of thing that really bothers you, being tied to Microsoft.

Answer 3

I switched from NANT to MSBuild. The project is running in .Net 4.0.

My experience in Nant was good. The project kind of died. And when .Net 4.0 came along, it was time to re evaluate the build process.

Since Nant was last released MSBuild has come along ways. At this point, MSBuild is the way to go. It's easy to use, has many extensions. I rewrote my Nant scripts in a day and a half. The MSBuild script is 1/3 the size of the Nant scripts.

Much of the work in the Nant script was setting up the different environments. In MsBuild/.Net 4.0 it's built-in.

Answer 4

NAnt has been around longer, and is a considerably more mature product, and also IMO easier to use. There is a lot of community know-how out there to tap into, and it is also cross-platform, should you be interested in building apps that can run under Mono as well as .NET and Silverlight. Out of the box, it does a whole lot more than MSBuild does. Oh yes, and you can call MSBuild from NAnt (OK, from NAntContrib) :-)

On the negative side, NAnt and its sister project NAntContrib do seem to have stagnated, with the most recent update being late 2007.

The main advantages that I see of MSBuild is that it ships with the .NET Framework, so it's one less product to install; and there is more active development going on (albeit in places to catch up with the older NAnt).

Personally, I find its syntax a little more difficult to pick up, but then I'm sure continued exposure to ti would make things easier.

Conclusion? If you're working with existing NAnt scripts, stick with them, it's not worth the hassle of porting. If you're starting a new project, and you're feeling adventurous, then give MSBuild a go.

Answer 5

I don't see any reason to switch. MsBuild itself locks you into the framework you are using. If you use NAnt, you can use it across many frameworks and shell out to msbuild to actually do the building task for you.

I am a fan of NAnt in this respect, because it decouples you from the framework a little bit.

I have created a framework that puts conventions into automated builds and I built it on NAnt. It's called UppercuT and it is the insanely easy to use Build Framework.

Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!

http://code.google.com/p/uppercut/

Some good explanations here: UppercuT

Answer 6

My advice is just the opposite - Avoid MSBuild like the plague. NANT is far far easier to set up your build to do automatic testing, deploy to multiple production environments, integrate with cruisecontrol for an entry environment, integrate with source control. We've gone through so much pain with TFS/MSBuild (Using TFSDeployer, custom powershell scripts, etc) to get it to do what we were able to do with NANT out of the box. Don't waste your time.