在我们的处理软件中，我们正在从一个版本的外部装配转移到更新版本。虽然程序集执行的总体任务是相同的，但API完全不同，并且没有保持向后兼容性。 API负责从外部站提取数据，这些数据可能与匹配的新API或旧API一起运行（也没有向后兼容性）。我们无法控制外部组件或外部站上的软件。外部程序集没有强签名，并且程序集中的模块对于两个版本都具有相同的名称。
我们不想维护我们处理软件的两个版本，而是希望动态地改进它，并让它使用外部装配的旧版本或新版本，这取决于要联系的外部站点。我们能够确定外部站是否支持新版本，因此“版本”的选择可能或多或少是明确的。
所以设置我们有两个版本的外部程序集ComLib.dll。我们可以引用同一个程序集/项目中的两个版本吗？在确定类型等时如何区分这两个程序集？
假设上述不能在单个程序集/项目中完成，我们可以实现特定于版本的“适配器”程序集，每个版本的外部程序集一个（我认为我们已经有足够的接口和抽象） ）但是我们应该注意一些警告或一些特定的设置，以避免运行时类型/版本混淆（程序集解析/加载等）？对于此设置，.NET运行时是否有足够的“并排”支持？
更新：为了让事情变得更有趣，我们还会进一步提出这个问题。似乎外部程序集加载其他程序集并使用外部配置文件。由于不同的版本需要不同的配置文件和不同的附加程序集，因此每个版本都需要以某种方式加载与其版本匹配的附加程序集。
在我看来，我们想要的是每个版本的程序集在一个单独的文件夹中加载“root”，该文件夹包含其配置文件和其他程序集。这是否可以使用标准的程序集解析器/加载器，或者我们是否需要做一些魔术并且可能手动加载程序集（在单独的AppDomains中？）来强制执行“root”文件夹？
答案 0 :(得分：2)
有关此选项的好帖子可以在这里找到： http://kevin-berridge.blogspot.com/2008/01/two-versions-of-same-shared-assembly.html
答案 1 :(得分：0)
您可以使用ILMerge自行签署程序集，然后使用this technique从同一项目中引用它们。
答案 2 :(得分：0)
您说此代码用于与外部工作站通信。为什么不从与外部站通信的代码中提供服务？该服务将从您当前的程序中调用。
这将允许您运行两个版本的服务 - 一个用于旧API，另一个用于新API。每个服务都在它自己的进程（或者可能是AppDomain）中，因此可以加载它喜欢的程序集的版本。在主程序从一个站切换到另一个站的过程中，随着API版本的变化，您将从一个服务切换到另一个服务。
这样做的另一个好处是可以将您与外部供应商隔离，从而创建与前两个版本无向后兼容的第三个版本的API。
此解决方案的性能可能非常高，因为您的主程序可以通过命名管道与服务进行通信，甚至可以与内存中的传输进行通信。 WCF可以在传输（绑定）之间切换，在大多数情况下不会更改代码。