TimeoutException when using DOTNET_CLI_USE_MSBUILD_SERVER=true in 10.0.300

[sebastienros]

Reproduced with the aspire default AppHost project microsoft/aspire#16849

When aspire sets DOTNET_CLI_USE_MSBUILD_SERVER=true to invoke dotnet build it throws.
10.0.300 only

[JanProvaznik]

Investigation: regression bisected to PR #13175 (vs18.5 → vs18.6)

Cross-referencing from microsoft/aspire#16849. Aspire CLI explicitly opts into the MSBuild server by injecting DOTNET_CLI_USE_MSBUILD_SERVER=true for AppHost builds (see src/Aspire.Cli/DotNet/DotNetCliRunner.cs, BuildAsync line 811-814, RunAsync line 523-527). That's why this only repros under aspire run and not plain dotnet build/dotnet run.

Bisect across release branches

Comparing vs18.3 (works, ships in SDK 10.0.204) vs vs18.6 (broken, ships in SDK 10.0.300):

Branch transition	Apphost-related changes
vs18.3 → vs18.4	none
vs18.4 → vs18.5	documentation/specs/msbuild-apphost.md only (spec only)
vs18.5 → vs18.6	DotnetHostEnvironmentHelper.cs, NodeLauncher.cs rewrite, MSBuildClient.cs, BuildEnvironmentHelper.cs, NodeProviderOutOfProc*.cs, AppHostSupport_Tests.cs

The implementation of #13175 (Add App Host Support for MSBuild) only landed in vs18.6, not vs18.5 — only the spec landed in vs18.5. PR #13501 ("Default to enumerating MSBuild processes") explicitly notes "Yes, worked in 18.5" for a related shutdown regression, which corroborates the vs18.5 → vs18.6 boundary.

What changed in MSBuildClient.TryLaunchServer

- using Process msbuildProcess = nodeLauncher.Start(_msbuildLocation, string.Join(" ", msBuildServerOptions), nodeId: 0);
+ using Process msbuildProcess = nodeLauncher.Start(new NodeLaunchData(_msbuildLocation, string.Join(" ", msBuildServerOptions)), nodeId: 0);

After #13175:

1. BuildEnvironmentHelper.CurrentMSBuildExePath resolves to the MSBuild apphost instead of MSBuild.dll (new TryFromMSBuildAppHost heuristic prefers the native exe).
2. NodeLauncher.ResolveExecutableName detects the apphost (Path.GetFileName == Constants.MSBuildExecutableName) and launches it directly instead of going through dotnet MSBuild.dll.
3. The NodeLaunchData constructed by MSBuildClient.TryLaunchServer does not set EnvironmentOverrides — compare with NodeProviderOutOfProc.cs which passes:

   EnvironmentOverrides: DotnetHostEnvironmentHelper.CreateDotnetRootEnvironmentOverrides()

   for worker nodes (specifically to make the apphost find the runtime).

So worker nodes get DOTNET_ROOT injected; the server child process does not.

Repro signature confirms this path

From the user's CLI log in microsoft/aspire#16849:

[2026-05-07 08:15:52.018] (build starts)
[2026-05-07 08:16:12.257] [FAIL] System.TimeoutException: The operation has timed out.

Exactly 20 seconds, which matches MSBuildClient.Execute:

if (!TryConnectToServer(serverIsAlreadyRunning ? 1_000 : 20_000))

So the path is: mutex check says no server is running → TryLaunchServer() spawns the apphost → TryConnectToServer(20_000) waits for the pipe → no server ever opens /tmp/MSBuildServer-{hash} → 20 s timeout. The launched apphost child is silently failing (or never reaching the server-listen point).

Corroborating: PR #13452

#13452 ("Prefer dotnet MSBuild.dll for out-of-proc worker nodes in CLI scenarios") reverted worker nodes back to dotnet MSBuild.dll due to a 16% perf regression caused by #13175. But that fix did not touch MSBuildClient.TryLaunchServer, so the server is still launched as the apphost in vs18.6/main. Aspire is the first widespread consumer hitting this because of the forced opt-in.

Suggested directions

1. Pass EnvironmentOverrides: DotnetHostEnvironmentHelper.CreateDotnetRootEnvironmentOverrides() in MSBuildClient.TryLaunchServer (mirroring NodeProviderOutOfProc); or
2. Mirror what Prefer dotnet MSBuild.dll for out-of-proc worker nodes in CLI scenarios #13452 did for worker nodes and revert the server to dotnet MSBuild.dll until the apphost path is hardened; or
3. At minimum surface the launched-server stderr/exit-code so the timeout message can identify why the server didn't come up (currently the user just sees a 20 s TimeoutException with no signal from the failed child).

User-side workaround for affected Aspire users

Set DOTNET_CLI_USE_MSBUILD_SERVER=false — the Aspire CLI honors the override (DotNetCliRunner.cs:82).

I'll follow up with a smoke test PR that exercises the apphost-launch path so this regression class is covered going forward.

[rainersigwald]

A failure to connect to the server here also shouldn't crash, it should fall back to in-proc execution.

[rainersigwald]

In general I wouldn't expect us to need to pass DOTNET_ROOT for installed-the-normal-way .NET SDKs. When I got a repro of this, a template console app's AppHost output also failed, because .NET was looking for the runtime in the wrong path, and removing the bad /etc/dotnet/install_location_x64 and /etc/dotnet/install_location files (that pointed to the wrong location) got Aspire and MSBuild Server working again.

However, we should still fix the environment passing, because I suspect that would NOT be the case for SDKs acquired with dotnet-install.sh or a zip.