Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Stop mutating environment variables during registration

Đang mở
  • Có gì không ổn?
#389 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
64/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
csharp
Lĩnh vực
build-system

Hướng nghiên cứu

Bắt đầu với ApplyDotNetSdkEnvironmentVariables và các lệnh gọi của nó từ các đường dẫn đăng ký .NET, sau đó kiểm tra bộ kiểm thử MSBuildLocator hiện có. Thêm độ bao phủ được cô lập theo tiến trình khi thiếu cả ba biến, đăng ký một SDK, đánh giá một dự án kiểu SDK và xác minh các đường dẫn được suy ra. Hoàn thành khi việc đăng ký không còn ghi đè các biến môi trường thuộc quyền quản lý của bên gọi và các kịch bản hồi quy đều vượt qua.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
C#
Star
262
Fork
91
Merge trung bình
11 ngày 22 giờ
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/MSBuildLocator

Tất cả issue của microsoft/MSBuildLocator

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.