mookid8000
commented
6 years ago It's up to the serializer to take the incoming message and represent it as something meaningful, which usually happens by looking up a C# class with the type as specified by the rbs2-msg-type header.
When the type specified in the header cannot be found, it will fall back to deserializing the message as a JObject, which makes it possible to handle any type of message by creating a handler that implements IHandleMessages<JObject>, which can then peek around in the JSON object.
If that's not what you want, I suggest you either a) share a DLL with your message types, so that subscriber can deserialize into a proper class, or b) inject an incoming pipeline step that takes that JObject and turns it into something else, or c) replace the serializer alltogether, which will then give you the opportunity to basically do whatever you want 😁
Let me know if this is not clear to you 😄
arielmoraes
@mookid8000 answered my SO question about how to keep message references decoupled by using custom topic names, but when the pipeline tries to deserialize the incoming message body the expected type to find the handlers is
Newtonsoft.Json.Linq.JObject. Is there a way to replace the native implementation that Rebus uses to find the IHandleMessages to use the name of the Event instead of the type?