Why would I want to continue to use Nant when MSBuild is available?

Question

I have seen the prior questions and answers. In that one question, the original poster asked a followup question:

what are the compelling reasons to use msbuild? are there cons?

I didn't see the answer to that. I'd like to know the converse, too. What are the compelling features of Nant?

I think, for nant, cross-platform is big. For msbuild, it is the currency and integration with Visual Studio. Does this sound right? Anything else?

EDIT/Added: anyone have a feature list comparison? Someone said "nant has more features out of the box." Which ones?

Would it make sense to combine these projects, combine efforts so as to benefit mutually? Has anyone asked MS if they'd be willing to contribute msbuild to the community, like WiX? What are the chances?

EDIT2: I just found this prior discussion, not sure why I couldn't find it before.

Instantaneity

Re cross-platform - note that mono will read csproj (msbuild) too. – Mountainous

oooo, cool. Mono's build tool is...? – Instantaneity

sorry - I should have re-phrased that; nant will happily work with msbuild files – Mountainous

Answer 1

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 Y. Hashimi (Sep, 2008)

Taradiddle

I had the exact opposite experience. I found MSBuild scripts confusing and NAnt scripts intuitive. I'd suggest people compare the tools for themselves and draw their own conclusions. – Mycosis

Answer 2

I simply find NAnt easier to use. I dare say this is partly due to my background in Ant, but I found building a NAnt file for Protocol Buffers to be a much simpler job than building an MSBuild file for MiscUtil. (Even now there are things in the MiscUtil build which I'd like to include but can't - it seems ridiculously hard to dump the output of a task to a text file, IIRC.) The concepts are simpler, and there seem to be fewer gotchas in terms of when file collections are evaluated etc.

I currently like using a setup which I previously thought was really silly - I use NAnt for my "main" build file, but invoke MSBuild to do the actual "compile my .NET project" step. The idea of having two build systems for the same project is abhorrent, but I basically don't treat the MSBuild part as a full build system - it's just an easy way of compiling, and I never need to manually examine the project file. (I only interact with it via Visual Studio.) I've been able to evolve my Protocol Buffers build very easily this way, and I doubt I'd have had the same experience if I'd used MSBuild.

Soon I'm going to try building it all with Mono (when 2.4 is released - until then there are showstoppers in gmcs) at which point we'll see how portable the strategy is...

Woolgathering

How did that go? Three years on, how do you feel about build systems? Would you still recommend "msbuild inside nant"? – Bounden

@Weeble: For Protocol Buffers, we're now using MSbuild entirely - but I doni't understand the build system, frankly. For Noda Time I don't even really have a build system. I've seen good things about psake, and need to get to grips with that some time... – Woolgathering

Answer 3

You would continue using nant because you are already using it. If you were using msbuild, and wanted to know why would you switch to nant, then the answer is theres no real reason to switch. At least you know msbuild isnt going anywere, nant hasnt been updated since december 2007.

Ephesus

Answer 4

Considering that NAnt is based off Ant for Java, that there might be reason enough to stick with it. Other build tools are based off Ant - Phing is one, for PHP. When I started using that tool, I picked it up in no time since I was already familiar with NAnt.

Markley

Answer 5

We use a hybrid approach because we started on NANT before MS-Build was available. However MS-Build cna do parallel buids on projects that are not dependent which can in the right circumstances reduce your build times significantly. Leaving NANT to interact with SVN, deployment and just having MS-build do compilation cut our build times by about 45% YMMV depending on how you structure your sln.

Slosberg

Answer 6

Some points that came to mind:

• you must use msbuild if you are working with Windows Workflow Foundation (compiling *.xoml files, probably this is also true for WPF)
• if you are using wix for building setup .msi file you can use VisualStudio or msbuild to compile wix scripts (in case of error VS can jump to problematic line in wix script)
• msbuild allows you to have build environment as much similar to development/Visual Studio environment (for example when building with msbuild postbuild events are executed, you don't have to manually maintain a list of *.cs files to csc task, ...)

Where I work we are currently using NAnt scripts with msbuild task from NAntContrib.

Cominform