MSBuild Server correctness validation when building VMR

[jankratochvilcz]

Context

When MSBuild Server is enabled by default we need confidence that VMR builds — which are the primary CI consumer — produce identical results to the non-server build.

Investigation via an agent-driven exploration surfaced a small set of fixable bugs in server behavior; nothing fundamental was identified. The primary mitigation needed for general server enablement is the restore-task workaround tracked in #13315. Other static-state concerns in SDK tasks were analyzed and do not block enablement (and remain workaround-able via nodeReuse=false if needed).

Exit criteria

• VMR builds with MSBuild Server enabled produce byte-identical / functionally equivalent outputs to the non-server build.
• The restore-task workaround (Execute Restore tasks in the TaskHost node in /mt mode or when msbuild server is on. #13315) is in place.
• Any small server-side bugs surfaced during validation are filed and either fixed or knowingly accepted.

Out of scope

• Architectural questions about per-workspace server lifetime, cross-workspace caches, and the relationship between server and a future build orchestrator. Those are tracked separately.

[JanProvaznik]

Cross-referencing the broader MSBuild Server default-on analysis at #9379 (overnight investigation summary).

This issue is Infrastructure / Class A (within-VMR cross-repo server sharing).

Key finding: within each VMR vertical, all repos are built sequentially on the same agent sharing $(sourcesPath)/.dotnet — every dotnet build computes an identical ServerNodeHandshake hash, so repo N's server is reused by repo N+1. The CleanupRepo target in repo-projects/Directory.Build.targets calls dotnet build-server shutdown --vbcscompiler but never --msbuild. Two compounding factors:

1. The dotnet/sdk MSBuildServer.Shutdown() implementation has a known limitation — ProcessId is hardcoded to 0 so cross-invocation server shutdown is best-effort and may not reach the long-running server process at all.

2. PR Include effective temp directory in node-reuse handshake salt (fixes #13594) #13651 (which would have isolated servers per Path.GetTempPath() via the handshake salt) was closed as "too heavy" by the author on 2026-05-05.

Immediate zero-code-change mitigation: set MSBUILDNODEHANDSHAKESALT=$(RepositoryName) per-repo in the <Exec> EnvironmentVariables in repo-projects/Directory.Build.targets. This gives each repo its own server pipe identity. Adding --msbuild to the CleanupRepo shutdown call is belt-and-suspenders (limited by the SDK-side ProcessId=0 issue above).

Exit criteria mapping:

• Restore task workaround → PR Workaround: route NuGet RestoreTask to transient TaskHost in server or mt modes #13660 (open, blocked)
• Apphost crash → PR Fix TimeoutException when DOTNET_CLI_USE_MSBUILD_SERVER=true on .NET 10.0.300 #13716 (open)
• Per-repo isolation → VMR-side env var change above

Once those land + the VMR Directory.Build.targets change is in, the validation pipeline can flip server-on safely.