Moving forward from #32769, I am trying to load a managed plugin assembly into a mixed C++/CLI dll that is in charge of gathering all the plugin's dependencies. I am porting this code from Full-Fx to netcore3.1 so I replaced my Assembly::Load calls with AssemblyLoadContext::LoadAssemblyXxxx calls after reading more about AssemblyLoadContext.

I also hook into the Resolving event for my probing path logic to execute and load into the AssemblyLoadContext.Default. That does not seem to be called (checked with breakpoint), however somehow the assembly in question is loaded.

There is a a common managed plugin interface that is located in a separate assembly: Jacobi.Vst.Core. The mixed C++/CLI assembly depends on it as well as the managed plugin we're trying to load.

I am experiencing the problem that my IPlugin (not the actual name) implemented by the plugin is 'not the same type' as the one the mixed C++/CLI assembly has, because that Jacobi.Vst.Core assembly was loaded into an 'IsolatedComponentLoadContext' while I load the plugin -and its Jacobi.Vst.Core dependency?- into AssemblyLoadContext.Default.

So my question is: Is my Resolving event handler not called because that is only used when netcore can't resolve it?
Would it be possible to load >everything< into a dedicated AssemblyLoadContext?

The mixed C++/CLI assembly already marshals calls between a 3rd party native host and the managed plugin, so I want to keep away from marshaling between AssemblyLoadContext's as well. It's a realtime audio application and performance is 'tight' as it is.