Problem
I recently ran in to a problem with a simple Windows forms application that I was using to test an NServiceBus endpoint. The forms application simply allowed me to add messages to the endpoint input queue without having to invoke a number of other components in the system; useful for development and testing.
The forms application had been written using NServiceBus 2.6 but had been upgraded to NServiceBus 3.3.2. However, when I ran the upgraded version of the forms application it was using over 40% of available CPU. This didn’t happen when using NServiceBus 2.6.
Solution
The issue turned out to be permissions when the forms application tried to access its input queue. The solution was to delete the existing queues and to configure the application to run the NServiceBus installers on start-up.
In this case the NServiceBus was self-hosted within the forms application so I invoked the installers when I created the bus, something like this:
var bus = NServiceBus.Configure.With()
.Log4Net()
.DefaultBuilder()
.XmlSerializer()
.MsmqTransport()
.UnicastBus()
.LoadMessageHandlers()
.DisableTimeoutManager()
.CreateBus()
.Start(() => Configure.Instance.ForInstallationOn<NServiceBus.Installation.Environments.Windows>().Install());
Note that if your process doesn’t actually need an input queue because it only sends messages you can avoid the necessity of creating the input queue altogether by using send-only mode:
var bus = NServiceBus.Configure.With()
.Log4Net()
.DefaultBuilder()
.XmlSerializer()
.MsmqTransport()
.UnicastBus()
.DisableTimeoutManager()
.SendOnly();