AssemblyLoadContext.Default in netcore 3.1 resolve the plugin type but can't excute its instance when the plugin use transitive dependency

Question

I have a console application in netcoreapp3.1 that use a netstandard2.0 plugin. The plugin reference a class library and implement an interface All dll dependencies are in the the plugin folder and the plugin.dep.json include all referenced library.

When I run:

AssemblyLoadContext.Default.LoadFromAssemblyPath("path/to/main_myplugin.dll");//load plugin

it resolve the type of interface

When i try to run an instance as given below it fail:

 if (type != null)  //type is resolved and not null
            {
                var instance = (IContract)Activator.CreateInstance(type); //instance is created
                Console.WriteLine($"Create instance  : {instance.GetType()}"); // ok instance is created
                var ret = instance.Execute(); //!!!fire exception here
                Console.WriteLine(ret);
            }

and fire error message:

System.IO.FileNotFoundException: 'Could not load file or assembly 'MyLibObjectsLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'

If I loaded all dependencies, it works fine.

Should I load all dependencies when using AssemblyLoadContext.Default or it's a bug?

Answer 1

I asked this question in the dotnet project

All credit go to @vitek-karas.

The detailed answer is:

Currently this is by design. LoadFromAssemblyPath as well as any other LoadAssembly-like methods only ever load that assembly, they don't try to load a "plugin". For this case to work you would need the AssemblyDependencyResolver and hook it up to the Default ALC (probably via the Resolving event), and hope that there are no collisions between the host app and the plugin (since they will share all dependencies) and so on. Generally this is why it's better to load plugins into their own ALCs as that creates the necessary isolation and also makes it easy to hook up AssemblyDependencyResolver.

Higher-level answer - in 3.0 we didn't try to provide a "plugin load" API as there were too many open questions in how it should behave (the exact isolation behavior is very tricky to get right so that it would work for most use cases). Instead we provided the necessary building blocks (ALC, ADR, diag improvements, ...) and rely on users to write the cca 20 lines of code to implement the custom ALC. In 5.0 we are improving diagnostics by adding detailed tracing around the entire assembly binding process, that should help debugging issues when loading assemblies in general, but specifically when implementing custom ALCs.