Summary
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.
Evidence, from a Windows host
install-tools.ps1 -Report: dotnet 10.0.303 10.0.400 ... outdated.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.
Summary
Microsoft.DotNet.SDK.10is the winget packageinstall-tools.ps1tracks fordotnet, andResolve-InstalledVersioncorrectly 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 sameC:\Program Files\dotnet\sdktree, 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.Evidence, from a Windows host
install-tools.ps1 -Report:dotnet 10.0.303 10.0.400 ... outdated.winget list --id Microsoft.DotNet.SDK.10 --exactshows 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-sdkson the same host additionally shows8.0.319,8.0.424,9.0.205,9.0.317,10.0.100-rc.1.25451.107, and10.0.400-preview.0.26322.102— none of which winget'slist --id Microsoft.DotNet.SDK.10reports.dotnet --version(what a caller on this host actually runs, absent a pinningglobal.json) resolves to10.0.400-preview.0.26322.102— already at or ahead of the10.0.400winget calls "available" — installed by Visual Studio, not winget.Why this matters
The report's
outdatedstatus and the-Upgrade/-Installaction 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-sdksagainst what winget reports, or at minimum add a note to the report similar to the existing python-venv-shadowing note, sayingdotnetmay 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.