public class ClassTests { [Fact] public void test() { var inputString = "{}"; var inputBytes = Encoding.UTF8.GetBytes(inputString); var payloadJsonStream = new MemoryStream(inputBytes); var brokeredMessage = new BrokeredMessage(payloadJsonStream, true); brokeredMessage.ContentType = "application/json"; var outputString = brokeredMessage.GetBody<String>(); Assert.Equal(inputString, outputString); } }
The primary problem here is that BrokeredMessage.GetBody<>() attempts to deserialize XML even if the content type is set to anything other than text/plain. In this example, I set the content type to "application/json" and try to pull a string out of the body but an exception is thrown complaining that the format of the message is not correct because it isn't valid XML.
I can work around this by calling BrokeredMessage.GetBody<Stream>() and the manually dealing with a stream of bytes, but this is not ideal. While I can appreciate not supporting a wide array of deserializers besides the XML deserializer, it seems unreasonable to treat String deserialization the same as object deserialization, especially in the face of an unknown content type.
In particular, this is problematic because as an application developer my choices are to set an incorrect contentType on the message so that the SDK is easier to work with (text/plain and GetBody<String>) or do more work on the consumer and producer ends and deal with everything as streams.
Ideally, I would like to be able to provide custom deserializers function, not deriving from XmlObjectSerializer. Then I can call GetBody<String>(MyCustomDeserializerMethod) and get out something more reasonable. At the least, I would like a way to tell ServiceBus to not assume everything is XML serialized.