Skip to content

Direct assemblies away from IsolatedComponentLoadContext towards a single AssemblyLoadContext #32851

Closed

Description

@obiwanjacobi

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.

Activity

  1. changed the title [-]Direct assemblies away from `IsolatedComponentLoadContext` towards AssemblyLoadContext.Default[/-] [+]Direct assemblies away from `IsolatedComponentLoadContext` towards a single AssemblyLoadContext[/+] on Feb 26, 2020
  2. obiwanjacobi commented on Feb 26, 2020

    @obiwanjacobi
    Author

    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.

    I hope this may benifit someone in the future.

    class MyAssemblyLoader
    {
        public Assembly LoadAssembly(string filePath)
        {
            var loadContext = AssemblyLoadContext.GetLoadContext(typeof(MyAssemblyLoader).Assembly);
            return loadContext.LoadFromAssemblyPath(filePath);
        }
    }
  3. ghost locked as resolved and limited conversation to collaborators on Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-AssemblyLoader-coreclronly use for closed issuesuntriagedNew issue has not been triaged by the area owner

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions