我最近一直在研究NServiceBus，因为我认为消息传递是减少系统之间依赖关系的好方法。然而，令我印象深刻的第一件事是消息发布者和所有订阅者必须共享消息定义DLL。在这种情况下会发生什么？：
假设有一个中央系统处理客户端数据。每当更改客户端记录时，它都会发布包含名称和地址的消息。这有十个订户，在收到消息时更新其本地数据副本。
有一天，需求发生变化，其中一个订阅者也需要客户电话号码。消息，发布者和受影响的订阅者都已更新以处理电话号码，并且它们都被重新编译和发布。
其他九个订户是否会继续不受影响？它们是否会像旧的Message DLL一样正常运行，还是需要使用新的DLL更新，重新编译和发布？
答案 0 :(得分：3)
NServiceBus体系结构旨在对消息结构更改具有弹性（特别是在更改涉及添加方案中的信息的情况下）。请参阅NServiceBus站点上的Versioning Sample页面。
答案 1 :(得分：1)
您不能像在版本控制示例中概述的那样在NSB中处理版本控制。
如果要在发送/接收方案中实施NSB，则可以执行此操作。在这种情况下，即使合同是消息DLL，也不需要在发送者和接收者之间共享相同的DLL版本。这是因为在线路上提供XML将在接收器端干净地反序列化一切都会很好。
然而，这在pub-sub场景中完全崩溃了。在这种情况下，依赖于发布者和订阅者之间共享的消息传递程序集的完全相同版本。这意味着版本，公钥令牌等都需要完全相同。原因是订阅机制。
当您的订户启动时，它会向发布者发送订阅消息，然后发布者将在订阅数据存储中输入订阅。此订阅适用于源自特定程序集版本的消息。
如果发布者然后更新它的消息DLL版本并收到它需要发布的消息，它将对它所持有的订阅进行查找并依次评估每个订阅。由于订阅存在于先前版本的消息程序集中，因此评估过程将忽略该订阅条目，因此不会向订阅者发送任何消息。
您需要了解pub-sub场景中的这种硬依赖关系。
希望这会有所帮助。
修改
从NServiceBus版本3.x开始，只要您的邮件程序集主要版本在发布者和订阅者之间共享，那么pub-sub将正常工作。