Best .NET build tool [duplicate]

Question

Possible Duplicate:
NAnt or MSBuild, which one to choose and when?

What is the best build tool for .NET?

I currently use NAnt but only because I have experience with Ant. Is MSBuild preferred?

Entreat

Do have a look at Fake. – Vinificator

Answer 1

We actually use a combination of NAnt and MSBuild with CruiseControl. NAnt is used for script flow control and calls MSBuild to compile projects. After the physical build is triggered, NAnt is used to publish the individual project build outputs to a shared location.

I am not sure this is the best process. I think many of us are still looking for a great build tool. One promising thing I heard recently on .NET Rocks, episode 362, is James Kovac's PSake, a build system he based entirely on PowerShell. It sounds really promising since what you can do with PowerShell is fairly limitless in theory.

Incinerator

Hey Peter - we do the same thing, but we templated the NAnt and make it reusable. What we ended up with we released as a product called UppercuT - projectuppercut.org – Windmill

I'll check it out. I've thought a number of times about templating the NAnt script, but haven't gotten around to it. The biggest pain point in our process is the tedious copy/paste/edit cycle to get a new project configured for build. It's easy because we have well defined conventions now, but, as I said, tedious ... Thanks for the info. – Incinerator

Answer 2

I'd just like to throw FinalBuilder in to the mix. It's not free, but if you're fed up with editing XML files and want a somewhat nicer (IMO) environment to work in I would give it a go.

I've worked with all of them and have always went back to FinalBuilder.

Incalescent

+1 from me. FinalBuilder is a great tool, no doubt. – Maiga

I have used FinalBuilder and it helped me to speed things up a lot. It was easier to use years ago, though, now it seems to have become complicated as well. Much faster than other options though. – Usance

Answer 3

I use MSBuild completely for building. Here's my generic MSBuild script that searches the tree for .csproj files and builds them:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
  <UsingTask AssemblyFile="$(MSBuildProjectDirectory)\bin\xUnit\xunitext.runner.msbuild.dll" TaskName="XunitExt.Runner.MSBuild.xunit"/>
  <PropertyGroup>
    <Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
    <DeployDir>$(MSBuildProjectDirectory)\Build\$(Configuration)</DeployDir>
    <ProjectMask>$(MSBuildProjectDirectory)\**\*.csproj</ProjectMask>
    <ProjectExcludeMask></ProjectExcludeMask>
    <TestAssembliesIncludeMask>$(DeployDir)\*.Test.dll</TestAssembliesIncludeMask>
  </PropertyGroup>

  <ItemGroup>
    <ProjectFiles Include="$(ProjectMask)" Exclude="$(ProjectExcludeMask)"/>
  </ItemGroup>

  <Target Name="Build" DependsOnTargets="__Compile;__Deploy;__Test"/>

  <Target Name="Clean">
    <MSBuild Projects="@(ProjectFiles)" Targets="Clean"/>
    <RemoveDir Directories="$(DeployDir)"/>
  </Target>

  <Target Name="Rebuild" DependsOnTargets="Clean;Build"/>

  <!--
  ===== Targets that are meant for use only by MSBuild =====
  -->
  <Target Name="__Compile">
    <MSBuild Projects="@(ProjectFiles)" Targets="Build">
      <Output TaskParameter="TargetOutputs" ItemName="AssembliesBuilt"/>
    </MSBuild>
    <CreateItem Include="@(AssembliesBuilt -> '%(RootDir)%(Directory)*')">
      <Output TaskParameter="Include" ItemName="DeployFiles"/>
    </CreateItem>
  </Target>

  <Target Name="__Deploy">
    <MakeDir Directories="$(DeployDir)"/>
    <Copy SourceFiles="@(DeployFiles)" DestinationFolder="$(DeployDir)"/>
    <CreateItem Include="$(TestAssembliesIncludeMask)">
      <Output TaskParameter="Include" ItemName="TestAssemblies"/>
    </CreateItem>
  </Target>

  <Target Name="__Test">
    <xunit Assembly="@(TestAssemblies)"/>
  </Target>
</Project>

