1

プラグインアセンブリが「ホスト」アプリケーションに動的に読み込まれ、ホストアプリケーションとそのプラグインの両方が共通のアセンブリを参照するWPFプラグインベースのアプリケーションを開発しました。

将来、共通アセンブリのクラスを微調整したい場合、異なるバージョンで実行されている可能性のあるホストアプリケーション内でプラグインを機能させるために、すべてのプラグインを再コンパイルする必要はありません。一般的なアセンブリ。

シナリオ：

  • 一般的なアセンブリには2つのバージョン（1.1.0.0と1.2.0.0）があり、グローバルアセンブリキャッシュに署名して展開します。それぞれにクラス「Foo」が含まれており、バージョン間で変更されません。アーキテクチャのため、Fooは共通のアセンブリ内にとどまる必要があります。
  • ホストアプリケーションは、共通バージョン1.1.0.0に対して構築されており、すべてのプラグイン内のビューモデルを派生させることができる基本クラスを提供します。その機能は非常にUI中心であるため、ホストアプリケーション内にとどまる必要があります。
  • プラグイン＃1は、一般的なバージョン1.1.0.0に対して構築されています
  • プラグイン＃2は、一般的なバージョン1.2.0.0に対して構築されています
  • 使用される関連するサードパーティコンポーネント：MicrosoftのPrismとServiceLocationおよびCastle（Windsor）

一般：

public class Foo
{
    // Some useful properties
}

亭主：

public class ViewModelBase<T> where T : Foo
{
    // Some useful behaviour
}

プラグイン＃1：

public class ViewModel : ViewModelBase<Foo>
{

}

プラグイン＃2：

public class ViewModel : ViewModelBase<Foo>
{

}

問題：

プラグイン＃2をロードすると、バージョン1.1.0.0のFooクラスがバージョン1.2.0.0のFooクラスと同じとは見なされないため、ReflectionTypeLoadExceptionが発生します。そのため、ビューモデルのタイプパラメーターとしてFooを使用します。プラグイン＃2が無効です。

IDEAS：

  • より不変の「コア」共通アセンブリを使用してFooクラスを含める（ただし、最終的には、非常に多くの異なるアセンブリから非常に多くのクラスを取得する必要があります）。したがって、オプションではありません。

  • アセンブリリダイレクトの使用（ただし、プラグインにホストアプリケーションと同じバージョンの共通アセンブリの使用を強制しても、重大な変更がないことを保証するルールが設定されていない限り、開発中に機能するプラグインが展開後に機能し続けることは保証されません。廃止属性を使用して導入）

このように（単一または複数のアプリドメインで）真にサイドバイサイド（.NET Frameworkをサイドバイサイドと混同しないでください）のシナリオを実現できた人はいますか？


どうもありがとう、

ロブ

4

1 に答える 1

0

ホストアプリケーションのapp.configファイルでアセンブリリダイレクトを使用して問題を回避することは終了しました。

于 2013-05-09T13:05:44.247 に答える