.NET 程序集绑定方式/原因(1.1、2.0、GAC、策略文件等...)

发布于 2024-07-13 07:12:00 字数 732 浏览 5 评论 0原文

我一直在解决一些与某些 DLL 版本、策略文件和 GAC 中的项目有关的非常“奇怪”的问题,而且我一直无法找到关于 . 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 如何确定程序集的位置?

I have been working through a number of very "odd" issues with some DLL versions, Policy Files, and items in the GAC and for the life of me I haven't been able to find a solid answer as to how/why the .NET framework picks the assemblies that it does, when binding project references.

First of all to give a bit of history about what we have, we have two library DLL files with the following information

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

Each of these assemblies are loaded into the GAC, and the 1.1 and 2.0 versions each have a policy file specifying the most current version for loading.

We have a project that references the 1.1.00.1234 version of the ApplicationAssembly.dll file, however, the project was moved and the hint path is no longer valid. However, the reference is not dead, but it is showing to the 02.00.00.1111 version and not the intended 1.1 version of the assembly.

How is this process determined, and why did it jump right away to the 2.0 framework? If we specify that it is a "Specific Version" reference, even with an incorrect hintpath it will find the proper DLL, but due to future risk of breaking things we cannot leave that setting turned on.

I guess the question is Why does this happen? And how does .NET determine where to go for the assembly?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

暖伴 2024-07-20 07:12:00

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

官方规则在此处进行了概括介绍
由于您的库具有强名称,因此将应用更复杂的规则

The rules Fusion (the managed dll loading functionality in .Net) uses to locate dlls is quite extensive (due to the Gac/strong names/custom loading hooks to name but a few).

The official rules are dealt with in broad strokes here
Since your library is strong named the more complex rules will apply

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文