You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Direct assemblies away from IsolatedComponentLoadContext towards a single AssemblyLoadContext #32851
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.
changed the title [-]Direct assemblies away from `IsolatedComponentLoadContext` towards AssemblyLoadContext.Default[/-][+]Direct assemblies away from `IsolatedComponentLoadContext` towards a single AssemblyLoadContext[/+]on Feb 26, 2020
I am a bit embarrassed to have posted the question.
I was stuck in thinking that everything had to go into AssemblyLoadContext.Default but that is not the case - its not even the best solution for my scenario. Once I let go of that I realized that I could simply load the managed plugin assembly into the same AssemblyLoadContext the code was executing from.
Activity
[-]Direct assemblies away from `IsolatedComponentLoadContext` towards AssemblyLoadContext.Default[/-][+]Direct assemblies away from `IsolatedComponentLoadContext` towards a single AssemblyLoadContext[/+]obiwanjacobi commentedon Feb 26, 2020
I am a bit embarrassed to have posted the question.
I was stuck in thinking that everything had to go into
AssemblyLoadContext.Defaultbut that is not the case - its not even the best solution for my scenario. Once I let go of that I realized that I could simply load the managed plugin assembly into the sameAssemblyLoadContextthe code was executing from.I hope this may benifit someone in the future.