Welcome to the first ever NServiceBus Weekly. As the name suggests, these posts will concentrate on the latest happenings around the NServiceBus. New post is released once a week, every Wednesday.

There’s going to be few different sections:

Every section will concentrate on NServiceBus. Also, any feedback is greatly appreciated. Please let me know if I missed an interesting link.

Because this is the first NServiceBus Weekly, we have an extra section: NServiceBus. This section will contain links to articles and web pages which will give you a good introduction on this popular open source service bus for .NET Framework, founded by Udi Dahan.. Also this week’s NServiceBus Weekly will contain links which are older than one week. Starting from the next post, I will concentrate on the latest happenings.


  • NServiceBus homepage – This is the home of NServiceBus. It contains documentation, download links and license information. Start from here.
  • NServiceBus official documentation – Unlike some other open source projects, NServiceBus actually has a pretty good documentation. The FAQ on there front page will get you started quickly.
  • NServiceBus source code – Even though GitHub isn’t the official place for NServiceBus source code, it’s the easies way to get the latest codes.
  • NServceBus samples – NServiceBus source code contains a large number of sample applications. Pub/sub, logging, ASP.NET communication, WCF integration and so on, they all are covered in the sample applications.
  • NServiceBus discussion board  – NServiceBus Yahoo! group is the main source of NServiceBus related discussions. You can use Yahoo’s own web page or Grouply to follow the discussion.
  • Enterprise service bus – NServiceBus is an enterprise service bus. This Wikipedia article will give you a good introduction on the topic.


  • "Still OSS, but higher value offerings not free in binary form." – NServiceBus has taken the next step: It now offers a commercial option. The NServiceBus source code will continue to be open and anybody can still fork the code. The commercial version will offer more features like distributor, gateway and saga timeout management.  This change was made “In order to save #NServiceBus from the same fate as other OSS projects (victims of their success)”. The current 2.0 version will remain completely free. The next service pack of 2.0 version will be called 2.5.
  • NServiceBus License Packages – If you’re interested in the features provided by the commercial licenses, this page will give you all the details.
  • NServiceBus Developer Studio – Not much is known about the up-coming NServiceBus Developer Studio. Currently it seems that it will be a commercial application and it will allow the developers to visualize what is happening inside the NServiceBus. More news to follow, I’m sure.

Tutorials and Articles


Here’s also an list of blogs which have been active lately and have posts related to NServiceBus. Please let me know if I missed something.

Got an interesting NServiceBus related link? Did I miss something? Link not working? Please, send mail or contact @MikaelKoskinen.


NServiceBus is like all the other messaging systems: It doesn’t promise to process the messages in-order. This attribute must be kept in mind when designing your application around a message bus. Let’s examine a situation where we have an ASP.NET MVC application with a user registration form. When the user fills the form, the controller can send one or many messages into the bus, depending on what information user has entered. For simplicity’s sake our example will have two different messages: CreateUserCommand and ChangeUserEmailAddressCommand.

Problem description

If our client sends a CreateUserCommand-message followed by a ChangeUserEmailAddressCommand-message and our message bus doesn’t promise to process them in order, how can we be sure that the ChangeUserEmailAddressCommand isn’t processed first? How can we update the user’s email address if the user isn’t in our database yet?

This tutorial uses NServiceBus 2 RTM and ASP.NET MVC 2. There’s a link to the source code at the bottom of this post.

Message handlers

Throughout this tutorial we are using the following message handlers at our server side:

   1: public class ChangeUserEmailAddressCommandHandler : IHandleMessages<ChangeUserEmailAddressCommand>
   2: {
   3:     public void Handle(ChangeUserEmailAddressCommand message)
   4:     {
   5:         Thread.Sleep(100);
   6:         Console.WriteLine("###########{0}", message.UserId);
   7:     }
   8: }


   1: public class CreateUserCommandHandler : IHandleMessages<CreateUserCommand>
   2: {
   3:     public void Handle(CreateUserCommand message)
   4:     {
   5:         Thread.Sleep(300);
   6:         Console.WriteLine("***********{0}", message.UserId);
   7:     }
   8: }

