Handle RID asset selection in SDK instead of NuGet

[dsplaisted]

Proposal

• Make NuGet restore agnostic of runtime identifiers (RIDs) and the RID graph
• SDK will include RID graph (https://github.com/dotnet/cli/issues/10104)
• SDK will use RID graph to select best matching runtime and apphost packs (https://github.com/dotnet/cli/issues/10095)
• NuGet will not use the RID or the RID graph as part of restore
• The assets file will only have one target pertarget framework
• RID-specific assets from NuGet packages will always be written as runtimeTargets assets to the assets file, never as native assets
• When building or publishing for a specific RID, the SDK will be responsible for selecting the appropriate native assets for the target RID from the runtimeTargets assets in the assets file (using the RID graph included in the SDK)
• Repurpose RuntimeIdentifiers property to specify a list of RIDs for which targeting packs should be downloaded

Benefits

• RID can be specified at build or publish time without having to re-restore (modulo possible PackageDownload for runtime packs)
• Further reduce asset file size
• Simplify NuGet logic (RID graph, two-phase restore)

Open questions

• Targeting earlier versions of .NET Core - currently we depend on NuGet to get the runtime assets for self-contained publish, via RID-specific dependencies specified in runtime.json in Microsoft.NETCore.App package
• Multitargeting - means we can't easily have different RID handling by NuGet for .NET Core 3.0 and prior versions

[nguerrera]

RID-specific assets from NuGet packages will always be written as runtimeTargets assets to the assets file, never as native assets

Why is this necessary?

Repurpose RuntimeIdentifiers property to specify a list of RIDs for which targeting packs should be downloaded

You mean"runtime packs", right?

Thinking about the open questions, it seems easier to leave RuntimeIdentifiers alone for back-compat and have a different property to specify runtime packs.

[dsplaisted]

If we do this, we wouldn't need NuGet/Home#7351 from NuGet

[mhutch]

Does this mean that NuGet will restore the assets for all RIDs regardless of whether they're needed or not? Seems like it could massively increase the initial restore time when using packages with large native assets.

[dsplaisted]

@mhutch It means we wouldn't support RID-specific package dependencies. For .NET Core, the RID-specific dependencies would come from runtime packs, and only runtime packs necessary would be downloaded.

We scanned the packages on NuGet.org and found that there weren't any current versions of third-party packages that used RID-specific package dependencies.

[eerhardt]

It means we wouldn't support RID-specific package dependencies.

Does that mean proposals like NuGet/Home#3114 won't be possible in the future?

[nguerrera]

It depends how "anchor packages" would be discovered. It seems that the expectation is that users would reference them explicitly from my skimming of that proposal. If so, that could still work.

[nguerrera]

NuGet/Home#3114 (comment)

[mhutch]

cc @migueldeicaza

It seems a shame to remove that capability just when it's on the horizon for platforms other than netcore. It would be super useful for things like SkiaSharp.

[nguerrera]

I don't think we can remove the capability so much as not use it in some scenarios Even if .NET Core packages were truly the only thing that used this, we still need to handle .NET Core <3.0.

I'm beginning to think that we should not do this feature and favor NuGet/Home#7351. It removes nothing and just adds another way to specify runtime.json.

There are other ways to we can achieve some of the things this would solve such as putting RID-specific assets in separate RID-specific assets files. I suspect going after these things will be moved out past .NET Core 3.0.

[glopesdev]

We scanned the packages on NuGet.org and found that there weren't any current versions of third-party packages that used RID-specific package dependencies.

@dsplaisted I wonder if this is the case simply because there isn't currently any reasonable user story for deploying RID-specific package dependencies in third-party packages?

It doesn't seem a fair assessment to judge community interest based on whether they can hack their way through undocumented features which can only really be used with insider knowledge of current framework architecture.

To be fair on this, you would have to analyse whether the community has a recurrent need for this feature. I would suggest searching nuget.org for keywords like "runtime", "native" or "linux" and you can easily find several high-profile packages which are trying to deploy RID-specific assets using a variety of different hacks.

And even then, these are only the success stories. As cross-platform usage of .NET increases, the need to solve this properly will only increase with time. You could probably also trace this by looking at activity in issue trackers mentioning this problem in one form or the other over the last 2 years.

[dsplaisted]

@glopesdev Yes, I pretty much agree with you. The main point of saying that there weren't any third party packages using RID-specific dependencies was that we could remove the existing functionality without much impact, since no one was using it.

It would also be nice to design a new mechanism for RID-specific package dependencies that was more usable and less technically complex.

However, it looks like for now these ideas remain on the backlog.