67

When Visual Studio runs a build, it runs MSBuild to do the majority of the work. If you pass the .sln file to MSBuild, with appropriate Configuration and Platform properties, it will build your solution similarly to how Visual Studio would.

msbuild mysolution.sln /p:Configuration=Release /p:Platform="Any CPU"

However, there are differences: sometimes a build will error through MSBuild and not through Visual Studio, or vice-versa.

What parameters does Visual Studio pass into MSBuild to influence the process? Is there some way to see the parameters it's passing as a build is is executed?

Paul Turner
  • 38,949
  • 15
  • 102
  • 166
  • 1
    Technically, it does not run `MSBuild.exe` but hosts the build engine internally, see my answer for more details. – Christian.K Aug 13 '12 at 11:18

2 Answers2

49

Visual Studio does not execute MSBuild.exe, but hosts the build engine itself (by means of the Microsoft.Build.* assemblies) - at least that is the case for the default C# project system. Other languages, addins, packages, etc. might do it differently.

Actually, there was a post series on the Microsoft blogs about this, I'm trying to find them and update this answer.

UPDATE: Found it again. Look for the "MSBuild in Visual Studio" posts here.

Concerning your original question, this page might help you further. Also you could go to "Tools", "Options", "Projects and Solutions", "Build and Run" and increase the MSBuild output verbosity. With "Diagnostic" you should basically see every property that is set upon starting the build.

Alan McBee
  • 4,202
  • 3
  • 33
  • 38
Christian.K
  • 47,778
  • 10
  • 99
  • 143
  • 1
    I could never see an external MSBuild process, so I expected the hosting was the case. The diagnostic setting sounds close to what I want, but it does make it harder to understand the equivalent MSBuild command-line syntax, if one even exists. – Paul Turner Aug 13 '12 at 12:03
  • @ProgrammingHero That's the point - there is no such command-line. You would have to come up with it by "reverse engineering" the properties, sort of. – Christian.K Aug 13 '12 at 12:08
  • I found this as a good reference article http://blogs.msdn.com/b/msbuild/archive/2006/01/06/508981.aspx. I would edit it into your answer, but thought it might be a bit presumptive. Perhaps you'd like to add this so I can accept your answer? – Paul Turner Aug 15 '12 at 12:26
  • Is this still true in 2015? Will this be true with Roslyn? – George Mauer Aug 28 '15 at 23:35
  • @GeorgeMauer Frankly, I have no idea and have not yet found the time to look into VS2015 at all ;-) But I _thought_ that Roslyn uses some sort of client/server compile architecture, no? If so, than I would guess that VS would only be another client (like the new csc.exe is another). But again, totally not sure here. – Christian.K Aug 29 '15 at 06:42
  • @Christian.K the link does not valid for "MSBuild in Visual Studio" posts – sorosh_sabz Aug 20 '20 at 21:15
12

First off, you can run msbuild with the /v:diag argument to get diagnostic-level logging. This can really help in figuring out why a build is failing.

Otherwise, yes, if you use Process Monitor, you can monitor for process start events where you can see the specific command-line sent to the process.

Specifically:

  • Run Process Monitor
  • Filter » Filter...
  • Operation is Process Create » Add
  • Operation is Process Start » Add
  • OK
  • Run your build through VS and through command-line msbuild
  • See the command-line arguments in the Detail column
Chris Schmich
  • 29,128
  • 5
  • 77
  • 94
  • 1
    This would be the way to go, if MSBuild was executed as a separate process; unfortunately, at least in Visual Studio 2010, it doesn't show up as a separate process. – Paul Turner Aug 13 '12 at 12:03