The dotnet host should respect a RID graph from an app's .deps.json

[eerhardt]

In applications that run on the shared framework, the app will have native assets for all the runtimes that are necessary. For example, if you reference SQLite, you get the following in your publish directory:

However, the problem is the host only knows how to resolve these assets using the RID graph that is contained in the shared framework's .deps.json file. So if a new RID came along, like LinuxEric, and I tried to run an app using SQLite, the host wouldn't know that LinuxEric should map to the linux RID. Thus the asset wouldn't get selected and my app would fail.

Instead, we should allow the app's .deps.json file to also bring in a RID graph which gets merged with the shared framework's RID graph. Then my app could map LinuxEric => linux and my app could now work correctly.

/cc @gkhanna79 @Petermarcu @ericstj @weshaggard

[gkhanna79]

So if a new RID came along, like LinuxEric, and I tried to run an app using SQLite, the host wouldn't know that LinuxEric should map to the linux RID.

If the host computed RID for the current OS is not in the RID fallback graph present with SharedFX, then we would use the fallback RID, which will be linux-* for the case above. Why would we need to have a RID fallback graph in the app unless our goal is to let external folks author their own RIDs and fallback graphs (something that we want to avoid, IIUC)?

[eerhardt]

Well, you need to take the scenario one step further. Now SQLite ships a LinuxEric native asset. (Or even better, as the maintainer of LinuxEric, I shipped a runtime.LinuxEric.SQLite package that contained the native asset for my distro.) Will it still find the asset correctly?

Or if LinuxEric is based off of debian, and there is a debian asset that should be used.

The whole point is, the RID graph that is in the Shared Framework isn't enough to satisfy all the RIDs in the world. We need to make it extensible for other RID graphs to be composed into an application.

unless our goal is to let external folks author their own RIDs and fallback graphs (something that we want to avoid, IIUC)?

Yes, this is the whole point of this issue. We DO want external folks to author their own RIDs and fallback graphs. With the move to only building for linux-x64, and build from source for all other distros, I think we need to allow this.

For a good discussion of the issue, see NuGet/Home#3114. The 2nd and 3rd problems listed there are this exact scenario. New distros. And trade secrets.

[gkhanna79]

If .NET Core does not support a new distribution of Linux (or Solaris) that has come out, what does it mean for someone to author an asset for it, using a custom RID, when the SharedFX does not exist for that platform (or does not work on it), even if the host can merge the RID fallback graph from FX and app? On the other hand, if it is possible for portable Linux RID sharedFX to work on such a new/unknown platform, I would imagine that we would expect assets for it to be authored as portable as well, no?

Is your scenario only lightup of new APIs in the custom RID for a platform not known to .NET Core?

[steveharter]

Is your scenario only lightup of new APIs in the custom RID for a platform not known to .NET Core?

@eerhardt any additional comments?

[eerhardt]

This isn't about lightup of new APIs. This is about new distributions and new versions of existing distributions being able to run .NET Core apps.

We currently have to encode all of the distros and versions of distros that we support in our shared framework's .deps.json RID graph. And if a new version comes out (say Fedora 27) apps won't be able to work correctly because we don't have an entry for Fedora 27 in the released RID graph. Instead, we need to ship a patched release just to update the RID graph with the new version.

[bording]

This the exact scenario I'm running into in https://github.com/dotnet/corefx/issues/23699. I need to be able target specific distros, but they just show up as linux-x64 if the framework's RID graph hasn't been updated.

Being able to supply my my own RID graph in my package would let me ship the optimal package, covering all the linux distros that .NET Core supports, with the minimum amount of separate libraries in the package.

[steveharter]

I'm assuming that an add-only approach is sufficient and we don't need to support removing a distro or version for example.

[eerhardt]

we don't need to support removing a distro or version for example.

Agreed, we shouldn't need to support removing.

[bording]

What about if the package defines something that is also in the shared version? Would it be allowed to supersede, or would that be considered an error?

[eerhardt]

The way RID graphs work is a single RID can "import" multiple base RIDs. So if a RID was in both, I would assume we just combine all the imports together into one.

The only issue is that the order of the imports is important (first one listed is searched first). There I would assume the app's imports would be merged first, and then the shared frameworks.

[bording]

The idea of merging the imports vs. one replacing the other is what I was getting at. If for some reason there was a RID defined in the shared graph that was missing an import that was important for my package, it sounds like I'd also be able to define it and add the import myself.

[bording]

One other question I thought of regarding this feature: Would the merging with the shared RID graph happen on a per-package basis? It doesn't seem like a good idea for the RIDs added in one package to be visible from another package.

[ericstj]

NuGet defines those semantics: any package can provide a portion of the RID graph. IIRC NuGet will allow additions to the graph and collisions are not supported (undefined behavior). /cc @emgarten

[steveharter]

Moving this out; feature complete is next week and this doesn't look like it will make it. If there's a broken scenario here in the 2.1 timeframe, please add that information.

I looks like some issues were resolved by adding missing RIDs: dotnet/corefx#26439

[steveharter]

To help prioritize this for 3.0, are there any additional thoughts? Is this still important considering we added the missing RIDs?

cc @leecow

[leecow]

I believe the issue to be solved is less about identifiable missing RIDS and more about arbitrarily extensible RID graph.

[eerhardt]

@leecow is correct. There will always be new RIDs coming that we didn’t know about when we ship.

Scenarios 2 & 3 listed here NuGet/Home#3114 are good descriptions of the issue.

[vitek-karas]

With the rework of RIDs in .NET 8 I think this looses some priority. Also our recommendation is to use portable RIDs whenever possible. Additionally, the host will not report EricsLinux RID even if the OS is called that, the host only reports portable RIDs by default (source builds are an exception, but those can also modify the RID graph accordingly).

Closing as I don't think we want to add this capability.