2008-11-17 105 views
0

在我们的处理软件中,我们正在从一个外部程序集版本转移到新版本。尽管程序集执行的总体任务是相同的,但API却有很大不同,并且没有向后兼容性。该API负责从外部站点提取数据,这些站点可能使用匹配的新API或旧API运行(也没有向后兼容性)。我们无法控制外部组件或外部站的软件。外部程序集未被强烈签名,并且程序集中的模块对于两个版本都具有相同的名称。使用版本化的.Net程序集

我们不希望维护两个版本的处理软件,而是动态演变,并使用旧版本或外部装配的新版本(取决于外部站点的联系)。我们可以确定外部站是否支持新版本,因此“版本”的选择可以更多或更少。

所以设置是我们有两个版本的外部程序集ComLib.dll。我们可以参考相同组件/项目中的两个版本,以及在确定类型时如何区分两个组件?

假设上述内容不能在单个程序集/项目中完成,我们可以实现特定于版本的“适配器”程序集,每个版本的外部程序集都有一个程序集(我认为我们已经有足够的接口和抽象这个),但有一些警告我们应该寻找或一些特定的设置,以避免运行时类型/版本混淆(程序集解析/加载等)?在.NET运行时中是否存在足够的“并行”支持?

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

对我来说似乎是我们想要的是每个版本的程序集都要在包含其配置文件和附加程序集的单独文件夹中加载一个“根”。这甚至可以使用标准的程序集解析器/加载器,或者我们必须手动执行一些魔术,并且可能会手动加载程序集(在单独的AppDomains中)以强制执行“根”文件夹?

回答

0

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

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

这样做会带来额外的好处,可以将您与外部供应商隔离,从而创建一个第三个 API版本,该版本不与前两个版本向后兼容。

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

相关问题