Try fixing rejection of preview SDK #51591
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this is on .cmd because the claim is the release version of vs 2022 doesn't allow preview sdks. the global.json should also be able to enable preview sdks but many tests use a custom global.json file. Whether this will actually resolve correctly, I don't know. But if the only problem was that it could resolve before but now skips preview sdks, then this could work.
I thought that MSBuildSDKsPath would work because of the error being propagated: the line of code which uses the default sdk resolver does look at msbuildsdkspath https://github.com/dotnet/msbuild/blob/27c7c81bbd20f7bf1252782826c1fc8ee1427b2f/src/Build/BackEnd/Components/SdkResolution/DefaultSdkResolver.cs#L33 to https://github.com/dotnet/msbuild/blob/27c7c81bbd20f7bf1252782826c1fc8ee1427b2f/src/Shared/BuildEnvironmentHelper.cs#L670, but I think that points to the MSBuild SDKs (the Sdk/ content under a selected SDK), but does not control which SDK version is selected /r is supposedly the sdks resolver path, but maybe we actually want /d since it's the hostfxr path we're really giving
…build sdks location I'm not sure if the property even worked, because the error code is the same and the code doesn't seem to point to using this cli_dir. will try msbuildsdks property mentioned earlier next.
credit to roslyn repo for this idea
also, why doesn't exist? maybe we call it too early? try calling it again in sdk tests as well
Based on the code in msbuild for the sdk resolver, this seemed to be what took effect the most to me. I think \r is likely correct, considering we also set DOTNET_SDK_TEST_MSBUILDSDKRESOLVER_FOLDER to the \r folder. What is surprising to me is that, that is not working. The dotnet on the PATH is also found but not by msbuild. I assume that this may mean it's VS who is rejecting the SDK, which would mean an environment variable won't be enough unless it's able to turn off the preview sdks disable check. I'll try to find the code for that or get the enable preview sdks bit to work inside of helix
this is what the roslyn code was doing but I didnt realize. Looking at the vscode, it's literally just this .txt file which decides how to reject or accept preview SDKs.
will try to make this not ugly later
This was referenced Nov 6, 2025
Youssef1313
reviewed
Nov 6, 2025
Member
Author
|
I was working in another PR to test multiple options at once: #51558, which I'll keep as the main PR. Looks like I got it to work. The ❌ is there due to some mac SSL issues in the template engine. |
3 tasks
nagilson
added a commit
to nagilson/sdk
that referenced
this pull request
Nov 7, 2025
- VS uses the local appdata, VS versioned folder, sdk.txt file to determine whether or not to accept preview sdks - VS Release rejects preview SDKs by default which causes the msbuild sdk resolver to not find sdks, as msbuild respects the vs settings - This changes the vs settings to enable our internal SDKs to be found by msbuild when it's going under test. - Possible improvements: this PR assumes sdk.txt content ordering does not matter - based on VS code this appears to be true but could change in the future Also tried: - modifying global.json to enable preview sdks, which was not enough. some tests have a custom global.json and it seems to not take precedence setting env vars such as msbuildsdks which did not take precedence over the vs setting This commit is a condensed version of the work done in dotnet#51591 and dotnet#51598
github-actions bot
pushed a commit
that referenced
this pull request
Nov 7, 2025
- VS uses the local appdata, VS versioned folder, sdk.txt file to determine whether or not to accept preview sdks - VS Release rejects preview SDKs by default which causes the msbuild sdk resolver to not find sdks, as msbuild respects the vs settings - This changes the vs settings to enable our internal SDKs to be found by msbuild when it's going under test. - Possible improvements: this PR assumes sdk.txt content ordering does not matter - based on VS code this appears to be true but could change in the future Also tried: - modifying global.json to enable preview sdks, which was not enough. some tests have a custom global.json and it seems to not take precedence setting env vars such as msbuildsdks which did not take precedence over the vs setting This commit is a condensed version of the work done in #51591 and #51598
github-actions bot
pushed a commit
that referenced
this pull request
Nov 7, 2025
- VS uses the local appdata, VS versioned folder, sdk.txt file to determine whether or not to accept preview sdks - VS Release rejects preview SDKs by default which causes the msbuild sdk resolver to not find sdks, as msbuild respects the vs settings - This changes the vs settings to enable our internal SDKs to be found by msbuild when it's going under test. - Possible improvements: this PR assumes sdk.txt content ordering does not matter - based on VS code this appears to be true but could change in the future Also tried: - modifying global.json to enable preview sdks, which was not enough. some tests have a custom global.json and it seems to not take precedence setting env vars such as msbuildsdks which did not take precedence over the vs setting This commit is a condensed version of the work done in #51591 and #51598
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#51558 is similar but I don't want to cancel the current run by pushing.... and can't disable autocancel without cancelling it