Rename message types

I want to rename message types, but need to ensure any queued will finish and errored messages can be retried. Typically, the way I do this is to rename the class, and then extend it with the old class, and then make sure both are routed. This involves a lot of work, and so I was looking to see if there was a way to custom map.

In Handlers • NServiceBus • Particular Docs , it discusses “Mapping to name” where it uses Assembly Qualified Name and FullName, but I don’t see anything to allow customization.

Is there a good/fast way to rename message types without breaking in process/errored messages?

Isn’t it simpler to create a new message type that’s a copy of the old one with a different class name and then:

  • add new handlers to receivers
  • stop publishing/sending the old one

After a while, when you’re sure that the old one is completely gone, no more in-flight and no more instances of the old one to retry, you can delete the old class and the old message handler.

I discussed the various options in a blog post Distributed systems evolution: message contracts

1 Like

Hi Mauro,

Yes, that is what I often do, which is good for a couple message types. But I want to change lots of message types, and the whole process is quite tedious. What’s unusual is that we can change the serialization/deserialization of the message contents, but it seems we can’t change the serialization/deserialization of the message name. As is, NSB strongly couples the implementation to the serialized data, but it doesn’t seem like it needs to be so.

NSB could configuring a custom mapper that allows serializing a type to a string, and deserializing a string to a type. This would allow full control over how things appear in SI/SP, and to decouple the implementation from the messages. That way developers can name message types the way they think they should be named, and support can see messages in SI/SP the way they thing it should be named

I realize it might not be quite as simple as I make it sound, because I assume some some logic in SC/SI/SP calculates the “Message Type” to be displayed from “NServiceBus.EnclosedMessageTypes”-- and so some constraints on the output string may be needed.

Sorry for my late response, it slipped through, and I missed your reply.

You can use a message mutator to manipulate the incoming transport message before deserialization starts. We have a sample covering a scenario that should be similar to yours: Change/Move Message Type • NServiceBus Samples • Particular Docs

Platform tools never deserialize the incoming message, so they don’t mind about the NServiceBus.EnclosedMessageTypes header content—you can tweak it to satisfy your needs.