Skip to content

Make the new SdkResolver set the proper DOTNET_HOST_PATH env var instead of the non-functional DOTNET_HOST env var#2592

Merged
marcpopMSFT merged 1 commit intorelease/10.0.1xx-rc2from
fix-sdkresolver-env
Sep 24, 2025
Merged

Make the new SdkResolver set the proper DOTNET_HOST_PATH env var instead of the non-functional DOTNET_HOST env var#2592
marcpopMSFT merged 1 commit intorelease/10.0.1xx-rc2from
fix-sdkresolver-env

Conversation

@baronfel
Copy link
Member

@baronfel baronfel commented Sep 24, 2025

Customer Impact

There isn't any observable customer impact to this change. This fixes an implementation issue in the previous MSBuild decoupling work that was being hidden by separate MSBuild engine compatibility shims that we added to enable testing the end-to-end of the feature before dev18 was available. If we don't take this change then the net impact is that we aren't able to remove our compat shim in the future and test/rely on the actual designed feature.

If we don't take this for RC2 we wouldn't push for this change, or the compat shim removal, for GA at all. We'd wait until a later feature band/VS release to coordinate that removal more safely.

Description

The SdkResolver is intended to set DOTNET_HOST_PATH to signal to MSBuild Tasks that need a .NET binary/runtime where to look for that binary. Instead it was setting DOTNET_HOST. This has no impact at all - we should have been setting DOTNET_HOST_PATH the whole time (once we added env var support at all in dotnet/sdk#50091).

This was masked because we put a compat shim in the MSBuild engine that looked for the DOTNET_EXPERIMENTAL_HOST_PATH Property set by an SdkResolver and transparently 'promoted' it to the DOTNET_HOST_PATH env var.

After this change, both the experimental property and the correct env var will be set, but the engine prefers the env var if it is present.

Risk

Low - even with this change we will continue to set the back-compat property, this just enables us to remove the compat code some time in the future without breaking the world.

Testing

It's hard to test the env-var setting right now because the automated tests run in a CI-driven VS environment where the SdkResolver doesn't have the ability to set environment variables (which is why we made the compatibility shim in the first place). We're waiting on dev18 images to be available before we can truly pin this behavior through testing. @rainersigwald has done some end-to-end testing as well.

@baronfel baronfel requested review from a team as code owners September 24, 2025 15:01
@baronfel baronfel changed the base branch from main to release/10.0.1xx September 24, 2025 15:02
@baronfel baronfel changed the base branch from release/10.0.1xx to release/10.0.1xx-rc2 September 24, 2025 15:04
@baronfel baronfel changed the base branch from release/10.0.1xx-rc2 to release/10.0.1xx September 24, 2025 15:04
@baronfel baronfel changed the base branch from release/10.0.1xx to release/10.0.1xx-rc2 September 24, 2025 15:04
Copy link
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied these privates over a canary-channel VS and was able to build a MAUI project using the right csc/vbcscompiler.

cc @jjonescz

@baronfel baronfel added the Servicing-approved Approved for servicing release label Sep 24, 2025
@baronfel
Copy link
Member Author

Approved for RC2 over email.

@marcpopMSFT marcpopMSFT merged commit 04104ba into release/10.0.1xx-rc2 Sep 24, 2025
10 checks passed
@marcpopMSFT marcpopMSFT deleted the fix-sdkresolver-env branch September 24, 2025 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Servicing-approved Approved for servicing release

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants