Is nAnt still supported and suitable for .net 3.5/VS2008?

Question

I am using MSBuild to build my stuff. I want to use CruiseControl.net as by Build Server.

Now, CCNET refers nAnt a lot, but it looks as if ccnet can do most of the stuff nant could do through the project configuration and msbuild. Also, nAnt seems a bit unsupported, with a Beta release that is almost a year old now.

In short: I am actually quite happy with MSBuild (especially since it's the "official" compiler front end) and a bit uncomfortable with nAnt, but I do not want to judge prematurely.

What would be reasons to use nAnt over MSBuild? Especially with ccnet, which seems to overlap a bit with nant in terms of features (and adding the automated build related stuff)

Answer 1

In my opinion it is more a question of personal preference. nAnt is a great framework and MSBuild is almost as capable. With the ability to easily develop custom tasks (in both frameworks) you can accomplish almost anything that you need to do.

I cannot answer the "still supported" portion of your questions, but I would say if you are already comfortable with nAnt then it's probably viable. If you (or someone in your group) is familiar with MSBuild then that is a fine way to go as well.

Answer 2

Honestly it depends on what fits in to your environment better. If you are using a lot of Non-Microsoft tools, nunit, ccnet, ncover. You will probably find better support with nant. Alternatively if you are using MSTest, TFSBuild, you will probably find MSBuild a better environment. I would learn both and use which every fits more smoothly with your environment.

Answer 3

If you've already got a bunch of custom tasks you use with nAnt, stick with it - you don't gain much with MSBuild. That said, there doesn't seem to be anything that nAnt can do that MSBuild can't at its core. Both can call external tools, both can run .Net-based custom tasks, and both have a bunch of community tasks out there.

We're using MSBuild here for the same reason you are - it's the default build system for VS now, and we didn't have any nAnt-specific stuff to worry about.

The MSBuildCommunityTasks are a good third-party task base to start with, and covers most of the custom stuff I ever did in nAnt, including VSS and Subversion support.

Answer 4

If you are quite happy with MSBuild, then I would stick with MSBuild. This may be one of those cases where the tool you learn first is the one you will prefer. I started with NAnt and can't quite get used to MSBuild. I'm sure they will both be around for quite some time.

There are some fundamental differences between the two, probably best highlighted by this conversation between some NAnt fans and a Microsoftie.

Interestingly, Jeremy Miller asked the exact opposite question on his blog last year.

Answer 5

CC.NET is simply the build server technology, not the build script technology. We use CC.NET at work to very successfully call MSBuild build scripts with no problems.

NAnt is an older and more mature build scripting language, but they are both similar in how they work. There are very few things I could do in NAnt that I can't also do in MSBuild, so it really comes down to which one you are more comfortable with. As far as how active NAnt is, don't go by when the last release was...instead go by when the last nightly build was. NAnt tends to go a long time between releases, but the nightly builds are usually pretty stable.

Answer 6

Like what so many people have already indicated, the answer here is "it depends". There are some things like repeating operations that are much simpler and cleaner in NAnt. See the MSDN forums for a discussion about this.

Answer 7

I find that you can also use a hybrid approach too, especially in larger projects. A lot of our nant scripts are being converted to msbuild when new components are developed. Both support the same major features and can call each other if you find a task that is natively supported in one but not the other.

For new .NET development starting with MSBuild can save you a lot of time since it can run the solution files directly. Extending from the main compilation to perform other tasks (source control, deployment, etc) works quite well.