Differences between Visual Studio (.sln) build runner and MSBuild

Question

I'm trying to set TeamCity to do a CI using .Net and configuring build runners I have:

1. Visual Studio (sln)
2. MSBuild
3. Visual Studio 2003

What's the difference? Why three build to work on the same type of project? (With the exception of 2003 which is only for 2003 I believe, Why?)

Taking the issue, we have this build runners for .exe files:

1. .NET Process Runner
2. Command Line

The "Command Line" build runner not works with any .net assembly? Why the .Net Process Runner?

Solution 1

Visual Studio (sln)
If your solution is small and you are not required to do fancy things you can use Visual Studio (sln) build runner. It does exactly the same thing as when you do Project->Build (from VS menu). This option is very easy to configure, a few clicks and your CI server compiles your solution.

MSBuild
If you need to do more advanced scenarios, apart from simple compilation, like apply different config files, insert transformed values into config file, deploy binaries etc, you would select MSBuild option. You will know when you need to use this, simply because sln builder will not be capable of doing stuff. This option requires some knowledge of build scripting language, which is a task-based and xml-like.

Solution 2

When you use MSBuild to build a .SLN file ( non MSBuild document ) it generates an in memory MSBuild file that references all of the projects to build in the specified configuration and then executes it. When you use Visual Studio to build you are calling DevEnv.com instead.

There are certain project types ( C++ in 2005/2008 and VDPROJ in 2005/2008/2010 ) that aren't MSBuild files and can't be build using just MSBuild. You will get a build warning saying that one or more projects were not valid MSBuild projects and could not be built.

In geneneral I try to maintain lean and mean build machines and only install Visual Studio if needed.

Comments

[Acaz Souza]

thanks for answer. Visual Studio (sln) use MSBuild behind the scenes, not?

[Rich]

VS can build some project types that MSBuild can't (e.g. setup projects). Or at least that was my experience of VS 2008 – maybe it's more in sync by now.

[oleksii]

@Acaz Well, yes, but it is all hidden from you. You actually use MSBuild when you do it in VS (Project->Build), but you simply don't know that. Same process here, for simplicity you can configure your CI to compile the project straight away.

[Christopher Painter]

There are also tools out there such as OpenMake Build Meister which does much better anaylsis of project relationships and targets that are out of date and needs to be rebuilt then generates it's own MSBuild files to allow for better threading across multiple solutions. For example I worked on a system that had dozeuns of solutions and thousands of projects and we were able to get our build times drastically reduced.

[Acaz Souza]

@oleksii MSBuild is a simple compiler for .Net projects or more? (I think this is another question in StackOverflow)

[oleksii]

MSBuild is a task-oriented build tool. It can compile, run unit tests, deploy binaries, archive, perform config-file transformation so on. For all this it uses other tools or libraries. For example, to compile C# solution it use scs.exe. To run NUnit tests it can use nunit-console.exe. So in a nutshell it is a wrapper that allows you to automate build, test, deploy process of your product.

[Acaz Souza]

@oleksii To complete the answer you know about differences in ".NET Process Runner" and "Command Line" build runners in TeamCity?

[MoonStom]

Sorry but that's not it. I'm starring at a green build using a Visual Studio runner on a server where I installed just the MSBuild Tools and the Windows SDK, both free products which can be downloaded from the MS site.

[Nikhil Agrawal]

You mean DevEnv.exe.

[Christopher Painter]

No. Take a look at your Common7\IDE folder and you'll see a DevEnv.exe and a DevEnv.com. If you do a devenv.exe /? you'll get a modal window with command line options. If you do a devenv.com /? it'll all be displayed on stdout . If you do an echo %PATHEXT% you'll see .COM listed before .EXE. So when you call DevEnv during a build you are actually calling DevEnv.com so that all the stderr and stdout can be harvested and processed into your logfiles.

[Christopher Painter]

I will say that my lean and mean comment at the end reflected my opinion from 2005-2012ish era. It's a good goal but not really practical anymore. While MSFT has the build tools and pull in a lot via Nuget the reality is there are frequently edge cases where you simply need to install the full Visual Studio workload. Kind of sad IMO but it is what it is.