Describe the suggested improvement
Is your improvement related to a problem? Please describe.
While implementing support for CloudEvents, we noticed that developers must know all the headers that NServiceBus expects and their formats. That is inconvenient; it's a string/string dictionary where, in some cases, the value format is obscure, e.g., the special NServiceBus wire representation for dates, or what should go into the EnclosedMessageTypes.
Describe the suggested solution
It would be ideal if Core had an approach similar to the Azure ServiceBus SDK, where the ServiceBus message has a set of strongly typed properties for the well-known properties/headers and then a collection of ApplicationProperties for user-defined things.
So, instead of having MessageContext.Headers, an improvement would be to have:
MessageContext.MessageIdMessageContext.Sender or ReplyToMessageContext.EnclosedMessageTypes (as a Type[])- etc.. for all the well-known NServiceBus headers
Additional Context
No response
Describe the suggested improvement
Is your improvement related to a problem? Please describe.
While implementing support for CloudEvents, we noticed that developers must know all the headers that NServiceBus expects and their formats. That is inconvenient; it's a string/string dictionary where, in some cases, the value format is obscure, e.g., the special NServiceBus wire representation for dates, or what should go into the
EnclosedMessageTypes.Describe the suggested solution
It would be ideal if Core had an approach similar to the Azure ServiceBus SDK, where the ServiceBus message has a set of strongly typed properties for the well-known properties/headers and then a collection of ApplicationProperties for user-defined things.
So, instead of having
MessageContext.Headers, an improvement would be to have:MessageContext.MessageIdMessageContext.SenderorReplyToMessageContext.EnclosedMessageTypes(as aType[])Additional Context
No response