NSB PowerShell Support in v3.3

Looks like this is the answer to my request for granular control over infrastructure installation. This works for me as PowerShell is our common denominator for our developers and admins. After getting through the new MSI installer, you will see a new short cut to a prompt.

I'm runing Windows 7 Enterprise and you will get an error OOTB

To get rid of this error you have to install PowerShell v3.  I won't show examples of all the commands available, but we do now have full control over what is installed.  Here is a listing of what is available:

Get-Message

Get-NServiceBusVersion

Install-Dtc

Install-License

Install-Msmq

Install-PerformanceCounters

Install-RavenDB

I think all of these are pretty self explanatory.  The great news is this takes care of allowing you to install only what you need instead of everything in the kitchen sink.

All I wanted was Perf Counters

We've been busy upgrading our endpoints and therefore there have been some reinstalls. NSB has some perf counters built-in to help you understand the relative health of your endpoint, (you can add your own). We still wanted those and therefore ran the Infrastructure installers. Then the fun started. Much to our admins chagrin, MSMQ got re-installed along with RavenDB(which we don't use). Everyone got all grumpy so I went off into the code(3.2.6) to check and make sure we had everything straight. Here is the summary I gave to our admins: Runmefirst.bat – this runs NServiceBus.Host.exe with the “/installInfrastructure” switch. This will install anything if it is not there or does not meet its requirements. NServiceBus.Host.exe – when installing the windows service, you can also use the “/installInfrastructure” switch. All OOTB profiles have “RunInfrastructureInstallers” = false. A custom profile can control this and be able to choose whether to run the install or not. When it comes to perf counters, it used to be the case that on startup if they didn’t exist, they would be created. In v3, the installation stuff has been moved and will pick up anything that implements a given interface. I don’t see a way currently to pick and choose what gets installed OOTB. So my advice would be to avoid running the infrastructure installers and we’ll just create a powershell script, or a custom profile, to isolate the perf counter install. Here is a sample of the script(non-validated) that I gave them:

$pc = New-Object NServiceBus.Unicast.Monitoring.PerformanceCounterInstaller $pc.Install([WindowsIdentity]::GetCurrent());

To follow up we opened a issue to get granular control over installation of infrastructure specifically.

Unobtrusive Mode - ASP.NET is Gonna Get-cha

We are using NSB as a send only endpoint in a REST style service hosted in ASP.NET. We are using unobtrusive mode and thought it would be easiest to identify our messages via using the assembly name itself. We unit tested fine, and our server side worked, but the client side just failed. We forgot about the whole dynamic compilation thing in ASP.NET. So we had some choices we could either go with fixed names or we could change our convention. We went with the latter. So be aware when you're dealing with ASP.NET.

Running 3.x Old School

I've run into a few interesting things that I thought I'd call out after running through an upgrade on my demo project.  Here at work we want to run 3.x as we were running 2.x, but this takes some work.  There are a couple of things you need to take care of.

NHibernate Persistence Requires Different Assemblies

In order to go back to NH persistence you need to pull in the NServiceBus.NHibernate package separately.  You will also need to create your own profile that default to these settings.

        public void ProfileActivated()
        {
            if (!Configure.Instance.Configurer.HasComponent<ISagaPersister>())
                Configure.Instance.NHibernateSagaPersister();

            if (!Configure.Instance.Configurer.HasComponent<IManageMessageFailures>())
                Configure.Instance.MessageForwardingInCaseOfFault();

            if (Configure.Instance.IsTimeoutManagerEnabled())
                Configure.Instance.UseNHibernateTimeoutPersister();

            if (Config is AsA_Publisher && !Configure.Instance.Configurer.HasComponent<ISubscriptionStorage>())
                Configure.Instance.DBSubcriptionStorage();
        }

SLRs and Timeouts Creates Extra Queues

These features require extra queues that you didn't have in 2.x, so these need to be disabled via custom initialization.

        public void Init()
        {
            Configure.With()
                .DefaultBuilder()
                .XmlSerializer()
                .DisableSecondLevelRetries()
                .DisableTimeoutManager();
        }

Timeout Persistence Moved to the Database

There is no more MSMQ timeout persistence, so if you want this back, you'll need to implement it yourself. This should be as simple as going back into the code and copying out the code.

NSB 3 Upgrade Continued

I finally got back around to my demo solution.  We run the Distributor as a stand-alone and would like to continue to so therefore I thought it would be good to validate that setup on 3.0.  The configuration and setup is much improved since you don't need any special dlls anymore.  The one thing you will run into is that when running in this mode, it is assumed that you will run the Distributor on another machine.  This is fine, but you'll need a license and if you don't have one, you'll need to get a temporary one.

NServiceBus 3.0 Upgrades

For those upgrading to the 3.0 RTM, please check out this video.  I've been upgrading my demo solution to check out the impact and so far all I've really had to do is name my endpoints and remove some config per the video.  Thus far I've gotten my version of Full Duplex working along with basic Pub/Sub.  Next I'll be hitting the Distributor since we use that pretty heavily.  I'll be sure to post back any gotchas that I find.

JSON Serializer in NSB 3.0

I was answering a question over on SO and I discovered that there is a JSON/BSON serializer built-in to 3.0. It seems like it would be possible with a a bit more digging that you could build upon my hack to expose NSB as a REST endpoint and skip the WCF serialization and jump right down into NSB(assuming WCF is configured to use the JSON format).