Looking at the documentation you’re pointing to, I feel it omits a third option: using unobtrusive mode which is a convention based registration of your message types as described here and here. In that scenario, you would still package your messages and reference them in the sending and consuming endpoints, but the message types assembly or package, wouldn’t depend on a specific version of NServiceBus.
Can I ask what your current reasoning is behind going for option 2? Would it be solved by using the unobstrusive mode?
To answer your “best approach”-question, like always the answer is “It depends”.
For fairly small systems I think it’s fine to take a dependency on NSB, as long as it’s feasible to upgrade NSB across the board.
For larger systems however, my preference goes out to unobtrusive mode for a few reasons:
- You are not bound to a specific version of NServiceBus as you’re not taking any dependency on the package so you can gradually upgrade your system
- Convention-based message type naming increases the readability of your code as it reveals intent
The caveat there is that you need to be mindful of your naming across the board. NServiceBus will perform reflection based scanning to detect message types, so naming other classes that match with the specified convention will result in NServiceBus picking these up as well.
As for option 2, you are totally right to point out the
EnclosedMessageType. To get that to work, you would need to instruct NServiceBus to use full names instead of fully qualified assembly names as
EnclosedMessageType as described here.
I hope that helps,