你没有做错任何事。但是我认为您缺少有关程序集引用的关键知识。并且有一些方法可以处理它,既适合您也适合 SAP。
当 .NET 引用程序集时,它会根据编译时使用的确切版本执行此操作。这意味着如果在运行时版本号不同,默认情况下会失败。用于强名称程序集或区域性的签名密钥的差异也可能导致程序集加载失败。这个previous answer 讨论了这个问题,并提出了一种使用AssemblyResolve 事件处理它的方法。如果您的应用程序具有复杂的插件加载机制,您可能还有很多工作要做,但如果它真的很简单,您可以轻松更新它。当然,如果客户端数据库进行重大更改,您仍然会遇到问题,但它们将是不同的问题。
另一种方法是自己将应用程序的configuration file 编辑为redirect assembly versions。有时甚至设置 Nuget 包以自动将这些重定向插入到应用程序配置文件中。不幸的是,考虑到版本更改的频率,这对于 HANA 来说并不是一个简单的策略。您需要知道执行此操作的确切版本。因此,如果您将应用程序部署到具有不同 HANA 版本的多个客户端,这可能会有点像噩梦。
可悲的是,发布库的供应商已经有一个现有的机制来处理此类事情。它被称为publisher policy assembly,但 SAP 通过包含(和嵌入)有史以来最无用的绑定重定向,搞砸了它的策略组合交付。
通常,使用绑定重定向的目的是允许将程序集无缝升级到更新版本,只要您的类型没有显着更改其公共接口。您只需在 XML 中指定此版本可以处理的版本范围。
然而,SAP 将其作为绑定重定向元素:
<bindingRedirect oldVersion="1.0.120.0-1.0.120.0" newVersion="1.0.120.0" />
只允许他们的 DB 客户端当前安装的版本(在本例中为 1.0.120.0),这对您有什么好处。不,对于这种严格的版本控制,该 DLL 没有改变其 ADO.NET 类。就我而言,关于不同程序集版本的一切都是完全相同的。
如果我有能力与 HANA 团队中理智的人取得联系,并有足够的影响力来解决此问题,我建议他们将 oldVersion 属性正确设置为最旧的可升级版本,并升级每个后续驱动程序包。所以如果你安装了1.0.120.0,它看起来更像是这样的:
<bindingRedirect oldVersion="1.0.9.0-1.0.120.0" newVersion="1.0.120.0" />
然后它可以被机器上的任何软件使用而无需额外的努力。我的意思是,它在GAC 中。对他们来说,让这变得更容易一点也不费力。尽管他们需要修补所有版本的 HANA 客户端,但许多应用程序(甚至是 SAP 提供的应用程序)都与特定的 HANA 版本相关联。如果他们只在最新版本中修复它,我们在几年内都看不到好处。