Prefer dotnet MSBuild.dll for out-of-proc worker nodes in CLI scenarios#13452
Merged
rainersigwald merged 2 commits intomainfrom Mar 30, 2026
Merged
Prefer dotnet MSBuild.dll for out-of-proc worker nodes in CLI scenarios#13452rainersigwald merged 2 commits intomainfrom
rainersigwald merged 2 commits intomainfrom
Conversation
YuliiaKovalova
force-pushed
the
yko/prefer-dotnet-host-for-cli-nodes
branch
from
9d2ce02 to
235f003
Compare
When MSBuild is launched via dotnet.exe (e.g. dotnet build, dotnet msbuild), BuildEnvironmentHelper resolves CurrentMSBuildExePath to MSBuild.exe (the AppHost) because it prefers .exe over .dll. This causes all out-of-proc worker nodes to launch as MSBuild.exe AppHost processes, incurring native bootstrap overhead per node. This change detects when the current process is dotnet.exe and the resolved MSBuild location is the AppHost, then substitutes MSBuild.dll so worker nodes are launched via dotnet.exe instead. This only applies to regular worker nodes (nodemode:1), not task host nodes (nodemode:2) which may need the AppHost for COM host object support. Fixes a ~16% regression in NuGet restore of OrchardCore (61s -> 72s) introduced by the AppHost PR #13175.
YuliiaKovalova
force-pushed
the
yko/prefer-dotnet-host-for-cli-nodes
branch
from
235f003 to
d9bf159
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts out-of-proc worker node launching when MSBuild is running under dotnet.exe (CLI-hosted), preferring dotnet MSBuild.dll over the MSBuild app host to reduce native bootstrap overhead while keeping task host behavior unchanged.
Changes:
- Extract
NodeModeearlier inGetNodes()to enable mode-specific launch decisions. - On .NET Core, when CLI-hosted and launching regular worker nodes (
/nodemode:1), substituteMSBuild.dllforMSBuild.exeif it exists alongside the app host.
src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs
Show resolved
Hide resolved
src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs
Show resolved
Hide resolved
YuliiaKovalova
force-pushed
the
yko/prefer-dotnet-host-for-cli-nodes
branch
2 times, most recently
from
47c3b6e to
e689cc0
Compare
YuliiaKovalova
force-pushed
the
yko/prefer-dotnet-host-for-cli-nodes
branch
2 times, most recently
from
1aaacab to
d1ba98d
Compare
YuliiaKovalova
force-pushed
the
yko/prefer-dotnet-host-for-cli-nodes
branch
from
d1ba98d to
dd9439d
Compare
ViktorHofer
approved these changes
Mar 30, 2026
JanProvaznik
added
the
merge-carefully
Member
|
Tests on dotnet/dotnet#5751 suggest that this mitigates the NuGet Perf DDRIT problem so let's do it. |
rainersigwald
approved these changes
Mar 30, 2026
This was referenced Mar 30, 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.
Summary
When MSBuild is launched via
dotnet.exe(e.g.dotnet build,dotnet msbuild),BuildEnvironmentHelperresolvesCurrentMSBuildExePathtoMSBuild.exe(the AppHost) because it prefers the AppHost overMSBuild.dll. This causes all out-of-proc worker nodes to launch asMSBuild.exeprocesses instead ofdotnet MSBuild.dll.Problem
PR #13175 introduced the MSBuild AppHost (
MSBuild.exe). After this change,dotnet buildspawns worker nodes asMSBuild.exeprocesses. ETL trace analysis of OrchardCore NuGet restore shows a ~16% regression (61s -> 72s):The root cause of the performance difference between
MSBuild.exeanddotnet MSBuild.dllhosting is not fully understood from available ETL data. Reverting worker nodes todotnet MSBuild.dllin CLI scenarios restores baseline performance.