Figure out how to handle runtime packs for optional shared frameworks for iOS and Android

[dsplaisted]

Right now, when we download runtime packs for a project, we download all possible runtime packs for the target framework. This happens whether or not the project uses them or not, because at restore time we don't yet know if there will be a transitive reference to any given shared framework.

We may have to refine this for iOS and Android. See discussion here of the ASP.NET Core runtime pack getting downloaded for Android.

One way to resolve this is to simply say that ASP.NET Core isn't available on iOS and Android, and never download it. There may be scenarios where it is desired, however.

Another solution is to have a feature in NuGet where the project passes in a mapping of shared frameworks to runtime packs. During restore, if a project depends on a shared framework via a transitive reference, NuGet would convert that to a PackageDownload for the corresponding runtime pack via the mapping. This would also allow us to fix some of the issues with compiling projects that reference WindowsDesktop on non-Windows PCs.

[marek-safar]

This does not affect iOS as it has a very specific RID hierarchy. However, it'll affect most of the remaining platforms. There are/will be multiple runtime packs for macOS, Linux and possibly windows RIDs for .NET5 which I if understood correctly the current limitations then ASP.NET self-contained scenario on Linux would download MonoVM runtime pack all the time.

[marek-safar]

/cc @richlander

[marcpopMSFT]

@dsplaisted please review and see if there is more work required here or if this is complete.

[dsplaisted]

The runtime pack identifiers for the ASP.NET Core shared framework are currently win-x64;win-x86;win-arm;osx-x64;linux-musl-x64;linux-musl-arm64;linux-x64;linux-arm;linux-arm64;linux-musl-arm;win-arm64;osx-arm64

Do any of those match an Android RuntimeIdentifier? @marek-safar @jonathanpeppers @Redth

[jonathanpeppers]

I think if one was unix, it might match Android, but those look OK.

Normally we have: android-arm, android-arm64, android-x86, and android-x64.

[dsplaisted]

I think we can close this then. We can revisit if it becomes an issue in the future.