The consumer interfaces in MassTransit all expect the message models to be classes and not structs. Since they are all inner interfaces (very nice design there I must say), this is the generic container class showing the constraint, taken directly from the source code:
/// <summary>
/// Declares a Consume method for the message type TMessage which is called
/// whenever a a message is received of the specified type.
/// </summary>
public static class Consumes<TMessage> where TMessage : class
This is not a problem for people starting out with the technology, but it was a hassle to us, since we already had objects related to the command pattern in our codebase before even considering the use of a service bus framework, and so we had to change quite a bunch of interfaces and generic classes to add that constraint for them to work with MT.
We were lucky for not explicitly having any struct types though, since that would probably cause even more (perhaps unwanted) changes.
Why does it require the message classes to be a class? Would it be possible to change that, so that the library interfaces more seamlessly with existing code? I figure that the constraint was not added for nothing though, so there are probably some complications.
In reality, all your message contracts should be interfaces. The abstraction should be removed from any logic and interfaces would enforce that. You can also compose delivery in interesting ways since MT will deliver to all matching routes in the inheritance/implementation hierarchy.
But regardless of what we suggest one does for the messages, it turns out that value types will not work the way we use them. We heavily depend upon type information and we can create proxies for the types delivered to your consumers.