Freigeben über

MSBuild tracing using MSBUILDDEBUGCOMM

  • Artikel

[This blog was written by my colleague: Prabhat Tandon]

We know that building in parallel feature is not new in MSBuild.

Here is how it works. When we start a build using IDE/command-line options, the first instance or the parent MSBuild instance starts. The project / solution dependency graph suggests if parallel builds can be spawned or not. If yes, the parent MSbuild process spawns several new instances.

Between the child and the parent instances, there is a handshaking that needs to take place.

In case of unsuccessful handshaking, newer instances cannot be spawned and ultimately the entire build process may fail. It was felt that we should know where the failure is.

Following is the basic criteria for successful handshaking:

  • The location and version of “microsoft.build.dll” loaded by parent and child msbuild instances should be same.

Recently I was working on an issue where an antivirus was interrupting the build process and we were getting MSB4014 error.

MSbuild team has come up with a logging mechanism which can help us diagnose whether the handshaking between different instances of MSBuild is successful or not.

This mechanism is dependent on the environment variable MSBUILDDEBUGCOMM which enables tracing.

Here is how we can do this:

  1. Make sure no instance of MSBuild.exe are running and that any instance of MSBuild_CommsTrace_xxxx.txt files in %TEMP% are removed.
  2. Close all instances of Visual Studio if any.
  3. Set the environment variable MSBUILDDEBUGCOMM=1.
  4. Run visual studio in that environment. (We can also open up a Visual Studio Command Window from the start menu, set the environment variable, then run devenv.exe.).
  5. Build the project / solution.
  6. Click Start->Run->%TEMP%
  7. Some files will get generated to called MSBuild_CommsTrace_xxxx.txt.

A typical successful build may produce something like : 

Waiting for connection 900000 ms...
Handshaking with host..
Entering read loop.

This may help us to determine if there is any blockage occurring in the communication between the Visual Studio IDE and its external nodes which are used to build C++ projects.

P.S. – This option may change / be removed in future versions of MSbuild.

Comments

  • Anonymous
    September 06, 2012
    There are other circumstances that can cause this, such as for some reason MSBuild.exe not being able to launch properly, or a bug in MSBuild. These logs will help figure out the problem and you can attach them if you encounter this and wish to open a Connect bug report.