Support "download only" package scenario with PackageDownload

[dsplaisted]

Keeping the original ask for context.
The design is as NuGet/Client.Engineering#91.

Tracking issues:

• PackageDownload Core logic Package Download logic implementation #7718
• PackageDownload VS Nomination updates PackageDownload VS nomination APIs update #7719
• PackageDownload NuGet.targets updates Update the NuGet.targets to handle PackageDownload #7721
• PackageDownload propagate telemetry and install info PackageDownload - Propagate the download dependency information to the telemetry and restore result APIs #7722
• PackageDownload restrict version range to exact versions only. PackageDownload - Restrict version range to exact versions only #7720

Post V1:

• PackageDownload version range implementation PackageDownload version range implementation #7709
• PackageDownload and hash validation PackageDownload and hash validation #7724

---

For .NET Core 3.0, there will be assets (such as Targeting Packs and Runtime Packs) that we want to acquire if necessary, but that we don't want to affect the NuGet restore graph. So we'd like to be able to provide a list of packages to restore which will be downloaded if they aren't already in the package cache, but that won't otherwise affect the restore operation.

These packages could be represented as a new item (such as DownloadOnlyPackage), or as metadata on the exsiting PackageReference item (such as DownloadOnly="true").

We imagine it would work as follows:

• The restore operation should download the "download only" packages (if they aren't already present)
• "Download only" packages should not affect the package graph in any way
  • It should be possible to specify multiple "download only" packages with the same package ID but different versions, and the restore operation should download them both
  • Dependencies of packages "download only" packages should be ignored by the restore operation. (In the case of Targeting Packs and Runtime Packs, we would author the packages so they have no dependencies specified.)
  • Restore would only download the exact version specified. If that version is not available, it would error out (instead of rolling forward to a later available version).
• "Download only" packages would not affect the assets file
• "Download only" packages inputs would not affect the noop restore fingerprint / cache.
  • IE, if a project had been restored, and then was restored again with no changes except the addition of "download only" packages (which is what we would expect if a project had been built and now was being published as a self-contained app), then NuGet would download the packages specified via "download only" packages if they were not already available locally, but in any case would treat the rest of the restore operation as a no-op restore.
• NuGet would provide a way (via an API and/or an MSBuild task) to resolve the local path to a given package's contents (ie in the packages folder, the fallback folder, or elsewhere where NuGet could resolve it from).

Download only package support is especially important for self-contained publish. The .NET Core runtime assets required for a self-contained publish depend on the RID being published for as well as the latest patch of .NET Core. Currently, a command line self-contained publish invalidates the assets file, and a self-contained publish from Visual Studio restores using a different assets path. Neither case is ideal and both of them result in extra non-noop restores running. "Download only" package support would allow us to tell NuGet to download the correct runtime pack when restoring for a self-contained publish without affecting the assets file that was generated from the restore during build.

[nkolev92]

Current spec is at https://github.com/NuGet/Client.Engineering/pull/91.

[nkolev92]

Closing the epic as the "original requirements" are fulfilled. The rest of the issues linked are future work.