一点背景知识:我们有一个应用程序使用 3 个核心 DLL,这些 DLL 被应用程序的不同部分引用。这三个 DLL 在 GAC 中。在我们的测试环境中,我们有 3 个测试网站(相同网站,不同版本)都使用 GAC 中的 DLL,以及 bin\ 中的产品特定 DLL。
我们遇到了一种情况,其中一种产品需要更新这些核心 DLL,但我们不想将程序集放在 GAC 中,因为我们的特定测试网站是唯一引用这些 DLL 的网站。我们知道我们可以在 GAC 中放置一个程序集的多个版本,但这与这个特定问题无关,因为我们选择不这样做。
我自己的研究表明,一群人似乎对自己的答案非常有信心,但他们中的大多数人不同:运行时定位程序集。大多数人说GAC 优先,根据我自己的经验,情况就是如此。其他人说,只要程序集没有被强烈命名,它将更喜欢 bin\ 而不是 GAC,根据我的经验,这是不正确的。
我找到了这篇 MS 文章:
它描述了 CLR 确定要绑定到哪些程序集的步骤。事实证明,这并不完全符合预期。所有这些很可能是一个环境问题(我实际上会这样倾斜)。
我还发现这个SO 问题与我读过的其他问题相似,但不一定是我需要的答案
我终于找到了一个比 GAC 更喜欢 bin\ 的解决方法。我在我们的 web.config 中使用了这个标签。我在 SO 和其他网站上看到了这个建议,并且间歇性地成功了,并且很高兴它在我的情况下有效。
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="dll1" publicKeyToken="ourToken"
culture="neutral" />
<bindingRedirect oldVersion="5.0.0.0" newVersion="5.0.1.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
版本 5.0.1.0 在我的 bin\ 文件夹中。5.0.0.0 在 GAC 中。最后我的问题是,即使 5.0.1.0 不是 GAC 中的程序集,CLR 怎么知道它需要在 bin\ 中查找要绑定的正确程序集?在 .config 中添加标记之前,无论项目是使用什么程序集版本 (5.0.1.0) 构建的,应用程序仍然更喜欢 GAC (5.0.0.0) 中的旧版本 DLL。
我无法找到任何有关此的文档,很可能是因为我不知道如何将这 5 段解释分解为搜索查询。任何参考资料都将不胜感激,甚至可能对上面引用的文章进行澄清,这样我就可以了解 CLR 为何正在做它正在做的事情。