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

I use MSBuild alongside Nant, because the current version of Nant can't as yet compile .NET 3.5 applications (same was true when .NET 2.0 first came out).

Answer 2

I feel that MSBuild and Nant are fairly comparable. If you are using one of these, I generally wouldn't switch between them unless there was a compelling feature that was missing in the product you had selected.

I personally use MSBuild for any new project, but your mileage may vary.

Hope that helps!

Edit: @ChanChan - @Jon mentions that Nant doesn't build .NET 3.5 applications. This may be enough of a reason to either change, or at least use them in parallel. As I've moved more towards MSBuild, I am probably not the most informed person to highlight any other showstoppers with either technology.

Edit: It appears Nant now builds .NET 3.5 Applications.

Answer 3

I think they're relatively comparable both in features and ease of use. Just from being C# based I find msbuild easier to work with than nants, though that's hardly a compelling reason to switch.

What exactly is nant not doing for you? Or are you just hoping there's some cool feature you may be missing out on? :)

One super-nice thing about C# is that if you have the .net framework, you have everything you need to run msbuild. This is fantastic when you are working on large teams / projects and have people/hardware turnover.

Personally I prefer SCons over both of them :)

Answer 4

I like MSBuild. One reason is that .csproj files are msbuild files, and building in VS is just like building at the command line. Another reason is the good support from TeamCity which is the CI server I've been using. If you start using MSBuild, and you want to do more custom things in your build process, get the MSBuild Community Tasks. They give you a bunch of nice extra tasks. I haven't used NAnt for several years now, and I haven't regretted it.

Also, as Ruben mentions, there are the SDC Tasks tasks on CodePlex.

For even more fun, there is the MSBuild Extension Pack on CodePlex, which includes a twitter task.

Answer 5

I'm actually still trying to figure this question out myself, but there is one big bonus for MSBuild here: using the same build file for local continuous integration by calling msbuild.exe directly, while also being able to use VSTS's server-side continuous integration with the same build file (albeit most likely different properties/settings).

i.e. as compared to TeamCity's support for MSBuild scripts, VSTS only supports MSBuild scripts! I've hacked around this in the past by exec'ing NAnt from MSBuild; I've seen others recommend this practice as well as the reverse, but it just seems kludgey to me, so I try not to do it if I can avoid it. So, when you're using "the full Microsoft stack" (VSTS and TFS), I'd suggest just sticking with MSBuild scripts.

Answer 6

The main reason I still use nAnt over msbuild for my automated builds is that I have more granular control on my builds. Due to msbuild using the csproj has it's build file, all the source in that project is compiled into one assembly. Which causes me to have a lot of projects in my solution for large projects where I am separating logic. Well with nant, I can arrange my build where I can compile what I want into multiple assemblies from one project.

I like this route, because it keeps me from having to many project files in my solution. I can have one project with folders splitting out the layers and then use nant to build each layer into it's own assembly.

However, I do use both nant and msbuild in conjunction for some build tasks, like building WPF applications. It is just a lot easier to compile a WPF application with the msbuild target within nant.

To end this and the point of my answer is that I like to use them side by side, but when I use msbuild in this configuration, it is usually for straight compiling, not performing any build automation tasks like copying files to a directory, generating the help documentation, or running my unit tests for example.