Supply RID graph for .NET Core 3.0 SDK

[dsplaisted]

Currently, the RuntimeIdentifier graph is provided via the Microsoft.NETCore.Platforms package, which is a dependency of the Microsoft.NETCore.App and NETStandard.Library packages. With .NET Core 3.0, we will be using Targeting Packs instead of these packages. The targeting packs won't support package dependencies, and won't be able to include the runtime graph for NuGet.

So we will need to find a different way of bringing in the RID graph. Two options come to mind:

• Include an implicit PackageReference to Microsoft.NETCore.Platforms. This has the downside that we would need to include this package in the NuGetFallbackFolder, which we would like to get rid of.
• Include the RID graph in the SDK, and pass it directly to NuGet for Restore. We will probably already be including the RID graph in the SDK as part of Resolve runtime pack to use for self-contained publish (including RID) #9799. So the main thing needed to support this option is a NuGet feature: Mechanism for supplying runtime.json outside of a package NuGet/Home#7351

[dsplaisted]

Related: #1046

[dasMulli]

If possible, it would be great to be able to pass the RID graph to .net framework builds as well. preferably in a way that can also be shipped within VS.
Currently, packages relying on native assets aren't always correctly resolved in .net framework builds until a reference to m.nc.platforms is added. This has come up a few times and it would be great to have a "fallback" RID graph that comes with the SDK / VS installation.

[nguerrera]

We're going to split this in two:

1. For initial bring-up, we will have exactly one version of the graph in the .NET Core SDK.
2. We need to figure out how to prevent breaking changes. By this we mean that we don't want the assets selected in a build to change with an sdk change and no project change. We thought about versioning it by TFM, but there's just one Platforms package with increasing version for all TFMs.

We'll leave this issue tracking just (1)

[dsplaisted]

We need to figure out how to prevent breaking changes. By this we mean that we don't want the assets selected in a build to change with an sdk change and no project change. We thought about versioning it by TFM, but there's just one Platforms package with increasing version for all TFMs.

This is covered by https://github.com/dotnet/cli/issues/10496