Installing 8.0 version of dotnet-dump fails. Possible regression.

[kichalla]

Describe the bug

We use the following command to install dotnet-dump tool in our container image. This has been working fine until yesterday but seems like there was an update to the 8.0 image today that is breaking this.
dotnet tool install --tool-path /tools dotnet-dump --version 8.0

To Reproduce

• docker pull mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
• docker run -it mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
• dotnet --version (this should print 8.0.101)
• dotnet tool install --tool-path /tools dotnet-dump --version 8.0 (this will fail and used to work until yesterday...seems like a regresion with nuget cli?)
• dotnet tool install --tool-path /tools dotnet-dump --version 8.0.505301 (this works though...but we want to specify only the major and minor vesions)

Example output:

C:\repos\acr [dev ≡]> docker pull mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
8.0-cbl-mariner2.0: Pulling from dotnet/sdk
Digest: sha256:b82cd08021851d137ce6142e23b0ecfb6fe231c67b7f08fa01bcbbb100e6c388
Status: Image is up to date for mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
C:\repos\acr [dev ≡]> docker run -it mcr.microsoft.com/dotnet/sdk:8.0-cbl-mariner2.0
root [ / ]# dotnet --version
8.0.101
root [ / ]# dotnet tool install --tool-path /tools dotnet-dump --version 8.0
Unhandled exception: Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageNotFoundException: dotnet-dump::8.0 is not found in NuGet feeds https://api.nuget.org/v3/index.json".
   at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetPackageMetadataAsync(String packageIdentifier, NuGetVersion packageVersion, IEnumerable`1 sources, CancellationToken cancellationToken, Boolean includeUnlisted)
   at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetPackageSourceAndVersion(PackageId packageId, NuGetVersion packageVersion, PackageSourceLocation packageSourceLocation, Boolean includePreview, Boolean includeUnlisted, PackageSourceMapping packageSourceMapping)
   at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.DownloadPackageAsync(PackageId packageId, NuGetVersion packageVersion, PackageSourceLocation packageSourceLocation, Boolean includePreview, Boolean includeUnlisted, Nullable`1 downloadFolder, PackageSourceMapping packageSourceMapping)
   at Microsoft.DotNet.Cli.ToolPackage.ToolPackageDownloader.DownloadAndExtractPackage(PackageLocation packageLocation, PackageId packageId, INuGetPackageDownloader nugetPackageDownloader, String packagesRootPath, IToolPackageStore toolPackageStore, NuGetVersion packageVersion, PackageSourceLocation packageSourceLocation, Boolean includeUnlisted)
   at Microsoft.DotNet.Cli.ToolPackage.ToolPackageDownloader.<>c__DisplayClass8_0.<InstallPackage>b__0()
   at Microsoft.DotNet.Cli.TransactionalAction.Run[T](Func`1 action, Action commit, Action rollback)
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()
   at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
root [ / ]# dotnet tool install --tool-path /tools dotnet-dump --version 8.0.505301
Skipping NuGet package signature verification.
You can invoke the tool using the following command: dotnet-dump
Tool 'dotnet-dump' (version '8.0.505301') was successfully installed.

Exceptions (if any)

Unhandled exception: Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageNotFoundException: dotnet-dump::8.0 is not found in NuGet feeds https://api.nuget.org/v3/index.json".

Further technical details

• Include the output of dotnet --info

root [ / ]# dotnet --info
.NET SDK:
 Version:           8.0.101
 Commit:            6eceda187b
 Workload version:  8.0.100-manifests.69afb982

Runtime Environment:
 OS Name:     mariner
 OS Version:  2.0
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/8.0.101/

.NET workloads installed:
 Workload version: 8.0.100-manifests.69afb982
There are no installed workloads to display.

Host:
  Version:      8.0.1
  Architecture: x64
  Commit:       bf5e279d92

.NET SDKs installed:
  8.0.101 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
  This is inside a 8.0-cbl-mariner2.0 docker container

[baronfel]

This worked in .NET 7 because of the way .NET tools were implemented under the covers - the version you specified was written to a hidden C# project, and that project had the Restore target run against it. This resulted in NuGet resolving the under-specified version to a specific version, which was then downloaded.

In .NET 8, for performance and reliability reasons, we moved to explicitly downloading packages from configured package feeds using the NuGet APIs. The version the user passed in was inferred as [8.0.0, ) in NuGet range syntax - so in your case this version would get resolved to the latest 8.0 release of dotnet-dump. However, this change broke users that were installing deprecated tools because this version range selection skips over unlisted tools in the NuGet algorithm. To solve this, we made a change in #35566 to treat the users' passed-in version as an exact match ([8.0.0] in NuGet range syntax). This enabled deprecated/unlisted tools to be installed, but it then broke the floating-version behavior you had come to expect.

This means, right now, your previous pattern won't work anymore.

We need to do some design work to cover all of these scenarios in one.

[baronfel]

As a workaround, you can use --version 8.0.* and the NuGet API will fill in that range in the manner you expect.

[marcpopMSFT]

The proposal from triage is to treat a three part version as an exact version and include unlisted and treat all other versions (like 8.0) as a version range and don't include unlisted. We are nervous about automatically including unlisted when searching a range as customers may want to remove a package after finding an issue in it.

For now, we think we may just improve the documentation and wait for feedback. There will be a separate bug for improving the error experience to not include the callstack.

[mcallaghan-geotab]

Also experiencing this as a regression against this and many other tools, the full list includes (though is not likely limited to)

• dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-sos, dotnet-stack, dotnet-trace
  ^ included for searchability for others experiencing the regression to land here.

dotnet tool install <dotnet-tool-name> --version 8.0
"Unhandled exception: Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageNotFoundException

The previous behaviour is that #.# (major.minor) would automatically discover and install the latest patch.