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.


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

  • So, why should we bother migrating from solution files to an MSBuild 'makefile'? First you have to tell u why you are even considering it? Isn't the solution file enough?
    – jgauffin
    Nov 1, 2013 at 12:27
  • 3
    Because it's reputed to be better practice. For your last question; maybe it is, maybe it isn't. That's why this question to explore it for a clearer answer. Nov 1, 2013 at 22:11
  • 2
    Because it's reputed to be better practice where?
    – jgauffin
    Nov 1, 2013 at 22:21
  • 3
    Segregation of the IDE (sln file) from the build is certainly a good SE design. Jeff's written about it at codinghorror.com/blog/2007/10/… if you desire details. Plus it's nice to fire up tests and even software packaging (setup.exe or msi) as part of the release build script instead of just compiling the build. Nov 3, 2013 at 6:31
  • 1
    @jgauffin: sedodream.com/2010/03/19/…
    – Josh Noe
    Jun 2, 2014 at 20:24

4 Answers 4


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.

  • 1
    So you use the sln+csproj in Visual Studio and then the same as-is csproj's + custom msbuild script on the build server? I've clarified question a bit. Thanks! Nov 1, 2013 at 3:24
  • Yes, they are functionally the same. Nov 1, 2013 at 13:32

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.

  • What are you thoughts on the latter part, on the potential overlap of the various components? I've (hopefully!) clarified the question a bit more ... thx Nov 1, 2013 at 3:22

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

  • 1
    What does using msbuild files instead of sln files have to do with not having to install SharePoint in the build server? These are completely unrelated concepts. The solution file does not carry any dependency on anything. Also, you can certainly rely on solution files to manage your build, since this is what our company has been doing for years without issues. I think you may be confusing solution and msbuild files with the msbuild tool itself, which also supports solution files. We are not using visual studio to compile the solution in the build machine.
    – julealgon
    Apr 24, 2015 at 20:43
  • +1 for your explanation of "Your organization has only one team project". It pains me to see people using multiple Team Projects as boundaries for things like 'products' or 'projects' in such small shops. I took the single team project approach and hopefully will never have to go back.
    – JohnZaj
    Apr 5, 2016 at 23:05

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.

  • 1
    ++ I was just having this argument with our lead today. Your build should be runnable from anywhere, not just a GUI on some cloud service.
    – RubberDuck
    Sep 9, 2016 at 22:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.