Don't compile CurrentThreadWorkingDirectory into every binary#13243
Merged
JanProvaznik merged 2 commits intodotnet:mainfrom Feb 12, 2026
Merged
Conversation
MultiThreadedTaskEnvironmentDriver sets FileUtilities.CurrentThreadWorkingDirectory. However, FileUtilities is linked into every MSBuild binary. That means that any reads of that property from other MSBuild binaries won't ever get the value that MultiThreadedTaskEnvironmentDriver set. Such reads can occur whenever FileUtilities.ItemSpecModifiers.GetItemSpecModifier(...) is called for "FullPath". The fix is to much the property to FrameworkFileUtilities, which is compiled (once!) into Microsoft.Build.Framework and is accessible everywhere.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR centralizes the per-execution “current working directory” used during property/item expansion so that all MSBuild binaries in-proc observe the same value (fixing incorrect relative path resolution in multithreaded builds when code crosses assembly boundaries).
Changes:
- Moved
CurrentThreadWorkingDirectoryfromMicrosoft.Build.Shared.FileUtilitiesintoMicrosoft.Build.Framework.FrameworkFileUtilities(as anAsyncLocal). - Updated item-spec modifier expansion (
%(FullPath)) and expander path helpers to readFrameworkFileUtilities.CurrentThreadWorkingDirectory. - Updated
MultiThreadedTaskEnvironmentDriverto set/clear the new centralized location.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Shared/Modifiers.cs | Uses FrameworkFileUtilities.CurrentThreadWorkingDirectory when currentDirectory is null for %(FullPath) expansion. |
| src/Shared/FileUtilities.cs | Removes the duplicated per-binary CurrentThreadWorkingDirectory static from shared FileUtilities. |
| src/Framework/FileUtilities.cs | Adds AsyncLocal-backed CurrentThreadWorkingDirectory to FrameworkFileUtilities (non-TASKHOST). |
| src/Build/Evaluation/Expander/WellKnownFunctions.cs | Updates Path.GetFullPath well-known function behavior to use the centralized working directory. |
| src/Build/Evaluation/Expander.cs | Updates expansion helpers to use FrameworkFileUtilities.CurrentThreadWorkingDirectory as the thread/async-local base directory. |
| src/Build/BackEnd/TaskExecutionHost/MultiThreadedTaskEnvironmentDriver.cs | Sets/clears the centralized working directory when ProjectDirectory changes / driver disposes. |
JanProvaznik
approved these changes
Feb 12, 2026
Member
JanProvaznik
left a comment
There was a problem hiding this comment.
thanks for catching this!
Member
|
Nice find! |
JanProvaznik
pushed a commit
to JanProvaznik/msbuild
that referenced
this pull request
Feb 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I spotted this issue while working on different code.
MultiThreadedTaskEnvironmentDriversetsFileUtilities.CurrentThreadWorkingDirectory. However,FileUtilitiesis linked into every MSBuild binary. That means that any reads ofFileUtilities.CurrentThreadWorkingDirectoryfrom other MSBuild binaries will never get the value thatMultiThreadedTaskEnvironmentDriverset. Such reads can occur wheneverFileUtilities.ItemSpecModifiers.GetItemSpecModifier(...)is called for "FullPath".The fix I've made is to move the property to
FrameworkFileUtilities, which is compiled (once!) into Microsoft.Build.Framework and is accessible everywhere.