22

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?

Acaz Souza
  • 8,311
  • 11
  • 54
  • 97

4 Answers4

17

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.

oleksii
  • 35,458
  • 16
  • 93
  • 163
  • 1
    thanks for answer. Visual Studio (sln) use MSBuild behind the scenes, not? – Acaz Souza Feb 14 '12 at 13:23
  • 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. – Joey Feb 14 '12 at 13:24
  • @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. – oleksii Feb 14 '12 at 13:26
  • 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. – Christopher Painter Feb 14 '12 at 15:27
  • @oleksii MSBuild is a simple compiler for .Net projects or more? (I think this is another question in StackOverflow) – Acaz Souza Feb 14 '12 at 16:35
  • 3
    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. – oleksii Feb 14 '12 at 17:26
  • @oleksii To complete the answer you know about differences in ".NET Process Runner" and "Command Line" build runners in TeamCity? – Acaz Souza Feb 14 '12 at 17:31
3

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.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • You mean `DevEnv.exe`. – Nikhil Agrawal Sep 13 '18 at 05:49
  • 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 Sep 13 '18 at 12:32
  • 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. – Christopher Painter Sep 13 '18 at 12:34
0

I've noticed very little between the two. Specifically in our instance we needed to build a .vdproj. Now after googling there where two runners to do this, Command line runner or the Visual Studio (sln). However when doing the Visual Studio (sln) runner type we got the following error: "[Warning] C:\BuildAgent\work\1bd75058d7bca32b\POS\PoSWidgetInstaller\myInstaller.vdproj.metaproj warning MSB4078: The project file "myInstaller\myInstaller.vdproj" is not supported by MSBuild and cannot be built."

And it doesn't fail when built in the solution. I think Visual Studio (sln) runner type pulls the data from the sln file and then uses it with MSbuild. Not sure can't confirm but just my thoughts on it.

Nate
  • 11
  • 1
-1

If you use the solution files (Visual Studio) way that means you need to license a copy of Visual Studio for your build server along with the installation/maintenance that comes along with that. If you use MSBuild you don't need any of that, all you need are the .net framework installs. The only real difference between the two is that Visual Studio has all sorts of environment variables set and utilitizes things like build order. While MSBuild does not have any environment variables set by default, and doesn't recognize build order, it only reconginizes the depencies. It will be slightly easier though in Visual Studio and you won't run into those cases occasionaly where you were depending on visual studio to cover up some sloppiness.

Alex
  • 12,749
  • 3
  • 31
  • 45
  • 2
    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. – MoonStom Mar 30 '15 at 21:00