バージョン管理された.Netアセンブリの使用

Question

処理ソフトウェアでは、外部アセンブリのあるバージョンから新しいバージョンに移行しています。アセンブリが実行する全体的なタスクは同じですが、APIは根本的に異なり、後方互換性は維持されていません。 APIは、一致する新しいAPIまたは古いAPIで実行されている可能性のある外部ステーションからデータを抽出します（後方互換性もありません）。外部アセンブリまたは外部ステーションのソフトウェアを制御することはできません。外部アセンブリは強く署名されておらず、アセンブリ内のモジュールは両方のバージョンで同じ名前を持っています。

処理ソフトウェアの2つのバージョンを維持するのではなく、動的に進化させて、外部ステーションに依存する外部アセンブリの古いバージョンまたは新しいバージョンのいずれかを使用するようにします。外部ステーションが新しいバージョンをサポートしているかどうかを判断できるため、「バージョン」の選択は多かれ少なかれ明示的です。

セットアップは、2つのバージョンの外部アセンブリComLib.dllがあります。同じアセンブリ/プロジェクトから2つのバージョンを参照できますか？タイプなどを決定するときに2つのアセンブリをどのように区別できますか？

上記を単一のアセンブリ/プロジェクト内から実行できないと仮定すると、バージョン固有の「アダプター」を実装できます。アセンブリ、外部アセンブリの各バージョンに1つ（このために十分なインターフェイスと抽象化が既に用意されていると思います）が、実行時に型/バージョンの混乱を避けるために注意すべきいくつかの特定の設定があります（アセンブリ解決） / loading etc））？ 「サイドバイサイド」で十分ですか？このセットアップの.NETランタイムでのサポート？

更新：物事をより面白くするために、この質問にさらにひねりを加えました。外部アセンブリが追加のアセンブリをロードし、外部構成ファイルを使用しているようです。異なるバージョンには異なる構成ファイルと異なる追加のアセンブリが必要なので、各バージョンは何らかの方法でバージョンに一致する追加のアセンブリもロードする必要があります。

＆quot; root＆quot;でロードされる各バージョンのアセンブリが欲しいと思う構成ファイルと追加のアセンブリを含む別のフォルダーに。これは標準のアセンブリリゾルバー/ローダーでも可能ですか、それとも「ルート」を強制するためにいくつかの魔法をかけ、おそらく（個別のAppDomainsで）手動でアセンブリを読み込む必要がありますか？フォルダ？

Answer 1

これに関するオプションについての良い投稿はここにあります： http：// kevin-berridge。 blogspot.com/2008/01/two-versions-of-same-shared-assembly.html

Answer 2

このコードは外部ステーションとの通信に使用されると言います。外部ステーションと通信するコードからサービスを作成してみませんか？そのサービスは現在のプログラムから呼び出されます。

これにより、古いAPI用と新しいAPI用の2つのバージョンのサービスを実行できます。各サービスは独自のプロセス（またはAppDomain）にあるため、好きなバージョンのアセンブリを読み込むことができます。メインプログラムがあるステーションから別のステーションに切り替わるプロセスでは、APIバージョンの変更に応じて、あるサービスから別のサービスに切り替えます。

これには、外部ベンダーからあなたを隔離して、最初の2つと後方互換性のない 3番目バージョンのAPIを作成するという追加の利点があります。

メインプログラムが名前付きパイプまたはメモリ内トランスポートを介してサービスと通信できるため、このソリューションのパフォーマンスは非常に高い可能性があります。 WCFは、ほとんどの場合、コードを変更することなく、トランスポート（バインディング）を切り替えることができます。

Answer 3

ILMerge を使用し、この手法を使用します同じプロジェクトからそれらを参照します。