I’m not sure I get the issue. Because initially I thought it worked correctly, until you mentioned that SQL Transport doesn’t show the behavior.
How subscriptions work in MSMQ is that every single time an endpoint is started, it figures out if it should be subscribed to certain events. If so, it will send a message to the appropriate endpoint to subscribe to those events. The reason it does this every single time, is because it has no idea if it ever subscribed before. So this is the expected behavior.
The receiving endpoint of those messages, need to store the subscription somehow. With MSMQ and SQL Transport you need persistence. With SQL Transport this is probably an easy choice. MSMQ has MSMQ Subscriptions, InMemory or SQL Persistence. Each subscription should only be stored once, obviously. And I get the impression that with MSMQ, the subscriptions is stored multiple times, in a different way? This is what isn’t clear to me. Perhaps you could share what exactly is stored, if you can find out.
What might have something to do with it is this line:
You can use that, but it’s not likely you should use an enum to differentiate between them. It’s unclear what options there are in the enum and what is provided, but usually, you’d use a number of GUID in there. It’s used for callbacks and sender-side-distribution. Do you make use of any of these? If not, you should probably remove that line.
endpointConfiguration.PurgeOnStartup(true); should probably be removed, since it will immediately remove the subscription messages that other endpoints might have sent.