使用版本化的 .Net 程序集

Question

在我们的处理软件中，我们正在从外部程序集的一个版本迁移到新版本。虽然程序集执行的总体任务是相同的，但 API 完全不同，并且没有保持向后兼容性。 API 负责从外部站点提取数据，这些站点可能与匹配的新旧 API 一起运行（也没有向后兼容性）。我们无法控制外部程序集或外部工作站中的软件。外部程序集没有强签名，并且程序集中的模块在两个版本中具有相同的名称。

我们不想维护我们的处理软件的两个版本，而是希望动态地发展它，让它使用旧版本或新版本的外部程序集，这取决于要联系的外部站。我们能够确定外部站是否支持新版本，因此“版本”的选择可以或多或少明确。

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

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

更新：为了让事情更有趣，对这个问题添加了进一步的转折。似乎外部程序集加载了其他程序集并使用了外部配置文件。由于不同的版本需要不同的配置文件和不同的附加程序集，每个版本都需要以某种方式加载与其版本相匹配的附加程序集。

在我看来，我们想要的是每个版本的程序集在包含其配置文件和其他程序集的单独文件夹中加载一个“根”。这甚至可以通过标准程序集解析器/加载器实现，还是我们必须做一些魔术并可能手动加载程序集（在单独的 AppDomains 中？）以强制执行“根”文件夹？

Answer 1

可以在此处找到有关此选项的好帖子： http://kevin-berridge.blogspot.com/2008/01/two-versions-of-same-shared-assembly.html

Answer 2

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

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

这还有一个额外的好处，就是将您与外部供应商隔离开来，创建一个与前两个不向后兼容的 API 第三个​​版本。

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

Answer 3

您可以使用ILMerge 自己对程序集进行签名，然后使用this technique 从同一项目中引用它们。