Reset current directory on Core#2978
Conversation
Full-framework MSBuild was resetting the current directory at the end of build requests and at node idle, which helps avoid holding handles to project directories that the user may wish to delete while a worker node is still alive in the background. That wasn't done on .NET Core because at the time of the original port, there wasn't an `Environment.SystemDirectory` to use. That property is now available, but returns the empty string on Linux, which fails `Directory.SetCurrentDirectory()`. So I'm avoiding it by using the current MSBuild tools directory, which should exist as long as the MSBuild process keeps running. Fixes dotnet#2977.
| #endif | ||
| // On Windows, a process holds a handle to the current directory, | ||
| // so reset it away from a user-requested folder that may get deleted. | ||
| NativeMethodsShared.SetCurrentDirectory(BuildEnvironmentHelper.Instance.CurrentMSBuildToolsDirectory); |
There was a problem hiding this comment.
Please check my logic about the new default value for this!
I can also do an if-windows conditional.
There was a problem hiding this comment.
Can setting cwd to a bogus value have any external behaviour? Files written, node failure logs, etc? If yes, do an if-windows conditional. If no, it doesn't really matter.
There was a problem hiding this comment.
AFAIK none of that depends on CWD . . .
jeffkl
left a comment
There was a problem hiding this comment.
Can we get rid of the feature flag or is it still used somewhere? (I'm on my phone otherwise I would look it up myself)
|
macOS: Possible issue connecting to GitHub or cloning the repository. This could be caused by a lack of network connectivity or a lack of disk space. Please email netciadmin. @dotnet-bot test OSX10.13 Build for CoreCLR please |
|
The feature flag is sadly still used, in a confusing place for bad reasons. Those tests still need to be disabled, but I couldn't come up with a better name for the flag that describes how they're broken. Totally open to suggestions! |
|
Hmm, perhaps the tests should just not use |
| #if FEATURE_ENVIRONMENT_SYSTEMDIRECTORY | ||
| // Somehow the startup directory vanished. This can happen if build was started from a USB Key and it was removed. | ||
| NativeMethodsShared.SetCurrentDirectory(Environment.SystemDirectory); | ||
| #endif |
There was a problem hiding this comment.
Why the inconsistency with the other changes? Not that it matters, right?
|
@dotnet-bot test this please (don't trust stale results from February, but want this in) |
|
@dotnet-bot test Ubuntu16.04 Build for CoreCLR please An odd hang: |
Full-framework MSBuild was resetting the current directory at the end of build requests and at node idle, which helps avoid holding handles to project directories that the user may wish to delete while a worker node is still alive in the background. That wasn't done on .NET Core because at the time of the original port, there wasn't an
Environment.SystemDirectoryto use.That property is now available, but returns the empty string on Linux, which fails
Directory.SetCurrentDirectory(). So I'm avoiding it by using the current MSBuild tools directory, which should exist as long as the MSBuild process keeps running.Fixes #2977.