0
votes

I've been reading about the implications of upgrading NServiceBus to a new major version, for example, from version 6.x.x to 7.x.x.

At ParticularDocs site, the Upgrade Guides says this:

Thanks to the wire-compatibility guarantees, it is not necessary for every endpoint in the solution to use the same version of NServiceBus. This means that a single endpoint can be upgraded, tested, and deployed to production before upgrading another one.

But if you read about Unobstrusive Mode Messages it says this:

Message contracts can be defined using plain classes or interfaces. For NServiceBus to find those classes when scanning assemblies, they need to be marked with the IMessage interface, which essentially says, "this is a message definition". This allows decoupling message contracts from the NServiceBus assembly.

This dependency can cause problems when there are different services that run different versions of NServiceBus. Jonathan Oliver has a great write up on this very subject.

This is not a big deal for commands because they are always used within the boundary of a single service and it's fair to require a service to use the same version of NServiceBus. But when it comes to events, this becomes more of a problem since it requires the services to all use the same version of NServiceBus, thereby forcing them to upgrade NServiceBus all at once.

The former one tells us there is no problem upgrading nodes independently, but the latter seems to indicate that regard to message assemblies we'll have to mantain the same version and upgrade all at once.

If I have not misunderstood:

Since my nodes depend on my message assemblies, when I upgrade one node, I also have to upgrade their dependencies to the same major version, so that I'll be forced to upgrade my message assemblies too. Other nodes that use these same message assemblies will also need to be upgraded. This could scale in a chain of upgrades of all my system.

The only way to avoid this is to use the Unobstrusive Mode Messages?

We have all the messages implementing IEvent or ICommand. Change to Unobstrusive Mode Messages would be an inconvenience right now.

1
I think you have reached the correct conclusion, you will be better of moving to unobtrusive mode before you upgrade.Sean Farmar
I was afraid of it :). But I don't understand why a communication system based on serialized and deserialized messages depends on the version of the message assembly. If we have the same message schema, the same namespace and it's the same assembly name, why do these compatibility problems exist? I guess there is an explanation.Alpha75

1 Answers

0
votes

After a bit of digging around, there is a solution I overlooked, you can use assembly redirect, that should work for v 5.x and onwards.

Hope this helps