Creating a new user is a more robust operation so it takes a little longer than changing the user’s email address.

Client’s controller

To simulate the stress for our server, our client will send it 100 messages in total, divided in half between the CreateUserCommand- and ChangeUserEmailAddressCommand-messages. The initial code in ASP.NET MVC controller looks like the following:

   1: public ActionResult SendMessages()
   2: {
   3:     for (int i = 0; i < 50; i++)
   4:     {
   5:         var createUserMessage = new CreateUserCommand() { UserId = i };
   6:         MvcApplication.Bus.Send(createUserMessage);
   8:         var changeEmailMessage = new ChangeUserEmailAddressCommand() {UserId = i};
   9:         MvcApplication.Bus.Send(changeEmailMessage);
  10:     }
  12:     return View("Index");
  13: }

Pretty simple. We first send a CreateUserCommand-message and then a ChangeUserEmailAddressCommand-message. Both messages have the same user id.

Server’s configuration

This is how our server’s configuration looks like:


InputQueue=<span style="color: #006080">"InputQueue"</span>

ErrorQueue=<span style="color: #006080">"error"</span>

NumberOfWorkerThreads=<span style="color: #006080">"1"</span>

MaxRetries=<span style="color: #006080">"5"</span>


First test

Given the previously described controller, message handlers and the server configuration will give us the following result (copied from server’s console):


Keeping in mind that the lines with ****** represent a CreateUserCommandHandler and the lines with ###### are caused by a ChangeUserEmailAddressCommandHandler, we can see that the messages have been processed in order. Did we get lucky? No. Remember our server’s configuration? In our first test the server is using only one thread (NumberOfWorkerThreads) to process all the messages. Because of this, the NServiceBus handles them in order.

Second test

Our server has a nice quad core processor so we’re wasting it's computing power by limiting it to only one thread. So, for our second test, let’s modify the NumberOfWorkerThreads to 4. Here are the new results:


We have a problem. Our server is trying to change the email address of the user 48 before it has been created in our system. The likely outcome? Exceptions. Because the NServiceBus has now more worker threads, each thread will process a new message from the queue as soon as it has handled the last one. Is there an easy way to make sure that the required messages are processed in-order? Yes, if we can change the client’s code.

Sending messages in-order

Our client’s controller sends the messages one after another, for a total count of 100 calls to Bus.Send. But the Send-method also has an overload which takes an array of IMessages as a parameter.  By putting the two relevant messages in an array, in the correct order, we can be sure that the NServiceBus will process them in order. The messages sent in an array will be processed by one thread by the server.

Third test

Here’s our new client code:

   1: public ActionResult SendMessagesInOrder()
   2: {
   3:     for (int i = 0; i < 50; i++)
   4:     {
   5:         var createUserMessage = new CreateUserCommand() { UserId = i };
   6:         var changeEmailMessage = new ChangeUserEmailAddressCommand() { UserId = i };
   8:         MvcApplication.Bus.Send(new IMessage[] {createUserMessage, changeEmailMessage});
   9:     }
  11:     return View("Index");
  12: }

This time the two messages are packed in an array (a batch) and the Bus.Send is called only 50 times. The results are interesting:


NServiceBus makes sure that the ChangeUserEmailAddressCommand-message is always handled after the CreateUserCommand-message. Fixing our problem was rather easy because we we’re able to change our client’s code. But what can we do if we can’t alter the client?

Other option

One of the easiest solution is to change our ChangeUserEmailAddressCommand to call Bus.HandleCurrentMessageLater-method if the user isn’t in our system yet. This will send the original message back to the input queue. Because it ends up as the last message in the queue, it’s highly probable that the system has been able to process the relevant CreateUserCommand-message before the message is processed the second time. But make sure to create a failure system so that the same message doesn’t end up in an endless loop. At some point it has to be moved into an error queue.


