MSBuild and ConHost remain in memory after parallel build by Brett Shearer

"The ConHost really has nothing to do with MSBuild"

So why is there a conhost for every msbuild, and they appear and disappear in tandem?

I see the same problem. We are using the upgrade template in Visual Studio 2010 TeamBuild and sometimes the files in BuildType folder is locked and cannot be deleted. Very annoying. All other developers think that TeamBuild is unstable.

I will try the /nodereuse:false, but I have to set this in every build definition I have.

I don't think this is good design. The default value should definitely not have the potential to lock up the build system, as it does in our case. The gain on this as opposed to starting up brand new agents is neglizable in a life-sized project with a lot of code and a lot of tests.

We are seeing concrete problems with this "feature" (that's why I post here). The effect is that the get operation before the build kicks off (recursive on the configuration folder) is not able to get dlls that we later import in TFSBuild.proj. They are locked by MSBuild agents hanging around from the previous build.

So I vote for the sensible default setting beeing not to sacrifize reliability for performance in this case. Please change.

Thanks for taking the time to send us this feedback.

The behavior you are seeing is by design. MSBuild will continue running for 15 minutes after a build in case there is another build. This reduces the time for the build if you are building in the IDE or on the command line over and over again.

If you do not wish for MSBuild to hang around as above, you can use /nodereuse:false to when you invoke MSBuild.

The ConHost really has nothing to do with MSBuild. It is the Console host process which is a part of Windows.

For more information on ConHost, see for example: http://www.howtogeek.com/howto/4996/what-is-conhost.exe-and-why-is-it-running/

The NodeMode switch is used internally only, and is not supported for customer use.

I will close this issue as By Design.

Chuck England
Visual Studio Platform
Program Manager - MSBuild

Thank you for reporting this issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

After a little research I've found that the process will terminate after 15 minutes.

int millisecondsTimeout = Math.Max(0, BuildParameters.NodeConnectionTimeout - ((int) span.TotalMilliseconds));

internal static int NodeConnectionTimeout
{
    [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
    get
    {
        return GetTimeoutVariableOrDefault("MSBUILDNODECONNECTIONTIMEOUT", 900000);
    }
}

I've set my connection timeout to 5000 and have resolved the issue.

Perhaps the hidden parameter (/NODEMODE) should be documented.