2011-02-10 17 views
11

MEFを使用して部品をロードするシステムがあります。これらの各部分は、コアライブラリに依存しています。また、MEF依存関係とバージョン管理

    • part1-1.0.0.0.dll part2-1.0.0.0.dll

    :私はプロジェクトをビルドするとき、私はこのような.dllファイルにバージョン番号を追加しますMEF合成を行うアプリケーションがあります。また、コアライブラリも使用します。私は、 "part" dllを配備するだけで済み、コンポーネントが依存しているコアライブラリを既にアプリケーションにロードしているため、コンポジションはうまくいきます。

    • /parts/part1-v1.dll
    • /parts/part2-v1.dll
    • 作曲-v1.exe
    • コア-v1.exe:だから、私のファイルシステムには、次のようになります

    私が抱えている問題は、コアと部品のバージョン管理の仕方です。コアとその部分の1つを更新したとします。次に、変更を展開します。

    • /parts/part1-v1.dll
    • /parts/part1-v2.dll
    • /parts/part2-v1.dll
    • 作曲:だから今、私のファイルシステムは、次のようになります-v1.exe
    • コア - v1.dll
    • コア-v2.dll私はパート1-v1.dllはコアv1.dll、およびpart1を-v2.dを使用していることを確認することができますどのよう

    core-v2.dllを使用しますか?私は、ロードする部品のすべてのバージョンと、適切なバージョンのコアを使用する必要があります。

    一部のクラスでは、このような何かを見て:

    [Export(typeof(IPart))] 
    public class Part1 
    { 
        public string GetSomethingFromCore() 
        { 
         return Core.GetSomethingFromCore(); 
        } 
    } 
    
    [Export(typeof(IPart))] 
    public class Part2 
    { 
        public string GetSomethingFromCore() 
        { 
         return Core.GetSomethingFromCore(); 
        } 
    } 
    

    答えて

    5

    strong namingあなたの問題の世話をしませんか?アセンブリが強力な名前付き依存関係に対して構築されている場合は、最後のバイトまで完全に同じ依存関係しか受け入れられないことがわかります。

    また、厳密な名前付けがあまりにも厳しい場合は、バージョン名を型名に入れることができます。たとえば、次のように参照されるアセンブリをロードするとき

    [Export(typeof(IPart))] 
    public class Part1v1 
    { 
        private readonly ICorev1 core; 
    
        [ImportingConstructor] 
        public Part1v1(ICorev1 core) 
        { 
         this.core = core; 
        } 
    } 
    
    [Export(typeof(IPart))] 
    public class Part1v2 
    { 
        private readonly ICorev2 core; 
    
        [ImportingConstructor] 
        public Part1v2(ICorev2 core) 
        { 
         this.core = core; 
        } 
    } 
    
    +3

    私はこのアプローチを取り戻すだろう。 Lanceが与えた例では、「コア」を静的に参照するように見えるため、Part1とPart2は実際には異なるスタティックシングルトンを参照するため、Wimは「コア」機能をインターフェイスに抽象化しています。予想される行動。 インターフェイスに機能を抽象化することによって、 'コア'引数は実際には異なるオブジェクト(ICorev1とICorev2)の2つの異なるバージョンを介して機能を公開する同じオブジェクトsingleton _instances_です。 – Adam

    +0

    すべてのMicrosoft Office相互運用機能アセンブリを見て、v8、v9、v10のdllなど(名前空間のバージョンを持つ)の仕組みに注意してください。それぞれの新しいバージョン_does_not_は、最後から機能を再定義しますが、_adds_に追加します。 内部クラスのコア::ICorev1、ICorev2 { ICorev1.GetSomethingFromCore(){} ICorev2.GetSomethingFromCore2(だから、メンテナンスの観点から、あなたの 'コア' の実装は、(時間をかけて)この(擬似コード)のようになります。 {{ }} – Adam

    1

    あなたは、あなたのコアアセンブリを与えるあなたの部品strong namesのすべてする必要があり、それらは完全一致が必要になります。これはまた、コアアセンブリの複数のコピーを展開する必要があることを意味します。私。代わりの

    • /parts/part1-v1.dll
    • /parts/part1-v2.dll
    • /parts/part2-v1.dll作曲-v1.exe
    • コア-v1。DLL
    • コア - v2.dll

    あなたが持っています:

    • /parts/1-1/part1-v1.dll
    • /部品/ 1-1 /コア-V1を.dllが
    • /parts/1-2/part1-v2.dll
    • /parts/1-2/core-v2.dll
    • /parts/2-1/part2-v1.dll
    • /parts/2-1/core-v1.dll
    • 作曲-v1.exe
    • コア - v1.dll
    • コア - v2.dll

    私がいることをやった方法過去には、必要なすべての依存関係とともに、各部分を別々のフォルダに格納するだけです。たとえ彼らが(現在)アプリケーションと同じバージョンであっても。アプリケーションがcore-v2に移行すると、core-v1に依存していたすべてのコンポーネントがそれを保持します。