[8.0.100-rc.2.23469.4] some deprecated global tools get NuGetPackageNotFoundException when installing

[Junjun-zhao]

Issue Description:
When installing these global tools with "dotnet tool install" command, NuGetPackaeNotFoundException will be thrown on dotnet-sdk-8.0.100-rc.2.23469.4. But they are installed successful with dotnet-sdk-8.0.100-rc.2.23466.1.

Application Name: Elemental.SysInfoTool, dotnet-giio, dotnet-sqldb
OS： Windows 10 21H2
CPU: X64
.NET Build Number: dotnet-sdk-8.0.100-rc.2.23469.4

Verify Scenarios:

1. Windows10 21h2 x64 + dotnet-sdk-8.0.100-rc.2.23469.4: Fail
2. Windows10 21h2 x64 + dotnet-sdk-8.0.100-rc.2.23466.1: Pass

Repro steps:
The machine only has 8.0.100-rc.2.23469.4 installed and set DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX environment variable as 2.

1. Open cmd.exe form %windir%\System32
2. Input ‘dotnet tool install -g Elemental.SysInfoTool’
3. Press keyboard ‘Enter’

Expected Result:
Elemental.SysInfoTool install successful.

Actual Result:
Install failed with following exception:

Unhandled exception: Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageNotFoundException: elemental.sysinfotool::[*, ) is not found in NuGet feeds https://api.nuget.org/v3/index.json, https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json, https://dotnetfeed.blob.core.windows.net/dotnet-windowsdesktop/index.json, https://dotnetfeed.blob.core.windows.net/aspnet-aspnetcore/index.json, https://dotnetfeed.blob.core.windows.net/aspnet-aspnetcore-tooling/index.json, https://dotnetfeed.blob.core.windows.net/aspnet-entityframeworkcore/index.json, https://dotnetfeed.blob.core.windows.net/aspnet-extensions/index.json, https://grpc.jfrog.io/grpc/api/nuget/v3/grpc-nuget-dev, https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json, https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json, https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json, https://pkgs.dev.azure.com/dnceng/internal/_packaging/6.0.414-servicing.23416.29-shipping/nuget/v3/index.json".

   at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetMatchingVersionInternalAsync(String packageIdentifier, IEnumerable`1 packageSources, VersionRange versionRange, CancellationToken cancellationToken)
   at Microsoft.DotNet.Cli.NuGetPackageDownloader.NuGetPackageDownloader.GetBestPackageVersionAsync(PackageId packageId, VersionRange versionRange, PackageSourceLocation packageSourceLocation)
   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)

Findings:
These tools do not exist in NuGet Gallery | Packages
And their details page marked them as deprecated and cannot be used anymore. For example, this is the Elemental.SysInfoTool tool page.
But we can install this tool successfully when we have earlier SDK installed in our machine.
This issue seems related to 8114042

@dotnet-actwx-bot @dotnet/compat

[Junjun-zhao]

@marcpopMSFT Could you please help check this bug? It appears to be intentional.

[KalleOlaviNiemitalo]

This seems to be by design, according to #24037 and #28951. Also #32092, although that one is still open.

Does the installation succeed if you specify the --version of the tool explicitly?

This might still deserve a breaking-change entry in https://learn.microsoft.com/dotnet/core/compatibility/8.0#sdk. There was a pull request dotnet/docs#32567 but it was closed as premature.

[Junjun-zhao]

Does the installation succeed if you specify the --version of the tool explicitly?

No, it does not work either. Same exception shows when try to install the tool with or without "--version"
For example, dotnet tool install --global Elemental.SysInfoTool --version 0.5.0

[marcpopMSFT]

@JL03-Yue @dsplaisted This was an intentional change. Do you know if it was intended to still work if the user specified an exact version of the package? We may want to mark this as a breaking change and document it as it appears some folks were relying on this.

[KalleOlaviNiemitalo]

ParseResultExtension.GetVersionRange(this ParseResult parseResult) from #28951 used to skip the NuGet search if --version was specified:

sdk/src/Cli/dotnet/commands/dotnet-tool/install/ParseResultExtension.cs

Line 22 in f9a6b4e

string packageVersion = parseResult.GetValue(ToolInstallCommandParser.VersionOption);

sdk/src/Cli/dotnet/commands/dotnet-tool/install/ParseResultExtension.cs

Lines 47 to 49 in f9a6b4e

	if (string.IsNullOrEmpty(packageVersion))
	{
	var nugetToolSearchApiRequest = new NugetToolSearchApiRequest();

But that code was removed in #33835 and replaced with NuGetPackageDownloader, which works differently. The comments on that pull request do not include the string "unlist". Some comments include the word "version" in relation to package versions but they do not directly address this issue:

• About allowing installation of a preview version when --version is specified: Download tool packages from NuGet feeds directly, instead of implicitly restoring #33835 (comment), Download tool packages from NuGet feeds directly, instead of implicitly restoring #33835 (comment).
• Need to pass the VersionRange to NuGetPackageDownloader: Download tool packages from NuGet feeds directly, instead of implicitly restoring #33835 (comment).
• Allow null VersionRange: Download tool packages from NuGet feeds directly, instead of implicitly restoring #33835 (comment).
• Request to delete the version query from ParseResultExtension: Download tool packages from NuGet feeds directly, instead of implicitly restoring #33835 (comment).

[Kralizek]

I'm experiencing the same issue when restoring in Azure DevOps a project that references Microsoft Tye 0.11 since RC2 went live.

The same issue doesn't happen on my local machine.

$ dotnet --version
8.0.100-rc.2.23502.2

See for more details the issue on the Tye repo: dotnet/tye#1615

[JL03-Yue]

This will be targeted to be fixed in .NET 8 GA.