Add MSBUILDFORCEMULTITHREADED env var to force multi-threaded mode#13662
Merged
Conversation
Agent-Logs-Url: https://github.com/dotnet/msbuild/sessions/99214eff-5790-464b-a89a-3c51c3e8a1d5 Co-authored-by: JanProvaznik <25267098+JanProvaznik@users.noreply.github.com>
Copilot created this pull request from a session on behalf of
JanProvaznik
April 30, 2026 15:02
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Adds an environment-variable escape hatch to force MSBuild’s multi-threaded (in-proc node) mode, mirroring existing patterns where env vars can drive CLI behavior when command lines can’t be modified.
Changes:
- Introduces
Traits.ForceMultiThreadedbacked byMSBUILDFORCEMT=1. - Updates
XMake.IsMultiThreadedEnabledto short-circuit to multi-threaded mode when the trait is set. - Documents the new environment variable in the environment-variable reference.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/MSBuild/XMake.cs | Honors Traits.Instance.ForceMultiThreaded to force-enable multi-threaded mode. |
| src/Framework/Traits.cs | Adds a new trait that reads MSBUILDFORCEMT from the environment. |
| documentation/wiki/MSBuild-Environment-Variables.md | Documents MSBUILDFORCEMT=1 alongside other MSBUILDFORCE* variables. |
AR-May
reviewed
May 4, 2026
AR-May
left a comment
Member
There was a problem hiding this comment.
Consider adding some tests for the parameters parsing logic.
Agent-Logs-Url: https://github.com/dotnet/msbuild/sessions/f193f24e-7408-43e0-85cd-d540744399e1 Co-authored-by: JanProvaznik <25267098+JanProvaznik@users.noreply.github.com>
Contributor
Author
Added three unit tests for the parsing/trait-resolution logic in |
Copilot
AI
changed the title
Add MSBUILDFORCEMT env var to force multi-threaded mode
Add MSBUILDFORCEMULTITHREADED env var to force multi-threaded mode
May 4, 2026
…o BuildParameters Agent-Logs-Url: https://github.com/dotnet/msbuild/sessions/d2a55112-0f8e-493e-bfc4-8499bb384f7a Co-authored-by: JanProvaznik <25267098+JanProvaznik@users.noreply.github.com>
JanProvaznik
approved these changes
May 4, 2026
AR-May
approved these changes
May 5, 2026
This was referenced May 6, 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.
Fixes #13606
Context
There was no environment-variable equivalent of the
-multiThreaded/-mtswitch, making it awkward to opt in to multi-threaded mode in scenarios where the command line cannot be modified (CI, IDE, wrapper scripts). Other switches (e.g.MSBUILDDISABLENODEREUSEfor-nodeReuse) already follow this pattern.Changes Made
src/Framework/Traits.cs— addedTraits.ForceMultiThreaded, readingMSBUILDFORCEMULTITHREADED == "1", alongside the existingForceAllTasksOutOfProcToTaskHost.src/MSBuild/XMake.cs—IsMultiThreadedEnabledshort-circuits totruewhenTraits.Instance.ForceMultiThreadedis set; otherwise falls back to the existing parameterized switch. The method was promoted fromprivatetointernalfor direct unit-test coverage (matching the pattern of neighboringProcessMaxCPUCountSwitch).documentation/wiki/MSBuild-Environment-Variables.md— documented the new variable next to the otherMSBUILDFORCE*entries.src/MSBuild.UnitTests/XMake_Tests.cs— added three unit tests for the parsing/trait-resolution logic:"1"→ multi-threaded enabled even without-mt."1"value (e.g."true") → not enabled (only literal"1"is honored, matching neighboringMSBUILDFORCE*flags).src/MSBuild.UnitTests/MSBuildMultithreaded_Tests.cs— added an end-to-end integration test (MSBuildForceMultiThreadedEnvironmentVariablePropagatesToBuildParameters) that launches a real MSBuild process withMSBUILDFORCEMULTITHREADED=1and no/mtswitch, then runs the existingEnvironmentIsolationTestTaskwithIsMultithreadedMode='true'. The task observes whetherTaskEnvironmentis isolated from the global environment, which is only true whenBuildParameters.MultiThreaded == true. This proves the env var flows end-to-end:Environment→Traits.ForceMultiThreaded→IsMultiThreadedEnabled→ localmultiThreaded→parameters.MultiThreaded.Testing
dotnet build src/MSBuild/MSBuild.csprojandsrc/MSBuild.UnitTests/Microsoft.Build.CommandLine.UnitTests.csproj— 0 warnings, 0 errors.Microsoft.Build.CommandLine.UnitTestsrunner with--filter-method "*MSBuildForceMultiThreaded*"(4 succeeded, 0 failed).MultiThreaded Mode - TaskEnvironment is isolated from global environment (PASS), confirming the env var propagates toBuildParameters.MultiThreaded.Notes
"1", matching the convention of neighboringMSBUILDFORCE*flags.MSBUILDFORCEMULTITHREADEDwas chosen over the initialMSBUILDFORCEMTfor clarity, per reviewer feedback.