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

Question

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

c#.net.net-assemblyassembly-resolutionassembly-binding-redirect

3

假设我有项目A、B和C。项目A引用了项目B（版本2.0.0.0）和项目C（版本3.0.0.0）。而项目B仅引用了项目C（版本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中，这个问题是如何解决的？为什么一开始需要绑定重定向呢？希望我的问题表达清楚。

- vladek

1

不再引用程序集，而是引用 NuGet 包或项目。但是，csc 编译器仍会在生成的 .exe/.dll 文件中使用传统的程序集引用。此外，在 .NET Core / .NET 5+ 的 .csproj 项目中，您仍然可以手动引用程序集，只是有点难找。 - Dai

有趣，我不知道这一点，感谢指出。我试图在这个问题上找到一些东西，但可能只是没有正确地使用谷歌搜索。 - vladek

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Elroy Flynn · Accepted Answer

如其他人所指出的，包版本与程序集版本是完全不同的东西。最终，您的构建仍然会引用一个程序集。只是这个程序集是以包的形式交付到您的构建环境中的。

您是正确的，.Net 5+ 不需要（默认情况下）在运行时匹配构建时使用的程序集版本。

我猜测，.Net 的早期设计试图解决“DLL 地狱”问题。通过将版本放置在程序集的元数据中来正式化 DLL 版本的概念，应用程序可以验证它是否得到了它期望得到的确切版本，从而具有可靠的行为。尽管如此，有时您仍希望能够使用更新的版本，而无需重新构建引用的应用程序，因此提供了

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