Stop mutating environment variables during registration

[rainersigwald]

On .NET, registration currently calls ApplyDotNetSdkEnvironmentVariables, which sets process-wide environment variables:

MSBUILD_EXE_PATH=<sdk>\MSBuild.dll
MSBuildExtensionsPath=<sdk>
MSBuildSDKsPath=<sdk>\Sdks

This was added to mimic the environment established by dotnet msbuild, but it appears unnecessary. MSBuild can derive its toolset, extensions path, and SDKs path from the loaded MSBuild assemblies.

Proposal: remove ApplyDotNetSdkEnvironmentVariables and stop setting or unsetting these variables during registration. Environment variables supplied by the caller should remain caller-owned.

Copilot analysis of the situation:

Why

MSBuild's BuildEnvironmentHelper already has self-location logic:

• MSBUILD_EXE_PATH is an explicit override, but when absent MSBuild locates its installation from the loaded assembly and adjacent MSBuild.dll/apphost.
• MSBuildExtensionsPath defaults to the detected MSBuild tools directory for a standalone toolset.
• MSBuildSDKsPath defaults to <detected MSBuild tools directory>\Sdks.

Mutating these variables is process-global and can affect unrelated code and child processes. In particular, a child dotnet invocation may select another SDK through global.json while inheriting paths pinned to the SDK registered in its parent.

Experiments

An isolated probe was run in a fresh process for each scenario. It:

1. Registered a specific SDK directory before touching any MSBuild API.
2. Removed MSBUILD_EXE_PATH, MSBuildExtensionsPath, and MSBuildSDKsPath before MSBuild initialized.
3. Created and evaluated a minimal SDK-style project.
4. Checked the evaluated toolset properties.
5. Restored and built the project and verified its output.
6. Repeated the build through two parallel out-of-process worker nodes.

Tested SDKs:

SDK	MSBuild	Project TFM	Result
2.1.300	15.7	netcoreapp2.1	Passed
8.0.423	17.x	net8.0	Passed
9.0.316	17.x	net9.0	Passed
10.0.302	18.x	net10.0	Passed
10.0.400 preview	18.x	net10.0	Passed

In every case MSBuild derived the selected installation correctly. For SDK 2.1.300, for example:

MSBuildExtensionsPath=<extracted SDK>\sdk\2.1.300
MSBuildSDKsPath=<extracted SDK>\sdk\2.1.300\Sdks
MSBuildToolsPath=<extracted SDK>\sdk\2.1.300
MSBuildToolsVersion=15.0

Restore, build, output verification, and the parallel-node build all succeeded. The current MSBuildLocator test suite also passed after replacing the environment setup during the experiment.

The SDK 2.1.300 probe used the official Windows x64 archive. The harness itself ran on .NET 8 while loading MSBuild 15.7 from that SDK; it did not cover a .NET Core 2.1-hosted process or Linux.

Compatibility considerations

• Existing ambient values currently get overwritten. With this proposal they would be preserved and would continue to act as explicit MSBuild overrides. That is more conventional, but it is a behavior change for callers with stale or incorrect inherited values.
• Native AOT and unusual bundled hosts can require an explicit toolset path when Assembly.Location is unavailable. MSBuildLocator currently relies on runtime assembly loading and does not support the normal Native AOT model, but this should be confirmed before removal.
• The oldest supported SDK should also be exercised under its native runtime and on Unix in CI if practical.

Proposed change

• Remove ApplyDotNetSdkEnvironmentVariables and its calls from .NET registration paths.
• Add process-isolated regression coverage that registers an SDK with all three variables absent, evaluates an SDK-style project, and verifies the derived paths.
• Document that MSBuild-related environment overrides are owned by the host/caller and are not rewritten by MSBuildLocator.