私たちの処理ソフトウェアでは、外部アセンブリのあるバージョンから新しいバージョンに移行しています。アセンブリが実行する全体的なタスクは同じですが、API は根本的に異なり、下位互換性は維持されていません。API は、一致する新しい API または古い API で実行されている外部ステーションからデータを抽出する役割を果たします (後方互換性もありません)。外部アセンブリまたは外部ステーションのソフトウェアを制御することはできません。外部アセンブリは強力に署名されておらず、アセンブリ内のモジュールは両方のバージョンで同じ名前になっています。
処理ソフトウェアの 2 つのバージョンを維持する代わりに、それを動的に進化させ、接続する外部ステーションに応じて、外部アセンブリの古いバージョンまたは新しいバージョンのいずれかを使用するようにします。外部ステーションが新しいバージョンをサポートしているかどうかを判断できるため、「バージョン」の選択は多かれ少なかれ明確になる可能性があります。
したがって、2 つのバージョンの外部アセンブリ ComLib.dll がセットアップされます。同じアセンブリ/プロジェクトから 2 つのバージョンを参照できますか?また、タイプなどを決定するときに 2 つのアセンブリをどのように区別できますか?
上記が単一のアセンブリ/プロジェクト内から実行できないと仮定すると、外部アセンブリの各バージョンに 1 つずつ、バージョン固有の「アダプター」アセンブリを実装できます (これには十分なインターフェイスと抽象化が既に用意されていると思います)。実行時のタイプ/バージョンの混乱 (アセンブリの解決/読み込みなど) を避けるために、注意すべき注意事項や特定の設定はありますか? このセットアップの .NET ランタイムには十分な「サイド バイ サイド」サポートがありますか?
更新: 物事をより面白くするために、この質問にさらにひねりが加えられています。外部アセンブリが追加のアセンブリを読み込み、外部構成ファイルを使用しているようです。異なるバージョンには異なる構成ファイルと異なる追加アセンブリが必要なため、各バージョンは、バージョンに一致する追加アセンブリを何らかの方法でロードする必要があります。
私たちが望むのは、各バージョンのアセンブリを、構成ファイルと追加のアセンブリを含む別のフォルダーに「ルート」でロードすることです。これは、標準のアセンブリ リゾルバー/ローダーでも可能ですか?それとも、「ルート」フォルダーを強制するために、何らかの魔法をかけてアセンブリを手動で (別の AppDomains で?) ロードする必要がありますか?