You can start your first NServiceBus installation from Visual Studio. There are some preconditions that must be satisfied before NServiceBus is installed on the machine:

Before setting up NServiceBus itself, vanilla NServiceBus makes a lot of use of MSMQ, DTC, RavenDB, and even performance counters to monitor NServiceBus's performance.

We will need to install the PowerShell commandlets through Package Manager.

Many items can be managed in the Package Manager console program of Visual Studio, 2012. We will need a solution, and we can start by using the MSMQ solution from GitHub. It is available at https://github.com/Particular/NServiceBus.Msmq.Samples/tree/master/VideoStore.Msmq. We will need to install the various NserviceBus references by using NuGet, as in the following screenshot:

We need to make sure that the PowerShell commandlets are installed correctly first. We do this by using Package Manager:

The "import module" step is dependent on where NService.PowerShell.dll was installed during the "install package" process. The "Install-package" command will add the .dll module into a package directory related to the solution. We can find out more on PowerShell commandlets at http://docs.particular.net/nservicebus/managing-nservicebus-using-powershell and even by reviewing the help section in Package Manager. Here, we see that we can insert configurations into the App.config file when we look at the help section, PM> get-help about_NServiceBus.

NServiceBus provides instructions for preparing your machine on http://docs.particular.net/nservicebus/preparing-your-machine-to-run-nservicebus. First, run the Install commands for the pieces that are accomplished in PowerShell commandlets.

We can then run various Test commands to see whether the installations succeeded.

This verifies that everything is set up correctly. I like using C# and NServiceBus because I can then use other products to verify the correctness. We can verify many pieces using services that come with Windows Server. These instructions will be specific to Windows-operating systems, and we will use the Windows 2008 server for these instructions. For instance, to verify that DTC is set up, we can check to see how it's set up:

This way, there is verification from Windows Server's tools that DTC is configured. However, this does not mean that the firewall ports are open to ensure that DTC is in operation. For example, a firewall may block the interaction of the DTC protocol between machines.

Due to firewalls not being allowed to open up all the ports between machines, it is often a best practice to minimize the ports to run the transactions between ports 5000 and 6000. This can be done by setting the Ports Ranges value under Component Service | My Computer | Default Protocols | Properties to 5000-6000.

DTC can be used to verify that the system is working before running a program. Both machines have to be set up to run DTC, and there are many articles related to troubleshooting DTC, such as http://blogs.msdn.com/b/distributedservices/archive/2008/11/12/troubleshooting-msdtc-issues-with-the-dtcping-tool.aspx and http://docs.particular.net/nservicebus/transactions-message-processing. Note that DTC is very dependent on the protocols that run between machines and can cause many errors when not configured properly.

Even if we know that MSMQ is set up correctly (because we have tested it), we may need to know which queues it is currently using.

Using the PowerShell PM> Get-NServiceBusLocalMachineSettings command, we can see which queues it currently wishes to reference. Also, by viewing Visual Studio Server Explorer, we can verify that they are present.

One of the many features I really like about NServiceBus is its ability to create message queues, services, and DTC pieces. This is less work than what the server staff does to maintain and install an application.

Here is a look at the queues now in Visual Studio Server Explorer:

We can see the RavenDB service is running without even leaving Visual Studio by looking into the services section of the same Visual Studio Server Explorer in which it was installed.

RavenDB is a document-oriented database that can operate completely independent of NServiceBus. This means that you are now working on NoSQL development, and it has an interface to save the collections of objects.

RavenDB must be running as NServiceBus uses it to store internal information such as subscription endpoint information and message types. The following screenshot is of Server Explorer in Visual Studio and shows that RavenDB is running:

In addition, we can see that RavenDB is installed by its web interface. When running one of the NServiceBus video store examples, we can see that it creates associated tables in RavenDB for internal use. We can view it through the default port 8080 and access it using http://localhost:8080/raven/studio.html.

At this point, we have the basics to set up pieces that NServiceBus utilizes. We have a data store for sagas and another persistence, RavenDB. Also, we have queues in MSMQ that uses DTC to handle transactions. These are not the only options, but they are the default options for NServiceBus.

RavenDB, a NoSQL database, comes standard with NServiceBus as a persister for sagas and other NServiceBus controls. It is worth mentioning that the licensing of RavenDB is part of NServiceBus.

If you are to use RavenDB outside of NServiceBus, then you must license RavenDB for your own use: http://ravendb.net/nservicebus-and-ravendb.

An alternate solution to RavenDB is to use other databases, such as SQL Server, through an open source ORM connector (called NHibernate). This does not negate the need to have RavenDB running, but it can offload many of the tables from RavenDB to other databases.