The scenario is using AssemblyDependencyResolver to dynamically load a component when running in a self-contained app.

The component can be portable, that means it has all necessary assets for all platforms included in it. It's .deps.json will have runtimeTarget sections which will describe which assets are to be used by which RID. For example it might have a native mycode.dll for Windows and libmycode.so for Linux.

In order for the dependency resolution to work correctly it needs to have a RID fallback graph. That is a data structure which describes how the various RIDs fallback. So for example it states that win10-x64 falls back to win-x64. That means that if we're running on win10-x64 and there are no win10-x64 specific assets, as a next step look at win-x64 assets and use those if available.

For applications the RID fallback graph is read from the Microsoft.NETCore.App.deps.json which is part of the Microsoft.NETCore.App framework. The RID fallback graph is only needed for portable apps and those must be framework dependent.

Self-contained apps are always RID specific and thus they only contain assets for the target RID. The RID resolution is performed at build time by the SDK/NuGet. So the .deps.json of a self-contained app does not include the RID fallback graph.

When AssemblyDependencyResolver is used it takes the RID fallback graph from the app. For framework dependent apps that will come from the core framework and everything works. But for self-contained apps, there's no RID fallback graph in the app. The result is that portable components don't work well when hosted by self-contained apps.

There's currently no workaround as there's no way to make SDK include the RID fallback graph in self-contained apps and similarly the component can't carry the RID fallback graph with it.