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.
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.
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.