1

コンポーネントの 1 つが Nservice バス 2.6 で開発されている状況にあります。現在、古いサービスから消費される NSB 3.2 を使用した新しいコンポーネントの開発に取り組んでいます。NSB 3.2 から NSB 2.6 コンポーネントへのコントラクトの共有に問題があります。古いシステムをすぐに NSB 3.2 に移行することはできません。誰かが同様の問題を抱えていましたか？

4

2 に答える 2

2

特に、3.2 メッセージ コントラクトに控えめなモードを使用しようとしている場合は、IMessage インターフェイスにアクセスするために NServiceBus.dll バージョン 2.6 を参照するという NServiceBus 2.6 の厳しい要件に遭遇することになります。

もちろん、2.6 には IEvent と ICommand の概念もありません。

1 つの解決策は、3.2 メッセージ コントラクト アセンブリにデュアル プロジェクトを用意することです。

MyPublisher.Events-2-6.csproj
MyPublisher.Events-3-2.csproj

各プロジェクトは同じ C# ファイルを参照しますが、2.6 バージョンは 2.6 NServiceBus.dll を参照しますが、3.2 バージョンは 3.2 バージョンを参照するか、または Unobtrusive を使用している場合は、アセンブリ固有の IEvent、ICommand を定義する追加のファイルを含める可能性があります。 、IMessage インターフェイス。もちろん、名前空間名またはその他のメトリックに条件を使用してこれらを定義し、そのステップをスキップすることもできます。

#if次に、バージョン間の違いを指定するメッセージ コントラクト内のいくつかのブロックが最後に必要になる場合があります。次に例を示します。

#if NSBGT3
    public void MyEvent : IEvent
#else
    public void MyEvent : IMessage
#endif
    {
        // properties
    }

完全な開示：私はまだこれを自分で試したことはありません。これが私のやり方だと思っていました. それを試して、いくつかのメッセージを公開してから、それらを検査し、メッセージが適用されるタイプについてメッセージ XML に何が入るかを確認してください。これにより、NServiceBus 2.6 がそれらを適切に受け入れるかどうか、特にポリモーフィック メッセージ処理に関する問題が発生する場合に、より良いアイデアが得られます。もちろん、3.2 クライアントと 2.6 クライアントでもテストしたいと思うでしょう。

幸運を！

于 2012-05-29T16:55:32.283 に答える
0

古いシステムのクラスファイルを新しいシステムのソリューションにリンクすることをお勧めします。そうすれば、新しいNServiceBusバイナリでコンパイルされ、バージョンの競合を回避できます。

于 2012-05-30T06:29:52.110 に答える