.NET 程序集绑定方式/原因（1.1、2.0、GAC、策略文件等...）答案

【问题标题】：.NET Assembly Binding How/Why (1.1, 2.0, GAC, Policy Files and more...).NET 程序集绑定方式/原因（1.1、2.0、GAC、策略文件等...）
【发布时间】：2010-10-04 03:09:10
【问题描述】：

我一直在解决 GAC 中的一些 DLL 版本、策略文件和项目的一些非常“奇怪”的问题，在我的一生中，我一直无法找到关于如何/为什么 .NET 框架在绑定项目引用时选择它所做的程序集。

首先介绍一下我们所拥有的历史，我们有两个库 DLL 文件，其中包含以下信息

ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1234
ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1244
ApplicationAssembly.dll - .NET 2.0 code - .dll Version 02.00.00.1111

这些程序集中的每一个都加载到 GAC 中，并且 1.1 和 2.0 版本都有一个策略文件，指定要加载的最新版本。

我们有一个项目引用了 1.1.00.1234 版本的 ApplicationAssembly.dll 文件，但是，该项目已被移动，提示路径不再有效。但是，该引用并未失效，而是显示为 02.00.00.1111 版本，而不是预期的 1.1 版本的程序集。

这个过程是如何确定的，为什么会马上跳到 2.0 框架？如果我们指定它是“特定版本”引用，即使使用不正确的提示路径，它也会找到正确的 DLL，但由于将来有破坏东西的风险，我们不能让该设置保持打开状态。

我想问题是为什么会发生这种情况？ .NET 如何确定程序集的去向？

【问题讨论】：

标签： .net binding gac policyfiles

【解决方案1】：

Fusion（.Net 中的托管 dll 加载功能）用于定位 dll 的规则非常广泛（由于 Gac/强名称/自定义加载挂钩等等）。

官方规则大体处理here 由于您的库是强命名的，因此将应用更复杂的规则

【讨论】：

很好的链接！我一生都在尝试，但从未找到那篇文章！
知道加载引擎叫做 Fusion 有很大帮助。
应该让每个 .NET 开发人员在被允许编写代码之前了解运行时如何定位/加载程序集 :)