.NET动态加载程序集时依赖未加载的原因咨询

这两种场景的差异核心在于构建阶段的依赖复制逻辑和**.NET程序集加载上下文的行为**两个方面：

1. 构建阶段的依赖复制差异 #

当A只通过B间接引用D时，项目构建系统只会复制“直接依赖”以及能通过传递引用链触达的程序集。但D对E的引用不会自动传递到A——因为A和E之间没有明确的引用关联（A→B→D→E这条链里，B并没有引用E，构建系统不会主动把D的依赖E复制到A的输出目录）。这就导致A的bin目录里只有D.dll，却没有E.dll。

而当A直接添加对D的引用后，D变成了A的直接依赖，构建系统会自动将D的所有传递依赖（包括E）复制到A的bin目录，为后续的依赖解析做好准备。

2. 程序集加载上下文的行为差异 #

• 当A直接引用D时，D会被.NET的默认加载上下文加载（要么在应用启动时，要么在首次调用D中类型时）。默认加载上下文会自动从应用基目录（A的bin目录）探测并加载所有依赖的程序集，只要文件存在就能正常解析。
• 当你通过Assembly.Load("D")动态加载D时，即使D.dll存在于bin目录，.NET在解析D的依赖E时，会因为E.dll不存在（或不在探测路径中）而无法加载E。而你要获取的SomeType很可能依赖E中的类型，此时类型元数据无法被完整解析，最终导致GetType返回null。

验证建议 #

你可以检查两种场景下A的bin目录：

• 不添加A对D的引用时，bin目录里应该没有E.dll；
• 添加引用后，E.dll会出现在bin目录中。

内容的提问来源于stack exchange，提问作者m.stm