Contents

• Getting Started
•     Overview
•     Video recordings about NServiceBus
•     Architectural Principles
•     Transactions

• Samples
•     Web App Integration
•     Web App - Asp.Net Mvc3 Integration
•     Encryption
•     Full Duplex - Request/Response
•     Generic Host - Logging
•     PubSub
•     Versioning
•     Message Mutators
•     Unobtrusive
•     Data Bus
•     Scale Out

• Day to Day
•     Dependency Injection
•     Support for child containers
•     Logging
•     Messages as Interfaces
•     Introducing IEvent and ICommand
•     Unobtrusive mode messages
•     Unit Testing
•     One way/Send only endpoints

• Hosting
•     In Your Process
•     NServiceBus Host
•     Profiles
•     More on Profiles
•     32-bit (x86) Host Process

• Management and Monitoring
•     Auditing
•     Monitoring
•     Msmq Information

• Scaling Out
•     Performance Information
•     Multi-Site with the Gateway
•     More about the Gateway
•     Multi-Server with the Distributor
•     Unit of work in NServiceBus 3.0
•     Unit Of Work implementation for RavenDB

• Publish-Subscribe
•     Overview
•     API and Configuration

• Long-Running Processes
•     Sagas

• Customization
•     Customizing Configuration
•     Pipeline Management Using Message Mutators

Support for running NServiceBus in Unobtrusive mode

When using NServiceBus you define your message contracts using plain C# classes or interfaces. So far so good. In order for NServiceBus to find those classes when scanning your assemblies you need to mark them with the special IMessage interface.
This essentially tells us that “hey this is a message definition, please use it”. This might seem like a small thing but now you’re coupling your message contracts to a NServiceBus assembly since you need to reference the NServiceBus.dll in order get access to the interface.

This dependency can cause problems if you have different services that run different versions of NServiceBus. I’m not going into the details since Jonathan Oliver has a great write up on this very subject.

This is not a big deal for commands because they are always used with in the boundary of a single service and it’s fair to require a service to use the same version of NServiceBus. But when it comes to events this becomes more of a problem since requiring all of your services to use the same version of NServiceBus and there by forcing them to upgrade NServiceBus all at once is not an ideal thing.

The solution

There are a couple of ways you can solve this. NServiceBus V3.0.0 has a few changes that will help you further.

1. Not bumping the assembly version for non-breaking changes. Following the semver.org semantics we only change our assembly version when we make changes that are not backwards compatible. This mean that 3.0.1 and 3.0.X will have this same assembly version, fileversion is of course changed for every release/build. This means that as long as you do a nuget update with the -safe flag your service contracts will stay compatible.
2. Support for running in what we call “Unobtrusive” mode. Running in unobtrusive mode removes the need for you to reference any NServiceBus assemblies from your own message assemblies. This obviously removes the problem altogether.

Unobtrusive mode

This new feature in NServiceBus V3.0.0 allows you to pass in your own conventions to determine which types are message definitions instead of using the IMessage interface.

Below is a snippet that shows how to define those conventions:

Configure.With()
   .DefiningCommandsAs(t => t.Namespace != null && t.Namespace.EndsWith("Commands"))
   .DefiningEventsAs(t => t.Namespace != null && t.Namespace.EndsWith("Events"))
   .DefiningMessagesAs(t => t.Namespace != null && t.Namespace.EndsWith("Messages"))
   .DefiningEncryptedPropertiesAs(p => p.Name.StartsWith("Encrypted"));

The code above tells NServiceBus to treat all interfaces/classes with a namespace that ends with “Messages” as messages. As you see you can also specify conventions for the new ICommand and IEvent feature as well.

NServiceBus supports property level encryption by using a special WireEncryptedString property and the last line in the snippet is the unobtrusive way to accomplish that encryption.

That is pretty much all there is to it.

A working sample can be found here.

This article was written by Andreas Öhlund and the original blog post can be found here.