.NET Core多层插件模式实现困境：基于官方教程的问题

微软官方插件教程的支持情况 #

微软官方的《创建支持插件的.NET Core应用》教程原生不支持多层嵌套插件场景，它的设计目标是实现单层宿主-插件模型，没有考虑插件作为宿主再加载子插件的递归加载需求。

当前问题的核心原因 #

1. AssemblyLoadContext（ALC）隔离限制：每个插件加载时会使用独立的ALC，ALC之间默认是完全隔离的，子插件的ALC无法自动访问父插件或主应用ALC中的程序集（比如你提到的SubPluginInterop）。
2. 加载逻辑的局限性：你当前重写的Load方法仅处理了当前插件目录内的程序集解析，没有配置跨ALC的依赖共享规则，导致子插件无法找到共享的Interop程序集。

实现多层嵌套插件+依赖隔离的方案 #

基于.NET的AssemblyLoadContext机制，我们可以通过分层ALC设计来实现需求：

1. 构建分层ALC结构 #

• 创建一个共享ALC：用于加载所有插件都需要的公共依赖（比如SubPluginInterop），所有嵌套插件的ALC都可以引用这个共享ALC。
• 为每个插件（包括子插件）创建独立的私有ALC：用于加载插件自身的私有依赖，确保不同插件的依赖版本隔离。

2. 修改程序集解析逻辑 #

重写ALC的Load方法，优先从共享ALC加载公共依赖，再从自身插件目录加载私有依赖：

private readonly AssemblyLoadContext _sharedAlc;
private readonly IAssemblyPathResolver _resolver;

public PluginLoadContext(AssemblyLoadContext sharedAlc, IAssemblyPathResolver resolver)
{
    _sharedAlc = sharedAlc;
    _resolver = resolver;
}

protected override Assembly Load(AssemblyName assemblyName)
{
    // 优先从共享ALC加载公共依赖（如Interop程序集）
    var sharedAssembly = _sharedAlc.LoadFromAssemblyName(assemblyName);
    if (sharedAssembly != null)
    {
        return sharedAssembly;
    }

    // 从当前插件目录加载私有依赖
    string assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
    if (assemblyPath != null)
    {
        return LoadFromAssemblyPath(assemblyPath);
    }

    return null;
}

3. 配置共享依赖加载策略 #

• 将SubPluginInterop这类跨插件共享的程序集部署到主应用目录或独立的共享依赖目录中，由共享ALC统一加载。
• 在创建子插件的私有ALC时，传入共享ALC实例，确保子插件能找到共享依赖。

4. 嵌套插件加载流程 #

当插件需要加载子插件时：

1. 为子插件创建新的私有ALC实例，传入共享ALC和子插件的路径解析器。
2. 使用该私有ALC加载子插件程序集，避免复用父插件的ALC，保证依赖隔离性。

关键注意事项 #

• 避免ALC循环引用：子插件的ALC仅依赖共享ALC，不依赖父插件的ALC，防止内存泄漏和加载冲突。
• 私有依赖隔离：插件的私有依赖必须放在自身目录下，私有ALC不会自动加载其他插件目录的依赖，确保不同版本依赖共存。
• 资源清理：插件卸载时需手动释放对应的私有ALC，避免内存泄漏。

内容的提问来源于stack exchange，提问作者Vladimir Fekete