在我们的处理软件中,我们正在从外部组件的一个版本转向更新的版本。虽然程序集执行的总体任务是相同的,但 API 却截然不同,并且没有保持向后兼容性。API 负责从外部站提取数据,这些外部站可能运行着匹配的新的或旧的 API(也没有向后兼容性)。我们无法控制外部组件或外部站上的软件。外部程序集没有强签名,并且程序集中的模块对于两个版本具有相同的名称。

我们不想维护处理软件的两个版本,而是希望动态地改进它,并让它根据要联系的外部站使用旧版本或新版本的外部组件。我们能够确定外部站是否支持新版本,因此“版本”的选择可以或多或少明确。

因此,我们的设置是有一个外部程序集 ComLib.dll,有两个版本。我们可以引用同一程序集/项目中的两个版本吗?在确定类型等时如何区分这两个程序集?

假设上述操作无法在单个程序集/项目中完成,我们可以实现特定于版本的“适配器”程序集,每个版本的外部程序集都有一个(我认为我们已经为此准备了足够的接口和抽象),但是我们应该注意哪些注意事项或一些特定设置以避免运行时类型/版本混淆(程序集解析/加载等)?.NET 运行时是否对此设置有足够的“并行”支持?

更新:这个问题的进一步扭曲只是为了让事情变得更有趣。似乎外部程序集加载了其他程序集并使用外部配置文件。由于不同的版本需要不同的配置文件和不同的附加程序集,因此每个版本都需要以某种方式加载与其版本匹配的附加程序集。

在我看来,我们想要的是每个版本的程序集在包含其配置文件和附加程序集的单独文件夹中使用“根”加载。使用标准程序集解析器/加载器是否可以做到这一点,或者我们必须做一些魔术,也许手动加载程序集(在单独的AppDomains中?)以强制执行“根”文件夹?

有帮助吗?

解决方案

其他提示

你说这个代码是用来和外站通信的。为什么不使用与外部站通信的代码来制作服务呢?该服务将从您当前的程序中调用。

这将允许您运行两个版本的服务 - 一种用于旧 API,另一种用于新 API。每个服务都位于它自己的进程(或者可能是 AppDomain)中,因此可以加载它喜欢的程序集版本。在你的主程序从一个站切换到另一个站的过程中,随着API版本的变化,你会从一种服务切换到另一种服务。

这将具有将您与外部供应商隔离的额外好处,从而创建一个 第三 与前两个版本不向后兼容的 API 版本。

该解决方案的性能可能非常高,因为您的主程序可以通过命名管道甚至内存中传输与服务进行通信。WCF 可以在传输(绑定)之间切换,在大多数情况下无需更改代码。

您可以使用

scroll top