Use the paths feature in global.json to point to our local .NET SDK.#126653
Use the paths feature in global.json to point to our local .NET SDK.#126653jkoritzinsky wants to merge 3 commits intodotnet:mainfrom
Conversation
As C# Dev Kit improves their experience, the fact that we don't have this makes it incresingly frustrating to work with in the runtime repo. Let's use the feature we built for this specific case.
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
There was a problem hiding this comment.
Pull request overview
Updates global.json to prefer the repo-local .NET SDK (installed into .dotnet/) during SDK resolution, improving editor/Dev Kit experiences while retaining a host fallback.
Changes:
- Add
sdk.pathsto search.dotnetfirst and then fall back to the host SDK ($host$). - Add a custom
sdk.errorMessageto guide developers when the required SDK is missing.
| ".dotnet", | ||
| "$host$" | ||
| ], | ||
| "errorMessage": "The required .NET SDK wasn't found. Please run ./eng/common/dotnet.cmd/sh to install it." |
There was a problem hiding this comment.
The errorMessage references a non-existent script path (./eng/common/dotnet.cmd/sh). In this repo the install entrypoints are eng/common/dotnet.sh, eng/common/dotnet.cmd (and dotnet.ps1), so the message should name the correct command(s) (e.g., unix vs Windows) to avoid sending developers to a broken path.
| "errorMessage": "The required .NET SDK wasn't found. Please run ./eng/common/dotnet.cmd/sh to install it." | |
| "errorMessage": "The required .NET SDK wasn't found. Please run ./eng/common/dotnet.sh (Unix) or eng\\common\\dotnet.cmd (Windows) to install it." |
|
This will most likely run into WasmBuildTests failures like #117460. I think we should fix that or find workarounds as I agree the feature is nice to have. |
|
I wish it could also just download the SDK itself without custom scripts 😐 |
I threw up this PR so I could get a binlog to investigate the failures without having to hook everything up locally. |
…olution
The global.json paths feature causes the SDK resolver to walk up the
directory tree and find the repo root's global.json with relative paths
like ".dotnet". When dotnet is invoked from temp directories (workload
install, WBT test projects, Blazor test projects), the resolver picks
up the wrong SDK from the repo-local .dotnet directory instead of the
intended SDK.
Fix by writing an empty global.json ({}) in temp directories so the
SDK resolver stops there and uses default resolution (DOTNET_ROOT, PATH).
This follows the established pattern used in HostTestContext.cs and
several CI pipeline scripts.
Files changed:
- InstallWorkloadFromArtifacts.cs: fixes workload install failures
("wasm-tools isn't supported on this platform")
- Wasm.Build.Tests/BuildTestBase.cs: fixes WBT test project builds
- Wasm.Build.Tests/Blazor/BlazorWasmTestBase.cs: fixes Blazor WBT builds
- Wasi.Build.Tests/BuildTestBase.cs: fixes WASI test project builds
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
|
@EgorBo that's dotnet/sdk#50623 :) |
The _GetDotNetVersion and _FirstDotNetRun targets run dotnet commands from the dotnet-none SDK directory. Without isolation, the SDK resolver walks up and finds the repo root's global.json with paths: [".dotnet"], resolving to the older preview.3 SDK instead of the preview.4 SDK actually installed in dotnet-none. This causes: - Manifests installed into the wrong version band directory - Workload packs not found at runtime - "multithreading runtime pack not available" test failures Fix by writing an empty global.json into the dotnet-none directory and setting WorkingDirectory on all Exec calls so the SDK resolver stops there and uses the correct SDK. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
As C# Dev Kit improves their experience, the fact that we don't have this makes it incresingly frustrating to work with in the runtime repo. Let's use the feature we built for this specific case.