问题描述
我正在编写一个需要 SQL Server SMO 库的 .NET 工具.我不在乎它是 Server 2005 (9.0)、2008 (10.0) 还是 2008 R2(可能是 10.5，没有检查)的版本.SMO 库与 SQL Server 一起安装，因此我可以放心地假设在任何安装了 SQL Server 的系统上，也可以使用某些版本的 SMO 库.
I'm writing a .NET tool that requires the SQL Server SMO library. I don't care if it's the version from Server 2005 (9.0), 2008 (10.0) or 2008 R2 (probably 10.5, didn't check). The SMO library is installed together SQL Server, so I can safely assume that on any system with SQL Server installed, some version of the SMO library is available as well.
不幸的是，SMO 库是强命名的:如果我在我的项目中添加对 SMO 9.0 的引用，如果客户的系统上仅存在 SMO 10.0，它将失败 (FileNotFoundException)，并且反之亦然.
Unfortunately, the SMO libraries are strongly-named: If I add a reference to SMO 9.0 in my project, it will fail (FileNotFoundException) if only SMO 10.0 is present on the customer's system, and vice versa.
有什么方法可以告诉编译器任何版本的库都适合我?或者我真的必须分发我的工具的 3 个相同版本，每个都编译为不同版本的 SMO?
Is there some way to tell the compiler that any version of the library is fine for me? Or do I really have to distribute 3 identical versions of my tool, each compiled to a different version of the SMO?
免责声明:我知道可以重新分发 SMO 库(以及 SMO 库所需的库).但是 (a) 一个 100KB 的超薄独立 EXE 和 (b) 一个安装了一大堆先决条件的成熟安装包之间存在很大差异.
免责声明 2:我知道以下重复项:
然而，提供的解决方案并不适合.在问题 1 中，开发人员可以控制引用的 DLL(我没有)；在问题 2 中，开发人员可以控制目标系统(我也没有).
推荐答案
据我所知，不可能消除对确切版本的依赖.这是强名称存在的原因之一 - 避免版本不匹配.程序集的内部甚至公共接口可能会在版本之间发生变化，您会发现新版本与旧版本不向后兼容.因此，.NET 会查找编译期间使用的版本，以确保应用程序正常工作.
As I know it is not possible to remove the dependency on exact version. That is one of reasons why strong names exist - to avoid version mismatch. Internals or even public interfaces of the assembly can change among version and you can find that new version is not backward compatible with the old one. Because of that .NET looks for version used during compilation to make sure that application works correctly.
如果第三方决定他们的新版本向后兼容，并且如果他们将程序集部署到 GAC，他们可以添加 发布商政策 将自动重定向.
If third party decides that their new version is backward compatible and if they deploy assembly to GAC they can add publisher policy which will do redirect automatically.
如果您决定要强制加载另一个程序集，您可以使用@chibacity 提到的方法或为 AppDomain.CurrentDomain.AssemblyResolve 实现处理程序.当 .NET 无法找到引用的程序集并且您可以实现自己的逻辑来找到它并通过调用 Assembly.LoadFrom 加载它时，将触发此事件.在这种情况下，完全取决于您加载哪个版本.
If you decide that you want to force loading another assembly you can use the approach mentioned by @chibacity or implement handler for AppDomain.CurrentDomain.AssemblyResolve. This event fires when .NET is not able to find referenced assembly and you can implement your own logic to find it and load it by calling Assembly.LoadFrom. In such case it is completely up to you which version you load.
这篇关于是否可以用“弱"程序集替换对强命名程序集的引用?参考?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！