PublishAot编译后动态加载程序集失败

Question

在使用 .NET 的 PublishAOT 发布原生 AOT 应用时，常见问题之一是动态加载程序集失败（如通过 `Assembly.LoadFrom` 或 `Assembly.LoadFile`）。这是因为在 AOT 编译过程中，所有代码必须在编译期可达，而动态加载的程序集无法被 IL 链接器包含，导致运行时找不到类型或方法。此外，AOT 不支持反射 emit 和部分反射场景，加剧了此问题。典型表现为 `FileNotFoundException` 或 `TypeLoadException`。解决方案包括将依赖程序集静态引用并标记为保留、使用 `DynamicDependencyAttribute` 显式声明依赖，或通过 `rd.xml` 配置保留策略，确保关键类型不被剪裁。

Answer 1

深入剖析 .NET 原生 AOT 发布中动态加载程序集失败问题

1. 问题背景与核心挑战

在使用 .NET 的 PublishAOT 构建原生 AOT 应用时，开发者常遇到动态加载程序集失败的问题。典型调用方式如 Assembly.LoadFrom(path) 或 Assembly.LoadFile(path) 在运行时抛出 FileNotFoundException 或 TypeLoadException。

根本原因在于：AOT（Ahead-of-Time）编译要求所有代码路径在编译期必须可达，而 IL 链接器（IL Linker）会剪裁未被静态引用的程序集和类型。动态加载的程序集无法被链接器识别，导致其代码未包含在最终输出中。

此外，AOT 不支持反射 emit（如 DynamicMethod、ILGenerator）以及部分高级反射操作（如 MethodInfo.MakeGenericMethod），进一步限制了动态行为的实现。

2. 典型错误场景分析

• 插件架构失效：通过目录扫描并动态加载 DLL 实现插件系统，在 AOT 下无法找到实际类型。
• 配置驱动加载：根据配置文件决定加载哪个程序集，逻辑虽正确但目标程序集被剪裁。
• 依赖注入容器初始化失败：某些 DI 框架使用反射遍历程序集注册服务，若程序集未保留则抛出异常。
• 序列化/反序列化问题：JSON 或 ORM 框架尝试反射创建未知类型实例，但类型已被移除。

3. 根本机制解析：AOT 编译与 IL 链接流程

AOT 编译过程包含以下关键阶段：

1. 源码编译为 IL（Intermediate Language）
2. IL 被 Native AOT 工具链转换为机器码
3. IL Linker 执行“剪裁”（Trimming），移除未调用的代码
4. 生成独立的本地可执行文件

其中第 3 步是问题的核心。由于 LoadFrom 加载的程序集不在静态依赖图中，Linker 判定其无引用，直接剔除。

4. 解决方案对比与实践策略

方案	适用场景	优点	缺点
静态引用 + [DynamicDependency]	已知依赖集	精确控制，性能最优	需提前知道类型
rd.xml 配置保留	复杂框架集成	灵活，兼容旧模式	易误配，增大体积
关闭剪裁 (PublishTrimmed=false)	调试或快速迁移	简单直接	失去 AOT 空间优势
源生成替代反射	高性能场景	零运行时开销	开发成本高

5. 代码示例：使用 DynamicDependencyAttribute 显式声明依赖

[DynamicDependency("MyPluginType", "MyNamespace.Plugin", "MyPluginAssembly")]
public void LoadPlugin()
{
    var assembly = Assembly.LoadFrom("MyPluginAssembly.dll");
    var type = assembly.GetType("MyNamespace.Plugin.MyPluginType");
    var instance = Activator.CreateInstance(type);
}

该属性通知 IL Linker 必须保留指定类型及其成员，防止被剪裁。

6. 使用 rd.xml 文件配置保留策略

在项目中添加 rd.xml 文件以声明保留规则：

<?xml version="1.0" encoding="utf-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <assembly name="MyPluginAssembly" dependency="normal">
    <type name="MyNamespace.Plugin.MyPluginType" dynamic="required" />
  </assembly>
</root>

此配置确保特定程序集中的类型即使未静态引用也不会被移除。

7. 架构设计层面的重构建议

对于重度依赖动态加载的系统，建议进行如下重构：

• 采用源生成器（Source Generator）在编译期生成注册代码，替代运行时扫描
• 定义接口契约，通过静态工厂或 DI 容器预注册实现类
• 将插件逻辑内联至主程序集，通过功能开关控制启用状态
• 使用 System.Reflection.Metadata 解析元数据而不加载程序集

8. 调试与诊断工具链支持

当遇到类型加载失败时，可通过以下手段定位问题：

1. 启用 TrimmerRootAssembly 标记关键程序集不被剪裁
2. 使用 dotnet ilverify 验证生成的本地二进制完整性
3. 查看中间构建输出目录中的 linked 程序集内容
4. 设置环境变量 DOTNET_ReadyToRun=0 排除干扰
5. 利用 ILLink.Descriptors.xml 编写细粒度保留规则

9. Mermaid 流程图：AOT 动态加载失败决策路径

graph TD
    A[尝试 Assembly.LoadFrom] --> B{程序集是否在静态依赖中?}
    B -- 否 --> C[IL Linker 剪裁该程序集]
    C --> D[运行时报 FileNotFoundException]
    B -- 是 --> E{是否标记为保留?}
    E -- 否 --> F[类型/方法被剪裁]
    F --> G[抛出 TypeLoadException]
    E -- 是 --> H[成功加载并实例化]
    H --> I[正常执行]
    

10. 高级技巧：结合 Source Generators 实现“伪动态”加载

利用 Roslyn 源生成器在编译期扫描插件程序集，并自动生成注册代码：

// GeneratedRegistration.g.cs
public static class PluginRegistry 
{
    public static object CreatePlugin(string typeName) 
    {
        return typeName switch 
        {
            "MyPluginType" => new MyNamespace.Plugin.MyPluginType(),
            _ => throw new InvalidOperationException()
        };
    }
}

这种方式既避免了运行时反射，又实现了类似动态加载的行为，完美适配 AOT。