NServiceBus doesn’t handle messages in-order. It’s up to the developer to make sure that the relevant messages are handler in the right order. The easiest way to do this is to send messages as batches from the client.


You can get a sample application from the GitHub.


It took me long enough to realize what was wrong in my Web.config so here’s a little friendly reminder: MessageEndpointMappings are case sensitive.

My Web.config had the following section:



    &lt;add Messages=<span style="color: #006080">&quot;Messages&quot;</span> Endpoint=<span style="color: #006080">&quot;InputQueue&quot;</span>/&gt;



And I had the following project:


And Bus.Send gave the following error:

No destination specified for message messages.CreateUserCommand. Message cannot be sent. Check the UnicastBusConfig section in your config file and ensure that a MessageEndpointMapping exists for the message type.

After staring at the configuration for 15 minutes and rebuilding the solution 30 times without a success, I noticed the capital M. Changing it to lowercase cured my problem.

Just a small note. If the Messages is changed to point to an assembly which doesn’t exist (like noMessages), NServiceBus will throw the following exception when configuring the bus:

Exception: System.ArgumentException: Problem loading message assembly: noMessages ---> System.IO.FileNotFoundException: Could not load file or assembly 'noMessages' or one of its dependencies. The system cannot find the file specified.

Maybe the case sensitivity can be classified as a bug?


If you’re using Windows 7 and have downloaded a NServiceBus sample application from somewhere, it’s likely that you will encounter problems running it. For example you may get the following exception when starting NServiceBus.Host.exe:

Creating the configuration section handler for MsmqTransportConfig: request failed. SecurityException…


System.IO.FileLoadException: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

This is because by default the Windows 7 restricts the permission for files which are downloaded from the net. Fixing this is fortunately really simple. Just right click every NServiceBus-dll (or .exe) which you have downloaded and click the “Unblock”-button:



By default the NServiceBus generic host uses Spring for its IoC-needs. Changing this is as easy at it gets.

Note: If you’re hosting NServiceBus without the generic host, please follow this tutorial instead.

1. Select your desired IoC-container

NServiceBus comes with a built-in support for the following IoC-containers:

  • Spring
  • Autofac
  • Castle Windsor
  • Structuremap
  • Unity

You can pick your favorite. This tutorial will use the Structuremap.

2. Include the IoC-container in your project

Supported IoC-containers can be located from the NServiceBus/binaries/containers –folder. In Visual Studio, open up an NServiceBus application for which you want to change the IoC-container. Add a reference to the following files:

  • NServiceBus.ObjectBuilder.StructureMap.dll
  • StructureMap.dll

Note: Change the dlls if you selected an another IoC-container.

3. Modify the initialization

Now open the generic host initialization method. By default, it may look like something like this:

<span style="color: #606060" id="lnum1">   1:</span> <span style="color: #0000ff">public</span> <span style="color: #0000ff">class</span> ServerInit : IWantCustomInitialization, IWantCustomLogging

<span style="color: #606060" id="lnum2">   2:</span> {

<span style="color: #606060" id="lnum3">   3:</span>     <span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> Init()

<span style="color: #606060" id="lnum4">   4:</span>     {

<span style="color: #606060" id="lnum5">   5:</span>         NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);

<span style="color: #606060" id="lnum6">   6:</span>     }

Modify this method by adding a call to NServiceBus.Configure.With().StructureMapBuilder() –method. This changes the IoC-container.

<span style="color: #606060" id="lnum1">   1:</span> <span style="color: #0000ff">public</span> <span style="color: #0000ff">void</span> Init()

<span style="color: #606060" id="lnum2">   2:</span> {

<span style="color: #606060" id="lnum3">   3:</span>     NServiceBus.Configure.With().StructureMapBuilder();

<span style="color: #606060" id="lnum4">   4:</span>     NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);

<span style="color: #606060" id="lnum5">   5:</span> }

Simple, wasn’t it? The new method comes from the NServiceBus.ObjectBuilder.StructureMap.dll. If your application has already initialized an StructureMap container, you can pass it to the NServiceBus as a method parameter.