Skip to content

[wip experiment] Key transient MSBuild Server per build root, not one-per-machine - #14262

Closed
JanProvaznik wants to merge 1 commit into
mainfrom
dev/janprovaznik/mt-server-per-root
Closed

[wip experiment] Key transient MSBuild Server per build root, not one-per-machine#14262
JanProvaznik wants to merge 1 commit into
mainfrom
dev/janprovaznik/mt-server-per-root

Conversation

@JanProvaznik

Copy link
Copy Markdown
Member

Context

A /mt build with node reuse off (-nr:false, as dotnet restore does) engages the MSBuild Server purely to obtain Server GC, which /mt depends on for performance, and then shuts the server down after the build (added in #14248).

But the server's pipe and mutex names are one-per-machine (keyed by architecture/user/version/session). So when two such transient builds run at the same time, they contend for a single server: all but one find it busy and fall back to an in-process, Workstation-GC build — defeating the whole point of engaging the server under /mt.

Change

Key transient (non-reused) servers per build root instead of one-per-machine:

  • CanRunServerBasedOnCommandLineSwitches now emits a serverRootKey — the entry project's full path, or the current directory when no project is resolved — whenever shutdownServerAfterBuild is set (/mt + node reuse off).
  • Main folds that key into the MSBUILDNODEHANDSHAKESALT before handing off to the client. The salt drives the handshake hash that names the pipe and mutex, and the launched server inherits the client's environment, so both derive the same per-root names.
  • Parallel builds of different roots each get their own short-lived Server-GC server. Builds of the same root still share one server (the second concurrent build falls back), so it is "one transient server per root", not an unbounded number per invocation.
  • Reusable (non-transient) servers are unchanged and remain one-per-machine.

Testing

New unit test TransientServerIsKeyedPerRootAllowingConcurrentServers: two concurrent distinct-root -mt -nr:false builds run in two distinct, simultaneously-alive server processes, both with Server GC, and both shut down afterward. All existing MSBuildServer_Tests pass.

Verified live on the bootstrap:

  • 3 / 5 distinct roots in parallel → 3 / 5 distinct concurrent /nodemode:8 servers, each ServerGC=True, 0 survivors afterward.
  • Same-root contrast (3 clients, 1 root) → exactly 1 server (ServerGC=True); the other two fall back to in-proc Workstation-GC builds.
  • Real dotnet build muxer (DOTNET_CLI_USE_MSBUILD_SERVER=1), 2 roots → two distinct MSBuild.exe /nodemode:8 Server-GC servers concurrently, both transient.

Docs updated in documentation/MSBuild-Server.md.

A /mt build with node reuse off engages the MSBuild Server purely to get
Server GC, then shuts it down after the build (added in #14248). Because the
server's pipe and mutex names are one-per-machine (per architecture/user/
version), two such transient builds running at once contend for a single
server: all but one find it busy and fall back to an in-process, Workstation-GC
build - losing the Server GC that /mt depends on.

Key transient servers per build root instead: the entry project's full path
(or the current directory when none is resolved) is folded into the handshake
salt, which drives the pipe/mutex names. Both the client and the server it
launches (which inherits the client's environment) derive the same per-root
names, so parallel builds of different roots each get their own short-lived
Server-GC server. Builds of the same root still share one server (the second
concurrent build falls back), so it is one transient server per root, not an
unbounded number per invocation. Reusable (non-transient) servers are
unchanged and remain one-per-machine.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@JanProvaznik JanProvaznik changed the title Key transient MSBuild Server per build root, not one-per-machine [wip experiment] Key transient MSBuild Server per build root, not one-per-machine Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant