Mechanism for supplying runtime.json outside of a package

[nguerrera]

In Core 3.0, the platform will not be represented as a traditional nuget package. As such, there's no obvious place for the RID graph to be supplied to NuGet.

1. The SDK will need access to the RID graph to pick the appropriate "runtime pack"
2. Restore will also need access to it to pick the correct RID-specific package assets for packages outside the platform.

For (2), the feature request here would be to have msbuild items that specify runtime.json files on disk to use during restore.

Something like

<ItemGroup>
  <RuntimeGraph Include="path/to/runtime.json" />
</ItemGroup>

It's a separate question as to how the SDK will locate runtime.json for (1), but once we do that, we can then just pass it in to restore if we had this feature.

Update by @nkolev92
Spec

[dsplaisted]

Downsides of current workaround (referencing platform package implicitly if there are any other package references):

• Platforms package shows up in dependency tree
• .NET Framework may still have issues if we don't also add code to automatically reference it

[dsplaisted]

Probably we would use an MSBuild property instead of an item for this, as that wouldn't require nomination API changes.

[nkolev92]

The idea is to use a property to avoid nomination changes. It can be a semicolon delimited property similar to TargetFrameworks for example.

I will create a short spec on this.

[nkolev92]

Update the issue body with link to the spec.

[nkolev92]

Project system bug: dotnet/project-system#4951
Project system PR: dotnet/project-system#4952

[xen2]

Noticed a bunch of regression and need some help:

1. Our game engine (Xenko), add extra runtimes (https://github.com/xenko3d/xenko/blob/master/sources/engine/Xenko/runtime.json)
2. Since updating to VS 2019 16.3.0 (with .NET Core 3), we had to add <RuntimeIdentifierGraphPath></RuntimeIdentifierGraphPath> to one of our target file for this to keep working.
   It doesn't seem to work anymore in latest VS2019 (however it work if I move <RuntimeIdentifierGraphPath></RuntimeIdentifierGraphPath> from our package target to user project but still half broken depending on PackageReference order).

I would be fine to change things around, so maybe you have some recommendation/other way to achieve this and keep the old way (which is still supposed to be supported for .NET Core 2 from what I understood)?

[nkolev92]

Not sure if this is enabled in 2.x, @nguerrera, @dsplaisted will know.

Can you clarify what you are seeing when it fails?

The assets file will have all the info about what nuget "thinks" exists, and it should be on a per framework basis.

[xen2]

Never mind, I think it might have been due to something else.
We had a circular runtime identifier references between our runtime identifier (on purpose so that win includes win-d3d11 by default).
I suppose this PR changed the default (undefined) order of runtime inclusion, which we shouldn't have relied on in the first place.
We will do things differently.