Question

I’m building a web site that sends commands to other endpoints in order to
effect changes in the domain. In the event that a command fails for a business
reason, I’d like to be able to use Bus.Reply() and send a command failure message
to an endpoint at the ReturnAddress specified in the TransportMessage.

In attempting to accomplish this, I’ve set up the MsmqTransportConfig in my
web.config to have the appropriate InputQueue value; the Bus.Reply() call then works
correctly. However, when the reply is received in the specified queue, the web
site proceeds to consume it, which is not what I want to happen; I have another endpoint listening to the same queue to consume these events.

Is there a way to have NServiceBus use the ReturnAddress header on the sent
message, or a way to instruct a process not to pay attention to the
iput queue specified in MsmqTransportConfig, or a way to set the ReturnAddress value programatically on the TransportMessage?

Answer 1

It turns out it is possible to do this. Here is the configuration block I ended up using:

var config = Configure.WithWeb().StructureMapBuilder(ObjectFactory.GetInstance<IContainer>()).XmlSerializer();
config.UnicastBus().MsmqTransport();
config.Configurer
    .ConfigureComponent<MsmqTransport>(ComponentCallModelEnum.Singleton)
    .ConfigureProperty(t => t.InputQueue, "MyReturnQueue");
config.CreateBus().Start();

I haven’t looked through the code yet to figure out exactly what is happening, but it appears that if there is not an MsmqTransportConfig entry in the web.config file, the transport will not listen on its input queue. So by setting the InputQueue property programatically before the bus is created, the ReturnAddress of the TransportMessage gets populated, but the bus does not consume messages at that address.