To answer your question:
So what do I do if the event is published by several endpoints?
You can subscribe to the same event from multiple publishers by having multiple RegisterPublisher
calls from your subscriber.
Note that it's usually considered a smell if the same event is publishes from multiple logical endpoints. You might want to consider using different event types for each logical endpoint or maybe switch from an event to a command. If you're not sure about the message design, it's highly recommended to visit the Particular Software Google Group, people are very happy to help you with design questions which extend this SO question.
Regarding the change between V5 and V6:
In NSB5 I a subscriber would subscribe as I have shown above, by using its own endpoint name in the MessageEndpointMapping, and not the publisher's endpoint name.
I'm having a hard time following this statement. V5 and V6 use the same approach to subscribing, just a different syntax.
Since you're using MSMQ, a subscriber has to send a subscription message to each publisher of an event. For the subscriber to know where to send the subscription message, it needs routing information for this. This is where V5 and V6 use a different syntax:
- V5 will look for a matching route in it's MessageEndpointMappings. It will send the subscription message to the endpoint specified in the mappings (which would be
SubscribingEndpoint
in your sample code).
- V6 enforces separation between subscription messages and commands. That's why there are different APIs for routing regular commands and for routing subscription messages. Broker based transports (e.g. RabbitMQ) don't need subscription messages and therefore no routing for subscription messages is needed while every transport still requires routing information to send commands.
As you see, there is only a difference in syntax between V5 and V6, there should be no change in concepts. Since you claim that the above example works for you, I can only imagine a few reasons why that is so:
- Your logical endpoints share the same subscription storage, which might cause the subscription message sent to the subscriber endpoint to be visible to the publisher by accident.
- Your persistent subscription storage used by the publisher already contains a subscription from the subscriber. Although it might no longer receive subscription messages (because with your configuration it shouldn't) it still has an "old" subscription which is used by the publisher.
Whether one of these reasons might explain the behavior your seeing or not, when using MSMQ transport with NServiceBus, a subscriber always needs to have a route configured to the publisher in order for the subscription message to reach the publisher. This design didn't change between V5 and V6.
There is a nice sample demonstrating Publish/Subscribe in both V5 and V6 available on the Particular docs: https://docs.particular.net/samples/pubsub/?version=core_5
I have updated to NServiceBus 6, where the IProvideConfiguration and its MessageEndpointMappings are obsolete.
Please note, that in V6, both these APIs are obsoleted with a warning, but they still continue to work. These APIs will be removed in the next major version.
I hope this clears things up a bit.