Samples

The samples are designed to be highlighting how various features of NServiceBus work and how the extension points plug into other libraries and tooling.

Not Production Ready

Samples are not meant to be production ready code or to be used as-is with Particular Platform tools. They are meant to illustrate the use of an API or feature in the simplest way possible. For this reason, these samples make certain assumptions on transport, hosting, etc. See the Technology choices for more details.

Not "Endpoint drop in" projects

Since the endpoint in samples have to chose specific technologies (transport, serializer, persistence etc) before using this code in production ensure the code conforms with any specific technology choices.

Downloadable and runnable

All samples have a download link that allows the sample solution to be downloaded as a zip. Once opened in Visual Studio the samples are then runnable. Note some samples may have certain infrastructure requirement, for example a database existing in a local SQL Server.

Versions 5 and below

On startup each sample will create the required queues. By default the samples use the prefix samples. for all queue names. There is no process to clean up these queues, as such after running samples those queues remain in MSMQ. To clean up these queues manually use a MSMQ management tool or programmatically using the native MSMQ API.

For example this PowerShell will delete all queues prefixed with private$\samples..

Console Hosting

Samples default to Self Hosting in a console since it is the most explicit and contains fewer moving pieces. This would not be a real choice for a production system and the other Hosting Options should be considered.

In many samples Messages are defined in a shared project along with reusable helper and configuration classes. This is done so reduce the number of projects in a solution. In a real solution message definitions are most likely isolated in their own projects.

Many samples make use of SendLocal and sending to an endpoint directly by specify the destination using a string in code. This is done to simplify the amount of configuration in samples. In a real solution most message destination should be defined via routing configuration.

Samples default to using the built-in dependency injection since it does not require pulling in any external NuGet packages. Switching to external dependency injection will give greater flexibility in customizations.