msbuild: Failed build leaves MSBuild processes lying around

I have a (closed-source) .NET Core project that uses some custom MSBuild tasks. The tasks are cross-built for both netcoreapp1.1 and .NET Framework 4.6, so that they will work properly in both dotnet build and Visual Studio.

However, when I run the build from within VS and it fails, three or four MSBuild.exe processes remain lying around, holding the DLL containing the tasks open, requiring me to taskkill them before I can replace the DLL with a version containing fixes for debugging. dotnet build does not appear to do this. I am using VS 2017 RC4 build 26206. As far as I can recall, this did not occur on previous builds of VS2017.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 2
  • Comments: 15 (3 by maintainers)

Most upvoted comments

When will this be fixed on a per project level? This issue is known and was called out since VS2008 every year.

It can’t really be that hard. The MSBuild processes started by Visual Studio are explicitly called WITH then /nodeReuse:true argument.

I’m quite sick and tired of this issue. Had it a few times over the years and every time i look for a solution which doesn’t require me to set a global environment variable does work only for MSBuild from the commandline but not in VS.

Bad, Microsoft, very bad. No, really, very bad.

This feature is called node reuse. You can turn it off on the command-line by running MSBuild.exe /nodeReuse:false (or just /nr:false). If you want it to not happen in Visual Studio you can set environment variable MSBUILDDISABLENODEREUSE=1. This features (for various reasons) is not supported in the .NET Core version of MSBuild so it will never happen.

That being said, the feature is there for performance. Your builds will be quite a bit slower with this turned off. It was added to avoid the overhead of process creation (with many projects and many cores it can be significant) and JIT.

I’m going to close this since it’s by design. Hopefully this answers your question though? If you think there’s really a behavior change between VS2015 and VS2017 feel free to re-open with repro steps. There should be no change.

I think it goes back to this old Q&A: Visual Studio 2008 locks custom MSBuild Task assemblies. The fundamental issue seems to be that there’s no way to tell UsingTask to load the task in a disposable AppContext, so the assembly ends up being loaded by the AppContext that VS keeps around… or something like that. After banging on this for a couple days, I’m coming to the conclusion that there is no way to use custom MSBuild tasks in a VS project without resorting to weird hacks like launching them from an inline task.

This is also happening to me, in any build, no matter if it succeeds or fails. Disable node reuse didn’t help. Any idea what else can I try?

@gabrielpra1 hey - I’ve set the environment variable

MSBUILDDISABLENODEREUSE = 1

That had solved the issue for me back then - haven’t worked on that project for a while now.

https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks#msbuildexe-nrfalse

$env:MSBUILDDISABLENODEREUSE = 1 This worked great in a Powershell solution build script, thank you! MSBuild processes are gone after the build script has completed now.

I have the same Problem as @fedeazzato . The MSBuild.exe is still running after a build.


If running msbuild from command line with: /nodeReuse:false everything works as expected, but using

<Project TreatAsLocalProperty="NodeReuse" ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSBUILDDISABLENODEREUSE>True</MSBUILDDISABLENODEREUSE> or <MSBUILDDISABLENODEREUSE>1</MSBUILDDISABLENODEREUSE>
    <NodeReuse>False</NodeReuse>

and compiling from visualStudio the MSBuild.exe is still running afterwards!

Just to be clear, the perf effect is only to save a few 100ms at the build start. As such it is not relevant in CI at all and IMO should always be disabled there. Perhaps in retrospect it would have been better to be opt-in and VS could opt in.

@gabrielpra1 hey - I’ve set the environment variable

MSBUILDDISABLENODEREUSE = 1

That had solved the issue for me back then - haven’t worked on that project for a while now.

https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks#msbuildexe-nrfalse