程序集加载版本不匹配：为什么要加载？

Question

我有两个程序集：HelloWorld.exe 和 Hello.dll。 exe是主程序集，而主程序集正在使用dll。

我编译了 HelloWorld.exe (1.0.0) 和 Hello.dll (1.0.0)。我将程序集放在不同的文件夹中。

然后我将 Hello.dll 的版本更改为 2.0.0 并继续用 2.0.0 版本覆盖 Hello.dll 1.0.0。然后我启动 HelloWorld.exe，它运行良好。

我预计它会立即崩溃并烧毁，因为我编译 EXE 时引用的 Hello.dll 是 1.0.0。现在，1.0.0 DLL 已被 2.0.0 替换，但它仍然可以工作！

根据MSDN：

默认情况下，程序集只会使用完全相同的类型 构建和测试它的程序集（名称和版本号）。 也就是说，如果您的程序集使用 1.0.0.2 版中的类型 另一个程序集，它将（默认情况下）不使用相同的类型 另一个程序集的 1.0.0.4 版本。这种名称和 识别引用程序集的版本有助于避免“DLL 地狱” 升级一个应用程序会破坏其他应用程序的问题。

问题：

1. 为什么有效？
2. 如何让它不起作用？
3. 额外问题：在构建过程中会发生什么？外部依赖的版本不是硬编码到主依赖的吗？

请注意，Hello.dll 不是强命名的。

这是 HelloWorld.exe 的清单：

// Metadata version: v2.0.50727
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
}
.assembly extern Hello
{
  .ver 2:0:0:0
}
.assembly HelloWorld
{
...//snipped
}

这是从 Fuslogvw.exe（程序集绑定日志查看器）获取的程序集绑定日志：

=== Pre-bind state information ===
LOG: User = ian.uy
LOG: DisplayName = Hello, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///C:/Users/ian.uy/Desktop/HelloWorld/HelloWorld/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/ian.uy/Desktop/HelloWorld/HelloWorld/bin/Debug/Hello.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\ian.uy\Desktop\HelloWorld\HelloWorld\bin\Debug\Hello.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
LOG: Binding succeeds. Returns assembly from C:\Users\ian.uy\Desktop\HelloWorld\HelloWorld\bin\Debug\Hello.dll.
LOG: Assembly is loaded in default load context.

Answer 1

为了版本控制，运行时区分常规程序集和强名称程序集。版本检查仅发生在强名称程序集上。

（来源：https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-versioning）

因此，答案如下：

为什么会奏效？

因为程序集不是强命名的

如何让它不起作用？

使程序集具有强名称

在构建过程中会发生什么？

视情况而定

• Use specific version = false：针对与项目中的引用匹配的第一个文件进行编译，采用任何版本
• Use specific version = true：针对找到的第一个与项目中指定版本的引用匹配的文件进行编译

外部依赖的版本不是硬编码到主依赖的吗？

是的，引用程序集的版本是硬编码的。您可以通过使用反编译器（例如 ILSpy）读取此信息来验证这一点

Answer 2

我也遇到过同样的事情，并试图查看 msbuild 日志：

msbuild /v:detailed /t:build

以下几行看起来很有趣：

统一依赖“Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed”。 在“C:\src\BindingTest\Lib1\bin\Debug\Lib1.dll”中使用此版本而不是原始版本“7.0.0.0”，因为 AutoUnify 是 '真实'。

此外，如果您在构建后查看生成的 app.config 文件，您可能会在那里看到您的 app.config 最初没有的自动绑定重定向。

所以我们观察到的行为与“automatic assembly unification”和“automatic binding redirection”msbuild 进程有关。

这是documentation 所说的关于AutoUnify 参数的内容：

当为 true 时，生成的依赖图会自动被视为 如果有一个 App.Config 文件传入 AppConfigFile 范围。这个虚拟 App.Config 文件有一个 bindingRedirect 条目 对于每组冲突的程序集，使得最高版本 组装被选中。这样做的结果是永远不会有 关于冲突程序集的警告，因为每次冲突都会 已经解决了。

当为 true 时，每次不同的重新映射都会产生高优先级 显示新旧版本的评论，并且 AutoUnify 是真实的。

最后，如果您想观察“失败”，您可以使用以下参数调用 msbuild：

msbuild /v:d /t:build /p:AutoUnifyAssemblyReferences=false;AutoGenerateBindingRedirects=false

Answer 3

为什么会奏效？

因为你已经指定了；）

如何让它不起作用？

1. 在解决方案资源管理器中右键单击 DLL
2. 选择属性
3. 选择使用特定版本

奖励问题：在构建过程中会发生什么？外部依赖的版本不是硬编码到主依赖的吗？

除非您指定，否则不会。默认情况下它是关闭的。设计良好的程序集应该是向后兼容的，版本应该不重要。