Profiles where introduced in NServiceBus 2.X so this is nothing that is new in 3.0. I've blogged about them a while ago but in short they are ways for you to alter the behavior of your endpoint without recompiling your code. This will help you tailor your endpoints for different environments but also controlling things like scaling out.  Profiles are only available if you use the NServiceBus host so this is not applicable if you self host NServiceBus inside a website, wcf service, smart client, excel:) whatever.

Profiles can be divided into 2 main categories depending on what they control. Those categories are Environment and Feature. Environment profiles can often use Feature profiles to turn things on and off depending on the environment. Technically there is no difference between the two types.

Environment related profiles

NServiceBus comes with 3 builtin profiles who's main goal is to adjust the behavioral of the host depending on the environment where the endpoint is running. You can of course create your own profiles, more on that later. The 3 environmental profiles are:

  • Lite - This is the default profile that is used if no explicit profile is defined. This profile is suitable for running on your development machine possible inside visual studio. This profile configures all the persistence like sagas, subscriptions, timeouts etc to be InMemory which is easy setup but probably not what you want for production. Lite also turns the TimeoutManager and Gateway on be default. Installers are always invoked when running the lite profile. Logging is done to the console.
  • Integration - The integration profile is suitable for running your endpoint in an integration/q&a environment. Storage is now persistent using queues or RavenDB, features like TimeoutManager and Gateway is now turned off be default. Installers are still being invoked to make deployment easier to automate. Logging is still being output to the console by default.
  • Production - This profile sets your endpoint up for production use. This means that all storage is durable and suitable for scale out. Installers are not invoked since your endpoint will probably be installed as a windows service and not running with elevated priviliges. Installers are only run when you install the host. Logging is done to a logfile in the runtime directory since again you're most likely running as a windows service.

Feature related profiles

The feature related profiles that comes out of the box are:

  • MultiSite - Turns the the gateway on
  • Time - Turns the timeout manger on
  • Master  - Makes the endpoint a "master node endpoint", can't be combined with the Worker or Distributor profile
  • Worker - Makes the current endpoint enlist as a worker with its distributor running on the master node. Can't be combined with the Master or Distributor profile.
  • Distributor - Not implemented yet but this will start the endpoint as a distributor only. This means that the endpoint won't do any actual work and only distribute the load among its workers. Can't be combined with the Master and Worker profiles.
  • PerformanceCounters - Turns the NServiceBus specific performance counters on
Profiles are just plain C# interfaces so you can mix and match the built in Feature profiles to your liking.

Telling the host which profiles to run

To activate a specific profile just pass the full name of the profile on the commandline when starting the host. Type names are case insensitive. Profiles can be combine by separating them with a white space. So if you want your endpoint to run in the Integration and Master profiles you would use:

.\NServiceBus.Host.exe nservicebus.integration nservicebus.master

When you install the host as a windows service the profiles used when installing will be persisted and used every time the host starts. So if you want to install your host with the Production and the MultiSite profiles you would use:

.\NServiceBus.Host.exe /install nservicebus.production nservicebus.multisite

 

Defining your own profiles

To define your own profiles you need to take the following steps:

  1. Create a profile by creating a class that inherits from IProfile
  2. Create 1 or many profile handlers for your new profile by implementing IHandleProfile<T>
  3. Activate the profile when starting the host by specifying the type name of your newly created profile on the commandline.
Note that you can create profile handlers for the builtin profiles as well if you want to do additional things when they are activated.
That's it, profiles are very powerful and can help you vary your endpoint behavior in and easy way!