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).

NServiceBus Modeling Tools Review

After downloading and installing the package, the first thing that we have to do is create a new NSB application. So where is it? I expected it to be in a custom NServiceBus folder under Visual C#, but it wasn't. Then I tried Windows thinking that since we deploy as a Windows Service, it would be there. Nope. Modeling Projects? Nope. So then I did a search and found it at the Visual C# root. I eventually found it, but I'm hoping this moves somewhere more obvious. I'm also curious about the term "application". In the Advanced Distributed System Design course we talked at length on how an application is something that does not require network access, something like Microsoft Word. I'm thinking this should be changed to "System" instead.

It takes you right into the designer canvas which is nice. In the toolbox we have a pretty small set of items, a couple of message types, matching connectors, and two endpoints. I'm going to try to set up a simple send-only client that in turn publishes to a couple of subscribers.

Somehow my references are busted, so I opened the project to see the path and it's referencing some MSBuild variable, so I just updated all the refs. I'm not sure what the bug is here, but I'll blow right by it.

Now that we've generated the system, let's go and see what it did. So far the Client looks just fine:

All the message classes look fine and I'm glad to see that the commands are separated from the events into different assemblies. I'm also glad to see that the Publisher is defined correctly:

I didn't think it would do that based on the canvas. I would like to see a larger group of endpoints that are defined based on there role. This would include Publisher, Subscriber, Distributor, Worker, and Server. This would make it very obvious to the beginner what they are building. The Subscribers are also defined correctly:

It would also be nice if the endpoint configuration matched what was on the canvas, in this case that would be "AsA_Subscriber". Most people that I've helped to learn NSB get a little caught up on what the endpoints can do. If we added "AsA_Subscriber" we could also do some validation on the subscription itself(depending on the profile). All in all, this is a huge step forward. Congratulations to the team for significantly lowering the barrier to entry to getting started. I'd like to see some of the refinements I mentioned above and also would like some Distributor support(I'm sure that is on the list).