問題タブ [nservicebus6]

NServiceBus を v6 に移行する過程にあり、IBus への参照を削除する過程で障害があります。

多くのアプリケーション (Web サイト、マイクロ サービスなど) の共通ライブラリを構築します。このライブラリには、本質的に送信および公開インターフェイスである IEventPublisher の概念があります。このライブラリには NSB の知識がありません。次に、アプリケーションから DI を使用してこの IEventPublisher の実装を提供できます。これにより、ライブラリのメッセージ パッシングを別のテクノロジに簡単に置き換えることができます。

最終的には、次のような実装になります

これは実際に何が起こるかを単純化したものですが、私の問題を示しています。DI コンテナーが IEventPublisher を要求されると、NsbEventPublisher を返すことを認識し、Web サイトのブートストラップでこれをコンテナーにシングルトンとしてバインドするため、IEndpointInstance を解決することを認識します。すべて問題なく、私のサイトは完璧に動作します。

現在、マイクロ サービス (NSB.Host で実行) を移行していますが、メッセージ ハンドラー内の依存関係を解決するときに、DI コンテナーが IEndpointInstance の解決を拒否しています。ドキュメントを読むことは意図的なものであり、メッセージ ハンドラーでは IMessageHandlerContext を使用する必要があります。 https://docs.particular.net/nservicebus/upgrades/5to6/moving-away-from-ibus ドキュメントは、クラス MyContextAccessingDependency の周りの一番下の例で私が抱えている問題を回避しています。提案は、メッセージ ハンドラーのコンテキストで実行されているコードに強い依存関係を置くメソッドを介してメッセージ コンテキストを渡すことです。

私がやりたいことは、送信者/発行者にアクセスできることであり、DI コンテナーは正しい実装を提供してくれます。このコードは、呼び出し元の概念を必要とせず、メッセージ ハンドラーから呼び出された場合や、パブリッシュするだけの自己ホスト型アプリケーションから呼び出された場合も必要ありません。

IMessageHandlerContext および IEndpointInstance インターフェイスがそれぞれ拡張する「バス」 IPipelineContext および IMessageSession と通信するための 2 つのインターフェイスがあることがわかります。私が疑問に思っているのは、NSB によってコンテナーにバインドされる 2 つのインターフェースが統合されているため、メッセージを送信/公開するインターフェースを受け入れることができるということです。ハンドラーでは IMessageHandlerContext であり、自己ホスト型アプリケーションでは IEndPointInstance です。

今のところ、アプリケーションのホスティングに応じて IEventPublisher の実装を変更しようとしています。コードパスの実行を開始したものに関係なく、送信/公開するための信頼できるインターフェイスなしで、このアプローチをモデル化する方法についていくつかの議論があることを望んでいました.

NServicebus メッセージングを使用して RabbitMQ 経由で通信する 2 つのデプロイ済みサービスがあります。ただし、マイクロサービスは RabbitMq で異なる仮想ホストを使用しており、送信されたメッセージは取得されていません。

両方のサービスをローカルで実行し、同じ仮想ホストを使用すると、すべてが機能します。メッセージが仮想ホストを通過できない理由はありますか?また、異なる仮想ホストでサービスを複数回展開することなく、この問題を回避する方法はありますか?

送信オプションにはコードで仮想ホストを指定する方法があると思いますが、機能するものが見つかりません

NserviceBus 6 エンドポイントは、NServiceBus バス 5 エンドポイントにメッセージを送信できますか?

2 つの .Net プロジェクトがあり、1 つはバージョン 6 でエンドポイントを定義し、バージョン 5 で定義されたエンドポイントにメッセージを送信します。これは、互換性がないためですか？