Advantages of using MSBuild or NAnt versus running DevEnv.exe from command-line

Question

Can anyone explain what advantages there are to using a tool like MSBuild (or NAnt) to build a collection of projects versus running DevEnv.exe from the command-line?

A colleague I had worked with in the past had explained that (at least with older versions of Visual Studio) using DevEnv.exe was much slower than the other techniques, but I haven't read any evidence of that or if that is now a moot point now that starting with 2005, Visual Studio uses MSBuild under the hood.

I know one advantage of using MSBuild allows you to build your projects without requiring Visual Studio to be installed on the build machines, but I wasn't sure if there were others.

Antilogism

Answer 1

One reason is because there's much more to building a product than just compiling it. Tasks such as creating installs, updating version numbers, creating escrows, distributing the final packages, etc. can be much easier because of what these tools (and their extensions) provide.

While you could do all this with regular scripts, using NAnt or MSBuild give you a solid framework for doing all this. There's a lot of community support for both, including additional tasks that can be downloaded (such as the MSBuild Community Tasks Project). Plus, there's support for them in numerous third party and open source products.

If you're just interested in compiling (and not the entire build process), you may find one time saving benefit of MSBuild is the support for building with multiple processors.

Marileemarilin

Answer 2

The obvious answer from my team is that not everbody has visual studio installed, in particular we do not install Visual Studio onto our build/CI servers.

Chemotaxis

Why not on the build server? Seems strange to have your build use a different mechanism to the one your developers are using. Visual Studio solutions control the project dependencies and you must be manually maintaining this on your build server opening you up to the chance that your production build is different. – Stirrup

NOT installing VS200x forces you to know you actually need to produce a deployable product. If you have third party products installed on a dev box, they may work for a developer build. But if you put it on a machine that ONLY has msbuild, you'll know earlier (rather than later) that you are missing (and thus will have to distribute) some ThirdParty.dll. Aka, it takes some voodoo out of it. Our build machine (CCNET) is NOT allowed to have VS200x on it. Thus when we create .zip or .msi deploys, we know exactly what needs to be included. Otherwise, you're guessing. – Chrissa

Answer 3

The prime reason for using an external build tool like NAnt or MsBuild is the ability to automate your build process and thus provide continous feedback on the status of your system. Also they can be used for loads of things besides a "pure" build and that's where you really start to get value from them, it's an extremly valuable thing to be able to build and test your application with a single command.

You can also start adding stuff like collection of metrics, packinging of release binaries and all sorts of nifty stuff like that.

Assault

Thanks for the reply. I understand the advantage of automating the build process, I guess I was looking for a distinction between automating via tools like MSBuild or NAnt as opposed to calling DevEnv.exe from a batch or script file. – Antilogism

Answer 4

As far as C# goes, devenv.exe 2005 runs the compiler in-proc, which may cause out of memory exceptions for sizable solutions. Msbuild resorts to launching csc.exe process for each project. Projects that don't compile with devenv /build work fine with msbuild. Hope you like this reason.

Ned

Answer 5

We are experimenting with switching from DevEnv to a tool (Visual Build Pro) that uses MsBuild under the hood and we got a "Reference required to assembly 'System.Drawing..." error for a project which doesn't need it and which builds fine in Visual Studio.

Chillon

Answer 6

We have a large system consisting of C#, managed C++, and plain old unmanaged C++ assemblies/dlls. There is C++ code that depends on managed C++ code that depends of C# code that depends of managed C++ code that depends on plain old C++ code (whew!). When we were setting up our automated build environment a few years ago we discovered that MSBuild.exe didn't properly handle all of the dependencies that we have.

Working with Microsoft we were able to solve some of the issues but not all of them. If my memory serves me, we never could get the C# assemblies that depended on managed C++ dlls to build. So we ended up making a custom build script that called devenv.exe from the command line and it worked just fine.

Of course, that was with VS2005, it might be fixed now, but the script is still working so we haven't revisited the issue.

Award

We have the same problem with regard to dependencies, even with a pure native/C++ solution. Building with MSBuild only works reliably when doing a full rebuild; when doing incremental builds some project dependencies are not honoured, depending upon what files were changed. We'll probably have to resort to using devenv.exe inside a script also. – Zachariah