New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A build with /nodeReuse:false will reuse nodes that were left running by a previous build #339
Comments
|
It looks like we already have a "handshake" process to determine whether a given worker node is in the right elevation level, username, and so on. I think we can add "is allowed to be reused" to that safely. See https://github.com/Microsoft/msbuild/blob/ab862ac37e6c5c828dea9f2c5fc492d02310b8cb/src/XMakeBuildEngine/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs#L155 |
This allows a host to avoid reusing a node leftover from a prior /nr:true build if the current build is /nr:false. Required for dotnet#339.
This allows a host to avoid reusing a node leftover from a prior /nr:true build if the current build is /nr:false. Required for dotnet#339.
This allows a host to avoid reusing a node leftover from a prior /nr:true build if the current build is /nr:false. Required for dotnet#339.
|
This change has been ported to our internal repo as well, so it should be available in Update 2. |
…0226.2 (dotnet#339) - Microsoft.Dotnet.Toolset.Internal - 3.1.200-preview.20126.2 Dependency coherency updates - Microsoft.NET.Sdk - 3.1.200-preview.20126.2 (parent: Microsoft.Dotnet.Toolset.Internal)
|
Anyone still has this problem? Using VS 2019. Because of the processes left behind I have errors like this one: MSB3191 Unable to create directory "obj\Debug\net472". Access to the path 'obj\Debug\net472' is denied |
|
@petervlad please file a new issue describing your problem in detail. This issue would not have resulted in that error. |
Consider this:
Most people would expect the first build to leave child processes running (that being the point of the
/nodeReuseflag). The second shouldn't leave any new processes running.What's surprising is that the second build will reuse processes left over from the first build. That causes problems if you have per-node state, or if you're looking at I/O from the process cone of MSBuild.
This appears to be intentional but I can't justify the behavior. I think we should change
/nr:falseto always spawn new processes.The text was updated successfully, but these errors were encountered: