After Visual Studio has finished opening the solution, on your screen you should see the picture to the left.
Before running the sample, take some time to look over the solution structure, the projects that are there, and the classes inside them.
The projects "MyPublisher", "Subscriber1", and "Subscriber2" each are their own process, even though they look like regular class libraries.
The project "Messages" contains the definition of the messages that will be sent between the processes. Open the "Messages.cs" class and you'll see a class called "EventMessage" and an interface called "IEvent".
The "MyPublisher" process will be publishing each of these message alternately, every time you press the 'Enter' key in its console window.
The "Subscriber1" process will subscribe to "EventMessage" while "Subscriber2" will subscribe to the interface "IEvent". Since the class "EventMessage" implements the interface "IEvent", when the "MyPublisher" process publishes an "EventMessage", both subscribers will receive it.
When running the sample, you'll see 3 console applications open, and each of them fill up with a great deal of log messages. Hardly any of these logs represent messages sent between the processes.
Run the sample
Press 'F5' and see the 3 console applications open.
Identify the "MyPublisher" process by its window's title as shown below:
You'll want to spread out the various console windows so that you can see all three fully.
Press 'Enter' repeatedly in the "MyPublisher" processes console window, and notice how the messages appear in the other console windows - one click appearing on only one other console, the next click causing messages to be sent to both subscriber consoles.
Let's see what else NServiceBus can do...
Pick one of the subscriber processes (say Subscriber1) and close it.
Now go back the "MyPublisher" process, and press 'Enter' several more times.
Now go to Visual Studio and right-click the project of the closed subscriber, and start it up again by selecting 'Debug' and then 'Start new instance' as shown below:
Notice how the subscriber processes all the messages that were sent by the "MyPublisher" process while it was down. This is how you can be sure that even when processes or machines restart, NServiceBus will ensure that your messages don't get lost.
Now let's examine some more failure scenarios.
Restart the "MyPublisher" process and bringing it up again as described above.
Press 'Enter' several times in the publisher's console window.
Notice that the subscribers aren't receiving these events anymore. You might not have expected this. It is reasonable to assume that a publisher "remember" its subscribers even if it restarts. That would require that a publisher store which events each subscriber wants to receive on some durable medium.
Luckily, NServiceBus comes with 2 durable subscription storage options in addition to the default in-memory storage - one makes use of MSMQ, the other makes use of a database.
The MSMQ option is suitable for integration environments where you want to test out various kinds of fault scenarios but don't require scalability. If you want to scale out a publisher over multiple machines the MSMQ subscription storage will not work correctly - for that, you need to use the DB subscription storage.
Switching from the in-memory storage to the others suitable for integration and production is done through the use of "profiles". These are preconfigured combinations of infrastructure technologies suitable for various scenarios. Let's change the publisher's profile to integration.
Go back to Visual Studio and stop debugging, double click the "Properties" node immediately under the "MyPublisher" process, and then click the "Debug" tab. In the "Start Options" section, in the "Command line arguments" textbox enter "NServiceBus.Integration" as shown below:
Now press "F5" again, press 'Enter' several times in the publisher's console, check that the events are showing up at the subscribers. Now restart the publisher.
This time when you press 'Enter' in the publisher's console, you should see the subscribers still receive those events.
Scale out your publishers and subscribers.
See the other NServiceBus pieces which handle this for you in how pub/sub works.
See the other samples.