Why should I use MSBuild instead of Visual Studio Solution files?

Question

We're using TeamCity for continuous integration and it's building our releases via the solution file (.sln). I've used Makefiles in the past for various systems but never msbuild (which I've heard is sorta like Makefiles + XML mashup). I've seen many posts on how to use msbuild directly instead of the solution files but I don't see a very clear answer on why to do it.

So, why should we bother migrating from solution files to an MSBuild 'makefile'? We do have a a couple of releases that differ by a #define (featurized builds) but for the most part everything works.

The bigger concern is that now we'd have to maintain two systems when adding projects/source code.

UPDATE:

Can folks shed light on the lifecycle and interplay of the following three components?

1. The Visual Studio .sln file
2. The many project level .csproj files (which I understand an "sub" msbuild scripts)
3. The custom msbuild script

Is it safe to say that the .sln and .csproj are consumed/maintained as usual from within the Visual Studio IDE GUI while the custom msbuild script is hand-written and usually consumes the already existing individual .csproj "as-is"? That's one way I can see reduce overlap/duplicate in maintenance...

Would appreciate some light on this from other folks' operational experience

Answer 1

First point of fact is that the solution file pretty much magically becomes a MSBuild file when MSBuild executes it -- which is what happens when you build the solution in visual studio. In addition, all those project files are just msbuild files managed by visual studio. In fact, the project files handle most of the real dirty work here no matter if you are building from solutions or building from a custom msbuild script.

We also use TeamCity to build and publish applications and we will typically end up with custom msbuild scripts for most projects. The role these scripts play -- which isn't really easy with a solution file -- is packaging the project for deployment or distribution. Typically these scripts handle some more operational aspects of things -- like building the web project to a particular folder or copying in the running configurations as opposed to the development configurations. The heavy lifting tends to be handled in the project files themselves -- the build script just references those, we don't try and recreate that wheel. Overall it works great and it isn't really much duplicated code. Typically once we get the build scripts up we rarely have to touch them until there are massive changes in a project mandating massively changing the build.

Answer 2

The makefile for msbuild is the .sln file (or vcproj file).

A typical msbuild command line would be something like:

msbuild /p:Configuration=Release BigProject.sln

The point of using msbuild is so you can script and automate the build process. Whether you were aware of it or not, TeamCity has been using msbuild all along.

Answer 3

Let me offer my take on this question.

Although you certainly can simply use your .SLN file as your 'build process', the file itself really doesn't constitute a build process. The Solution file is really just a part of Visual Studio and is used for development. But Visual Studio is only a part of the build and release process. You can't rely on Solutions to manage your build, and Solutions certainly don't offer a scalable build situation.

The entire purpose of establishing a build process is to create reliable builds. That is to say, the build process is so reliable that no matter the build configuration, you will get a predictable build output. Every time, every machine. The result of a predictable and reliable build is that the test, deployment, and release process can then be highly automated, further reducing the risk of human error.

Establishing a build process requires an investment, but in certain cases, the investment is required. Here are some factors that favor an msbuild process:

• Your product has multiple teams (cross-functional or otherwise) who are working in the same team project
• Your organization has only one team project (should be the case for 99% of traditional shops, even those with 200+ developers)
• You have more than 20 projects that need to be built, some of which have dependencies on others and are maintained by different teams
• Your product incorporates multiple .NET technologies (C#, C++, VB, F#, ASP.NET, etc), or even non-.NET technologies (Grunt, node, npm, Java, etc)
• Your product has heavyweight dependencies or is built on top of a heavyweight platform. SharePoint, as an example

Let me give an example to expand on my last point. My current company does SharePoint development. SharePoint development at a minimum requires SharePoint foundation to be installed to perform builds on SharePoint projects. Speaking in terms of a lightweight build server, it's completely impractical to require the build server to have SharePoint installed. Not only is SharePoint a beast with high requirements but it would have serious performance implications on a build - and builds are supposed to be as fast and lean as possible. Leveraging MSBuild allows me to eliminate this installation requirement on the build server. In fact, our build server has no installation requirements other than the .NET framework (required by MSBuild) and Node.

As a reference, I would recommend checking out this book by Sayed Ibrahim Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr=8-1-fkmr0&keywords=msbuild+reliable+build

Answer 4

This is exactly the question I asked myself a few months ago! We had everything set-up nicely:

• Solution file nicely in the root of the repositories
• Build steps configured in Teamcity, like
  • Restore NuGet packages
  • Build solution
  • Run Unit Tests
  • Set-up integration test environment
  • Run integration tests
  • Tear down integration test environment
  • Create an deployment package
  • Build migration script

And then, when it comes to reproducibility, it became apparent that this scored low. When you let TeamCity be your build script it becomes hard to reproduce similar results, reliable, on your own development machine.

When you have a build script, the build script knows everything that needs to be done and has all the variables in place. When you use an CI server as your build script, and some issue happens, like a complex test failing or needing to build a deployment package manually (as per my example), you need to piece all the steps of the build together manually.

So, in short, why a (MS) build script? Because you will end up having more requirements when it comes to your build. You probably want to run some tests and generate some artifacts from that. You probably want to do deployments. And when everything you want needs to be runnable, whether it is on a build server or your machine, it can't end up anywhere but in a build script.