LINQPad – My choice of test client for NServiceBus 3.0

Posted on February 1, 2012

8


The NServiceBus 3.0 RTM has just come out and I have spent a little bit of time over the last couple of weeks re-familiarizing myself with this fantastic product after recently changing jobs to a place where asynchronous messaging is not (yet) king. I suspect most people that have worked or evaluated NServiceBus will at some point have created an AsA_Client test service to use to send commands to your distributed application layer and watch the events propagate throughout the system. Since I discovered LINQPad a couple of years ago I don’t think I have created any console applications for testing code snippets or perform utility functions. All that I can normally handle completely in LINQPad and NServiceBus testing is no exception. Running LINQPad as an NSB send only client has become incredibly easy with the new SendOnly fluent configuration option. This initiates a bus with, surpirse, surprise, send only capabilities.
I LINQPad just hit F4 and add the NServiceBus and NServiceBus.Core assemblies as well as any assemblis containing the Commands you want to send. Normally you would need log4net but as long as you dont specifiy the Log4Net() option you don’t need it.

Here is the configuration I use:

var bus = Configure.With(typeof(MyCommandAssembly).Assembly)
.DefineEndpointName(“linqpad”)
.DefaultBuilder()
.DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith(“Commands”))
.DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith(“Events”)) // as this is a send only endpoint this doesn’t do anything – it is just here as an example
.XmlSerializer()
.MsmqTransport()
.UnicastBus()
.SendOnly();

I have created a little visual studio snippet that LINQPad can use for the above setup code (just drop it into the LINQPad snippets folder). Download it from my public Dropbox folder here
It is hooked up to the ‘nsb’ keyboard shortcut but you can change this as you see fit naturally.

Apart from the new SendOnly() option there are a couple of other new configuration options that I find really useful.

In 2.x all messages had to implement the IMessage interface. One of the first things to bear in mind when designing a message based system is to make sure you make the intent of your messages clear. Many of us defined additional interfaces to distinguish between Commands (RPC – type messages) and Events (PubSub). This has now been included in NServiceBus 3.0 with the new IEvent and ICommand interaces. In short, IEvents can only be published and ICommands can only be sent. Simple and clear. But it doesn’t stop as that. The constraint that defines what is considered an event or a command (or a ‘message’ but I am ignoring this for now) can be configured using the DefiningCommandsAs() and DefinintEventsAs() methods. This allows you to configure NSB into an ‘Unobtrusive mode’. This is likely to be a nod to the CQRS crowd as it allows you to publish events emitted by your domain straight onto the bus without coupling your domain code to the NServiceBus assemblies. I like this a lot. More details on this can be found here.

Watching messages can be highty addictive. And the ease you can achieve fairly complicated but reliable messaging scenarios with NSB is for me it’s strongest asset. Udi and the other NServiceBus guys have designed a system to make it hard to get it wrong and this concept is hardened with the 3.0 release.

Until next time…

Tagged: ,
Posted in: NServiceBus