运行时ProjectB如何定位不同构建配置下动态命名的ProjectA DLL？

项目结构 #

-Solution
   -ProjectA
   -ProjectB（包含指向ProjectA的csproj的ProjectReference引用）

两个项目的AssemblyName随构建配置动态变化：Debug配置下生成DebugProjectA.dll和DebugProjectB.dll；Release配置下生成ReleaseProjectA.dll和ReleaseProjectB.dll。ProjectA中类的命名空间始终为ProjectA.*。

问题解答 #

你的猜测是正确的，构建时ProjectA对应配置的AssemblyName会被存入ProjectB的程序集文件中，具体原理分为构建阶段和运行时阶段两部分：

构建阶段的处理逻辑 #

• 当ProjectB通过ProjectReference引用ProjectA时，MSBuild会遵循依赖优先构建原则：先构建当前配置（Debug/Release）下的ProjectA，确保生成对应命名的DLL文件。
• 构建ProjectB的过程中，MSBuild会读取ProjectA当前配置下的AssemblyName值（比如Debug模式下的DebugProjectA），并将这个名称写入ProjectB的程序集清单（Assembly Manifest）的AssemblyRef记录中。这个记录包含了ProjectB运行时需要加载的依赖程序集的核心标识（名称、版本、公钥令牌等）。
• 同时，MSBuild会自动将ProjectA构建生成的对应配置DLL复制到ProjectB的输出目录（如bin/Debug/net6.0），确保运行时两者处于同一探测路径下。

运行时的程序集加载逻辑 #

• CLR加载ProjectB程序集时，会先解析其程序集清单中的AssemblyRef信息，从中获取需要加载的ProjectA的AssemblyName（即动态生成的DebugProjectA或ReleaseProjectA）。
• 随后CLR按照默认的程序集探测规则查找：首先在应用程序域的基目录（也就是ProjectB的输出目录）中搜索匹配AssemblyName的DLL文件。
• 由于构建阶段已经将对应配置的ProjectA DLL复制到该目录，CLR能直接找到并加载目标DLL，完成依赖解析。

补充说明 #

ProjectA的命名空间ProjectA.*和动态变化的AssemblyName之间没有直接关联——CLR加载程序集完全依据AssemblyName，命名空间只是代码的逻辑组织方式，不影响程序集的查找与加载过程。

内容的提问来源于stack exchange，提问作者Krystian Sikora