In .NET Core 3.0 we're introducing AssemblyDependencyResolver which is a managed API to basically parse and process a .deps.json for a component (think plugin). The API uses existing algorithms in hostpolicy which are executed during application startup to process the .deps.json for the app.

Apps are allowed to contain assemblies which are also part of a framework which the app relies on. As an example app which relies on ASP.NET framework can also have a package reference for System.Threading.Channels (assembly which is part of the ASP.NET framework). The current behavior is:

• For self-contained apps, the SDK will pick the higher version of the two and copy it into the app (so if the package reference is higher it overwrites the one in the framework, otherwise the one from framework wins).
• For framework-dependent apps, the SDK will make the package assembly part of the app and it will write the assembly and file versions into the .deps.json. At runtime hostpolicy uses the version information to compare the assembly from the app against the one in the framework and it picks the one with the higher version.

Applying this logic to dynamically loaded components means that we would want the "framework dependent" behavior for components as well (we don't support self-contained components - that sort of doesn't make sense). Note that during component dependency resolution we intentionally ignore the assemblies from the app itself (this is to enable component isolation), but we do want to consider the frameworks (as frameworks are assumed to always be shared between the app and the components).

If the component is loaded into a framework dependent app, this is easy to solve as hostpolicy will apply the exact same logic and compare assembly and file versions for framework assemblies.

The problem is if the component is loaded into a self-contained app, there's no way to tell which assemblies are from a framework and which belong to the app itself. As noted above we want to consider the framework assemblies, but ignore the app assemblies.

The ask here is to add some information somewhere such that the dependency resolution could always tell which assemblies are framework assemblies, even in self-contained apps. For the hosting layer, putting this information into .deps.json would make a lot of sense, but if it makes sense to put it elsewhere, it might work as well.

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

We would be OK for this to not be solved in 3.0 as we probably don't have enough time to make the necessary hosting changes to support the new information coming from the SDK.