Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Failed build leaves MSBuild processes lying around
See original GitHub issueI 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.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:15 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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 variableMSBUILDDISABLENODEREUSE=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.
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.