.NET 6 如何处理程序集引用冲突?

发布于 2025-01-16 11:38:49 字数 661 浏览 3 评论 0原文

假设我有项目 A、B 和 C。项目 A 引用项目 B (v. 2.0.0.0) 和 C (v. 3.0.0.0)。项目 B 仅引用项目 C (v. 1.0.0.0)。我们遇到了冲突,因为项目 A 和 B 依赖于项目 C 的不同程序集版本。在 .NET 框架中,我们使用绑定重定向解决了这个问题。在项目 A 的 app.config 文件(作为主项目)中,我们添加:

<dependentAssembly>
    <assemblyIdentity name="C"  
                      publicKeyToken="<somePublicKeyToken>"  
                      culture="en-us" />  

    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />  
</dependentAssembly>

我相信绑定重定向不再是 .NET Core 和 .NET 5 中的问题。我们引用 NuGet 包或项目,而不是引用程序集。我的问题是:这个问题在新版本的.NET 中是如何解决的?为什么绑定重定向首先是一个问题?希望我的问题有意义。

Let's say I got projects A, B and C. Project A references projects B (v. 2.0.0.0) and C (v. 3.0.0.0). Project B references only project C (v. 1.0.0.0). We got a conflict on our hands, since project A and B depend on different assembly versions of project C. In .NET framework we solve this issue using binding redirects. In Project A's app.config file (being the main project) we add:

<dependentAssembly>
    <assemblyIdentity name="C"  
                      publicKeyToken="<somePublicKeyToken>"  
                      culture="en-us" />  

    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />  
</dependentAssembly>

I believe that binding redirects are no longer a thing in .NET Core and .NET 5 forward. Instead of referencing an assembly, we reference a NuGet package or a project. My question is: how is this issue solved in newer version of .NET? Why were binding redirects a thing in the first place? Hope my question makes sense.

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

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

发布评论

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

评论(1

寂寞美少年 2025-01-23 11:38:49

正如其他人指出的那样,软件包版本与汇编版本完全不同。最后,您的构建仍然引用程序集。碰巧该程序集是通过包传递到您的构建环境的。

您是正确的,.Net 5+ 不(默认情况下)要求运行时使用的程序集版本与构建时使用的程序集版本匹配。

我推测 .Net 的早期设计是试图解决“DLL Hell”问题。通过形式化 DLL 版本的概念(通过将版本放置在程序集的元数据中),应用程序可以验证它是否获得了它期望获得的版本,因此将具有可靠的行为。尽管如此,您有时还是希望能够使用较新的版本,而不需要重建引用应用程序,因此提供了

.Net Core 认识到这不是一个成功的设计。新方法 a) 忽略强命名:它不影响行为。 b) 默认允许在运行时使用任何版本,c) 提供了一种用于强制执行版本策略的新机制:AssemblyLoadContext

As others pointed out, a package version is a completely different thing from an assembly version. In the end, your build still refers to an assembly. It just happens that the assembly was delivered to your build environment in a package.

You are correct that .Net 5+ does not (by default) require that the assembly version used at runtime match the assembly version used at build time.

I'll speculate that the early design of .Net was attempting to address the "DLL Hell" problem. By formalizing the notion of the DLL version (by placing the version in the metadata of the assembly), an application could verify that it was getting exactly the version that it expected to get, and so would have dependable behavior. Still, you wanted to be able to use a newer version at times, without rebuilding the referring application, so <bindingRedirect was provided.

.Net Core recognizes that it wasn't a successful design. The new approach a) ignores strong naming: it doesn't affect behavior. b) defaults to allowing any version at runtime, and c) provides a new mechanism for enforcing version policy: AssemblyLoadContext

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