Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Stop mutating environment variables during registration

未关闭
  • 哪里不对？
#389 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
64/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
csharp
领域
build-system

调研方向

先从 ApplyDotNetSdkEnvironmentVariables 及其在 .NET 注册路径中的调用开始，然后检查现有的 MSBuildLocator 测试套件。在三个变量均缺失的情况下，添加进程隔离的覆盖测试，注册一个 SDK，评估一个 SDK-style 项目，并验证派生路径。完成标准是注册过程不再重写调用方拥有的环境变量，并且回归场景通过。

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
C#
星标
263
派生
90
平均合并
3 天 21 小时
30 天内合并 PR
1

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/MSBuildLocator 的其他 Issue

查看 microsoft/MSBuildLocator 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。