You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
install-tools.ps1: dotnet status doesn't see pre-release SDKs Visual Studio installs outside winget #694
Microsoft.DotNet.SDK.10 is the winget package install-tools.ps1 tracks for dotnet, and Resolve-InstalledVersion correctly folds side-by-side 10.x builds winget knows about into one version. But Visual Studio installs its own SDK copies (including pre-release ones) into the same C:\Program Files\dotnet\sdk tree, outside winget entirely, and those aren't in winget's inventory for that id at all, so they're invisible to the report and to the outdated/current decision.
winget list --id Microsoft.DotNet.SDK.10 --exact shows three side-by-side builds: 10.0.111, 10.0.204, 10.0.303 — the script correctly resolves the newest, 10.0.303.
dotnet --list-sdks on the same host additionally shows 8.0.319, 8.0.424, 9.0.205, 9.0.317, 10.0.100-rc.1.25451.107, and 10.0.400-preview.0.26322.102 — none of which winget's list --id Microsoft.DotNet.SDK.10 reports.
dotnet --version (what a caller on this host actually runs, absent a pinning global.json) resolves to 10.0.400-preview.0.26322.102 — already at or ahead of the 10.0.400 winget calls "available" — installed by Visual Studio, not winget.
Why this matters
The report's outdated status and the -Upgrade/-Install action it would drive are both scoped to winget's view alone, which is correct as far as it goes, but a host with Visual Studio installed can already be running an SDK ahead of what the report shows, and nothing here says so. Someone reading the report has no way to tell "genuinely behind" from "the number winget tracks is behind, but a newer preview SDK from Visual Studio is what the shell actually resolves to."
Suggested direction
Not a fix directly, but worth naming as a gap: either detect SDKs Visual Studio (or other external tooling) lands outside winget, e.g. by cross-checking dotnet --list-sdks against what winget reports, or at minimum add a note to the report similar to the existing python-venv-shadowing note, saying dotnet may resolve to an SDK winget did not install. Leaving the exact shape to whoever picks this up.
Host
Windows 11 Pro 10.0.26200, PowerShell 7.6.4, winget (App Installer), unelevated, Visual Studio installed.
Activity
Drive the dotnet Note Through Add-ToolNote With a Stub dotnet
Answer Only --list-sdks From the Test's Stub dotnet
Name a Newer dotnet SDK From Outside the Managed Package in the Windo…