我最近一直在尋找NServiceBus，因爲我認爲消息傳遞將是減少系統之間依賴關係的好方法。但是，讓我感到震驚的是，消息發佈者和所有訂閱者必須共享消息定義DLL。在這種情況下會發生什麼情況？：NServiceBus：共享消息DLL
假設有一箇中央系統處理客戶端數據。每當客戶記錄被更改時，它都會發布一條消息，其中包含名稱和地址。這有十個訂閱者，它們在收到該消息時更新他們的本地數據副本。
有一天，需求發生變化，其中一個用戶也需要客戶電話號碼。消息，發佈者和受影響的訂閱者全部更新以處理電話號碼，並且它們全部重新編譯併發布。
所有九個其他訂戶是否會繼續不受影響？它們是否會像舊的一樣正常運行舊的Message DLL，還是它們都需要用新的DLL進行更新，重新編譯併發布？
NServiceBus體系結構旨在對消息結構更改（特別是在涉及添加信息（如您的方案）中的信息更改）方面具有彈性。請參閱NServiceBus站點上的Versioning Sample頁面。
並非如此，您可以在NSB中處理版本控制，就像他們在版本控制示例中概述的那樣。
如果您在發送/接收方案中實施NSB，則可以執行此操作。在這種情況下，即使合同是一個消息DLL，也不需要在發送者和接收者之間共享相同的DLL版本。這是因爲在線路上提供XML將在接收端乾淨地反序列化，一切都會很好。
但是，這在pub-sub場景中完全崩潰。在這種情況下，發佈者和訂閱者之間共享的消息傳遞程序集的完全相同版本存在依賴關係。這意味着版本，公鑰令牌等都需要相同。原因是訂閱機制。
當您的訂閱者啓動時，它會向發佈者發送訂閱消息，發佈者然後將在訂閱數據存儲中輸入訂閱。此訂閱適用於源自特定彙編版本的消息。
如果發佈者隨後更新其消息DLL的版本並接收到需要發佈的消息，它將對其所持有的訂閱進行查找並依次評估每個消息。由於訂閱針對消息組件的先前版本而存在，因此評估過程將忽略該訂閱條目，因此不會將消息發送給訂閱者。
您需要注意pub-sub場景中的這種硬性依賴性。
希望這會有所幫助。
編輯
由於NServiceBus的3.x版本，只要組裝主要版本發佈者和用戶之間共享您的郵件，然後發佈 - 訂閱將恢復正常的。
我以前沒遇到過這個問題。通過使用一個通用的高級接口來避免特定類型的所有消息實現（並且不會改變）並訂閱它？ –
我還沒有嘗試過（界面作爲消息），但理論上這可以工作。正如你所說，那麼你可以分別爲發佈者/訂閱者發送實際消息。但在實踐中，我不知道，所以你不得不嘗試。 –
您試圖在服務之間共享的是消息模式，它恰好代表組件，因爲這是Microsoft給我們的框架。這種情況下的解決方案是不執行AssemblyVersion屬性，並始終將其保留爲1.0。如果您需要跟蹤版本，請增加AssemblyFileVersion屬性。您可以在不中斷髮布/訂閱機制的情況下做到這一點。 –
只是我需要的，ta。 –
情況並非如此。請參閱下面的答案。 –
它工作得很好 - 只是不增加AssemblyVersion屬性 - 改用AssemblyFileVersion。看到我對@ hugh的回答的評論。 –