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