Message type detection

NServiceBus sets the NServiceBus.EnclosedMessageTypes header to the AssemblyQualifiedName of the emitted message type when sending, publishing, or replying.

It is possible to change the enclosed message type header for all emitted messages by using a behavior. The consumer-driven contracts sample shows how to manipulate the header for outgoing messages.

To invoke the correct message handlers for incoming messages, NServiceBus must be able to map the incoming transport message to a message type.

The mapping rules are as follows:

1. If the message contains the NServiceBus.EnclosedMessageTypes header, the header value is used to find the message type. The header value may contain:
   • The AssemblyQualifiedName of the message type (with or without the private key; both are supported). In cases when the assembly qualified type is not known by the endpoint, NServiceBus will fall back to any loaded type that matches the contained FullName, even when the type resides in a different assembly.
   • The FullName of the message type. NServiceBus will map it to any loaded type that matches the specified FullName, even when the type resides in a different assembly.
   • The Name of the type, without the assembly name.
2. If the header is missing, some serializers can optionally infer the message type based on the message payload. Serializers that support message type inference:
   • XML via the root node name
   • JSON.NET via a custom $type property

Custom type inference

A custom type inference behavior can be created when type inferences cannot be done using the incoming NServiceBus.EnclosedMessageTypes header and the serializer is not able to infer type information using the embedded message body. The custom behavior needs to be executed in the IncomingPhysicalMessageContext stage. It can infer the message type by inspecting any message header of body data using custom logic and add the NServiceBus.EnclosedMessageTypes header with the custom resolved message type.