With the introduction of AssemblyDependencyResolver in 3.0 we're making it relatively easy to dynamically load components with their entire dependency trees. Such components can be portable in the sense that they include RID specific assets (for example different asset for Windows and Linux).

In order to correctly resolve dependencies of such component, the AssemblyDependencyResolver must have a RID fallback graph to follow (so that when we're running on win10-x64, we know that we should also look for assets which are win-x64 or even win). The component itself should not carry the RID fallback graph with it (it would need to have the graph of all the RIDs there are and it would need to be updated with every addition).

Just like framework dependent apps which rely on the framework to provide the RID fallback graph, the component should rely on the host app to provide the RID fallback graph.

So if the host app is a framework dependent app, the RID fallback graph comes from the core framework Microsoft.NETCore.App. In this case everything works fine.

If the host app is a self-contained app, it in itself doesn't need a RID fallback graph since it's been built/published for one specific RID and thus it only carries assets which are necessary for that RID. But if a portable component is about to be loaded into such app, the RID fallback graph is necessary.

The proposal is to modify the SDK to include the RID fallback graph in self-contained app's .deps.json. It should be the graph filtered by the RID the app is targeting (just like what we do for the shared framework).

The problem is also discussed in https://github.com/dotnet/core-setup/issues/6960