(Sorry if it's a little dense. Markdown seems to be stripping out the blank lines.)

It's pretty simple though once you understand the concepts and all the dependencies are handled automatically. I should note that we use Visual Studio project files, which have a lot of logic built into them, but this system allows people to build almost identically both within the Visual Studio IDE or at the command line and still gives you the flexibility of adding things to the canonical build like the xUnit testing you see in the script above.

The one PropertyGroup is where all the configuration happens and things can be customized, like excluding certain projects from the build or adding new test assembly masks.

The ItemGroup is where the logic happens that finds all the .csproj files in the tree.

Then there are the targets, which most people familiar with make, nAnt or MSBuild should be able to follow. If you call the Build target, it calls __Compile, __Deploy and __Test. The Clean target calls MSBuild on all the project files for them to clean up their directories and then the global deployment directory is deleted. Rebuild calls Clean and then Build.

Tracheostomy

Answer 4

There is another new build tool (a very intelligent wrapper) called NUBuild. It's lightweight, open source and extremely easy to setup and provides almost no-touch maintenance. I really like this new tool, and we have made it a standard tool for our continuous build and integration of our projects (we have about 400 projects across 75 developers). Try it out.

http://nubuild.codeplex.com/

• Easy to use command line interface
• Ability to target all .NET Framework versions, that is, 1.1, 2.0, 3.0 and 3.5
• Supports XML based configuration
• Supports both project and file references
• Automatically generates the “complete ordered build list” for a given project – No touch maintenance.
• Ability to detect and display circular dependencies
• Perform parallel build - automatically decides which of the projects in the generated build list can be built independently.
• Ability to handle proxy assemblies
• Provides a visual clue to the build process, for example, showing “% completed”, “current status”, etc.
• Generates detailed execution log both in XML and text format
• Easily integrated with CruiseControl.NET continuous integration system
• Can use custom logger like XMLLogger when targeting 2.0 + version
• Ability to parse error logs
• Ability to deploy built assemblies to user specified location
• Ability to synchronize source code with source-control system
• Version management capability

Irrelievable

It looks interesting. But now is .NET 4.5, it doesn't seem to update. – Priestcraft

Answer 5

We use MSBuild, because we started with Visual Studio 2005 (now Visual Studio 2008), and MSBuild was already "built in" to the SDK - there is less maintenance on the build server. It's a NAnt clone, really - both tools are infinitely flexible in that they let you create custom build tasks in code, and both have a decent set of community build tasks already created.

• MSBuild Community Tasks
• NAntContrib

Papert

Answer 6

Rake and Albacore is an excellent combination. The power of Ruby and no XML.

.NET Open Source 5 - .NET Automation with Rake and Albacore by Liam McLennan [Tekpub.com]

Man

it was an epic vid, I am starting to use this too as my build tool :), once you have watched the vid look at code-magazine.com/Article.aspx?QuickID=1006101 – Serow

Answer 7

We're using Bounce, a framework for cleaner build scripts in C#.

Tangent

Answer 8

I use a commercial software, Automated Build Studio for the build purpose.

Buyers

Answer 9

I've used both and prefer NAnt. It's really hard for me to say one is "better" than the other.

Monterrey

Answer 10

I have used both MSBuild and NAnt, and I much prefer MSBuild, mainly because it requires a lot less configuration by default. Although you can over-complicate things and load MSBuild down with a lot of configuration junk too, at its simplest, you can just point it at a solution/project file and have it go which, most of the time, for most cases, is enough.

Durrett

Answer 11

It also depends on what you're building. The MSBuild SDC Task library has a couple of special tasks. For example, for AD, BizTalk, etc.

There are over 300 tasks included in this library including tasks for: creating websites, creating application pools, creating ActiveDirectory users, running FxCop, configuring virtual servers, creating zip files, configuring COM+, creating folder shares, installing into the GAC, configuring SQL Server, configuring BizTalk 2004 and BizTalk 2006, etc.

Edlun

Answer 12

Using a dynamic scripting language like Python, BOO, Ruby, etc. to create and maintain build scripts might be a good alternative to an XML based one like NAnt. (They tend to be cleaner to read than XML.)

Katt

For .NET centered projects first choice would/should be PowerShell if going dynamic scripting language. – Saturated

Answer 13

Generally speaking, I get the impression that NAnt offers more flexibility compared to MSBuild, whereas (with my relatively simple needs) I've been fine with the latter so far.

Malley

Answer 14

UppercuT uses NAnt to build 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://projectuppercut.org/

Some good explanations here: UppercuT

Windmill

First link is dead. Project is probably no longer in active development. – Example

UppercuT is getting ready to implement Cake, so development is about to kick back off. But you are right, that link needed updated. – Windmill