Download tool packages from NuGet feeds directly, instead of implicitly restoring

[baronfel]

Is your feature request related to a problem? Please describe.

Currently to install a .NET SDK tool we acquire the nuget package by restoring a temporary project. This has a number of side effects, which often show up as flaky restore errors because MSBuild concepts like Directory.Build.props, or other heirarchical notions, pollute the restore.

Describe the solution you'd like

We should query NuGet APIs for explicit versions of tool packages to download, and download them via the NuGet API (of course handling authentication, NuGet.config files, etc in a consistent manner as Restore does).

[KalleOlaviNiemitalo]

Is this what was requested in #22349? Which was closed because "we won't be able to make this change."

[baronfel]

@nkolev92 any insight into @KalleOlaviNiemitalo's question? To me, for tools specifically, we should be able to

• query NuGet for versions of the Package ID the user requested (adding the implied constraint of PackageType == DotnetToolPackage or whatever the named constant is)
• use the version the user requested (if any) to pick the latest matching version of that Package Id
• download and extract that NuGet package and continue about our day

[nkolev92]

Tools depends on restore for assets and compatibility selection.
By calling restore, you're also getting all the user configuration, handling of multiple feeds, plus things like source mapping are respected.

I think it's a lot of code that you'd have to maintain separately that duplicates a lot of what restore does today.

[baronfel]

When you say assets and compatibility - for tools we know what the TFM, architecture, and OS platform should be - the ones from the currently-running host and SDK installation. Isn't that enough to serve as inputs into the selection algorithm?

[nkolev92]

The SDK does know everything it needs to, but restore is not necessarily written like a library, but rather a tool, which is why I think maintaining multiple workflows could potentially be costly.

In the past, downloading was not done on the SDK side either, so there's some API knowledge on that end, so maybe those concerns are lesser now.

[marcpopMSFT]

Merged!