Replacing AzureNetQ Components

AzureNetQ is a library composed of small components. When you write:

var bus = AzureBusFactory.CreateBus("Endpoint=sb://servicebus/ServiceBusDefaultNamespace;StsEndpoint=https://servicebus:10355/ServiceBusDefaultNamespace;RuntimePort=10354;ManagementPort=10355");

... the static method CreateBus assembles these components according to some default settings defined in the AzureNetQSettings class:

https://github.com/Roysvork/AzureNetQ/blob/master/AzureNetQ/AzureNetQSettings.cs

An overload of the CreateBus method allows you to pass in your own instance of the settings class which allows you to provide your own versions of any of the AzureNetQ dependencies, as well as setting various defaults and configuration options. The signature looks like this:

public static IBus CreateBus(string connectionString, AzureNetQSettings settings)

The AzureNetQSettings class provides a series of Func<>s which you can specify in order to change how components are resolved. This decoupled approach allows you to use any wireup/DI strategy that you like:

public Lazy<IAzureAdvancedBus> AzureAdvancedBus { get; set; }
public Func<IAzureNetQLogger> Logger { get; set; }
public Func<IConventions> Conventions { get; set; }
public Func<IRpc> Rpc { get; set; }
public Func<ISendReceive> SendAndReceive { get; set; }
public Func<ISerializer> Serializer { get; set; }

So to register your own logger, based on IAzureNetQLogger, you'd write this code:

var logger = new MyLogger();
var bus = RabbitHutch.CreateBus(
    connectionString, 
    new AzureNetQSettings() { Logger = () => logger) });

All these Func properties are invoked when CreateBus pulls together the components to make an IBus instance, so while any services you override will be respected, it'll still fall back to the defaults implementations for those that you don't.

To use an IoC container with AzureNetQ componets, see Using a DI Container