[Question] Why is not the given default context resolving the type if PreferSharedTypes is set to true

Hi,

first of all thank you for your effort on this project. This is a really nice project and I try to adapt it for our plugin system.

Since I need plugins that can have a reference to some other plugins I looked at this issue #60

I encountered some problems by trying the two suggested solutions and wanted to try another way.

Starting with my Idea I found that this following lines will not resolve the type defined in my created AssemblyLoadContext, but the type defined in the Assembly instance loaded by the PluginLoader.

string? pluginName = Path.GetFileName(pluginDirectory);
string assemblyFile = Path.Combine(pluginDirectory, pluginName + ".dll");

AssemblyLoadContext pluginAssemblyLoadContext = new AssemblyLoadContext(pluginName);
pluginAssemblyLoadContext.LoadFromAssemblyPath(assemblyFile);

PluginLoader loader = PluginLoader.CreateFromAssemblyFile(
    assemblyFile: assemblyFile,
    true,
    sharedTypes: Array.Empty<Type>(),
    config =>
    {
        config.DefaultContext = pluginAssemblyLoadContext;
        config.PreferSharedTypes = true;
    });

Assembly pluginAssembly = loader.LoadDefaultAssembly();
Type[] allTypes = pluginAssembly.GetTypes();

IEnumerable<Type> pluginTypes = allTypes.Where(t => typeof(IPlugin).IsAssignableFrom(t) && !t.IsAbstract);

Why is this? I’m not sure if I found all the available documentation about the ALC and this PluginLoader lib stuff, so maybe I just didn’t understand all that ALC fallback things right. My assumption was that it should be possible to build a tree of ALCs that has the default ALC (implicitly) as root.

I thought here https://github.com/natemcmaster/DotNetCorePlugins/blob/8312d70c90801f6caf3f39b6e1341d26689c5111/src/Plugins/Loader/ManagedLoadContext.cs#L100 this “routing” is done - but it seems that I missed something.

[natemcmaster]

Thanks for the updated diagrams and explanation. It was useful to learn from your example. I’m not planning on making changes to this library at the moment. I think your code is a good example of how to use AssemblyLoadContext if you have scenarios that extend beyond the current capability of this library, but I don’t see enough need for this right now to add anything to the library. I’ll leave this issue open for additional discussion. If there is more demand for something like this in the future, I’ll reconsider, but for now, it doesn’t appear to warrant the effort.

Thanks, Nate

[stale[bot]]

Closing because there was no response to the previous comment. If you are looking at this issue in the future and think it should be reopened, please make a comment and mention natemcmaster so he sees it.