My Live! 360 sessions

This morning I arrived back home from my trip to Orlando, FL together with Marcel. It was a fun trip, where I got the opportunity to do two things: completing my final “exam” for becoming an official Xamarin University Partner Trainer and delivering my sessions at AppDev Trends, part of the Live! 360 2017 conference. It was weird to hear “I’m Dreaming of a White Christmas” and other assorted X-mas songs all day while the sun was shining through the palm trees in the tropical Florida scenery.

On Tuesday, I spent an intense but fun day with Rob Gibbens from Xamarin, going through the Xamarin University curriculum, presenting the material to him and exchanging tips. This was the final part of becoming a certified XamU trainer. My colleague Geert and I are currently the only official Xamarin University Partner Trainers outside the US. We can deliver 3 to 5 day on-site trainings that count towards the official Certified Xamarin Developer exam. Ping me for more info, or check out our website.


The rest of the week I got to spend time at the Live! 360 conference at the Royal Pacific Resort in Orlando, FL. Live! 360 is a yearly conference that is a combination of several smaller conferences such as Visual Studio LIVE!, SQL Server LIVE!, TechMentor and AppDev Trends. I was invited to deliver two sessions in the AppDev Trends track, and the fun part is that attendees can pick and choose between the different tracks. My talks were centered around cross platform mobile development.

Here are the slide decks for my sessions:

Mobile DevOps Demystified with Xamarin, VSTS and HockeyApp

In this talk I introduced the concept of DevOps and the unique challenges that come with mobile. This talk was pretty demo-heavy, in which I showed how to set up a continuous delivery pipeline in VSTS Build & Release, in conjunction with Xamarin Test Cloud and HockeyApp. I also briefly introduced the brand new Visual Studio Mobile Center, which was announced last month at Microsoft Connect();

Overcoming the Challenges of Mobile Development in the Enterprise

Big enterprises can be a challenging environment for doing mobile development. There’s tension between existing architectures and processes and the innovation and speed that mobile requires. In this session I shared my experiences in mobile projects in bigger enterprise environments.

You can check out Marcel’s sessions on his blog.

Thanks to the AppDev Trends organisation and the speakers and staff of Live360 for another fun conference. And if you thought you could get away without another food post, think again… 🙂 We closed off in style with a great dinner at Emiril’s Tchoup Chop, where I enjoyed this mind blowing cocktail:

Holiday Cocktail: home infused bourbon with apple, cinnamon, nutmeg, cloves and other spices, mixed with home made raspberry syrup and topped off with rosemary

Xamarin Evolve 16 – Training day 1

Hi there from Orlando, FL! Yesterday was the first day of the Xamarin Evolve 16 pre-conference training. And man, we’re already having a blast here. Evolve 16 is even bigger than the previous one, and on the pre-conf training alone, there are more people than there were at the original, legendary Evolve 2013; in total! Impressive.

Finally it's happening! #XamarinEvolve

A post shared by Roy Cornelissen (@roycornelissen) on

My mobile peer at Xpirit, Geert and I arrived on Saturday, together with a bunch of fellow Dutchies including some of my former colleagues from Info Support. It’s nice to catch up and hang out.

In the training, we’re doing the Intermediate track, which offers some more advanced topics. I have to say that most of the topics are already familiar, but for us this is also a great opportunity to get to know the Xamarin University material. We’re working towards certifying ourselves for delivering the official Xamarin University training curriculum at Xpirit to be the first Dutch Xamarin Training Partner! How awesome is that? Stay tuned for more news!

The main topics we covered were:

Asynchronous programming with async/await
For this module we dove into the mechanics behind the Task Parallel Library in .NET and the async/await keywords. This stuff is so important to get right as it’s crucial for quality apps to make sure that you’re not wasting the main UI thread by doing expensive work like heavy CPU-bound work or (network) I/O. The course went into some of the mechanics of async/await – with the compiler generated state machine that ends up in the generated IL.

The problem with async/await is that the syntactic sugar makes it almost too easy to make work inside your app asynchronous. The point is that making things asynchronous isn’t always necessary and using async/await the wrong way may actually hurt the app in the sense of complexity and possibly performance more than it helps. Understanding the state machine that the compiler generates, the effects of ConfigureAwait(false), working with the Dispatcher, etcetera is crucial if you want your apps to be responsive.

Patterns for reuse
A topic that’s dear to my heart. Marcel and I actually did a pretty popular talk about it at Evolve 2013. IMO, this stuff all still holds true, however we have progressed a bit when it comes to the maturity of the Xamarin platform. With the advent of Xamarin.Forms, more and more code sharing techniques are possible and go right up to the top UI level. On the other hand, Xamarin.Forms already takes away a lot of the hard work of bridging platforms. Very nice, but – my pet peeve – beware of the abstractions! 🙂

It all comes down to keeping things as simple as possible. In the training, we talked through using the Factory and Service Locator patterns, but our common conclusion was that they involve a fair amount of Yak Shaving.


In the end, Dependency Injection is a relatively clean way of dealing with dependencies that have per platform implementations. In my experience, using a light weight DI container like SimpleIoC is sufficient for most apps. Let’s be honest, in an average app, you don’t really need much sophisticated lifetime management or other things. You just want to be able to swap in per platform implementations of some components to use them from shared code. But before you start building your own components, head over to Xamarin’s plugin repo on GitHub because a lot of plugins are already available. And they generally use DI to set up.

We talked about the techniques that are at our disposal for validating the quality of your app. Of course using unit tests should be a no-brainer to developers, and there are actually some nice scenarios for testing the behaviour of your ViewModels and other logic in your app. These unit tests, being independent and mostly having their dependencies stubbed (another advantage of using DI is that it makes stubbing a bit easier), can give you the quickest feedback during your development cycle.

But an important part of your app will be the UI and that actually runs on the device. This has always been hard to test and we had a look at what Xamarin Test Cloud has to offer and the UITest API’s that you use to drive those tests. In a recent talk, I used this test pyramid diagram to show the stack I like to use for testing mobile apps:


Note that I still think that there will always be a certain amount of manual testing involved for the more complex cases. And specifically those cases where you want to check the behaviour of your app under different circumstances, such as actually being on the move through tunnels or other low connection situations, or being out in the field to make actual pictures with the camera. Manual field tests by the team and beta test platforms like HockeyApp, Apple TestFlight and Google Play Beta are excellent tools for this.

Xamarin sure knows how to throw a party… #XamarinEvolve

A post shared by Roy Cornelissen (@roycornelissen) on

After the training it was time for some relaxation at LaFayette’s. Excellent food and great Southern style live music, and all the familiar faces from the Xamarin community there. Great to see everyone again! Really looking forward to the next few days!

To infinity, and beyond!
On Sunday, we had some spare time, so we spent the day at the NASA Kennedy Space Center. Wow what an amazing trip! It was incredible to see the huge rockets, it’s impossible to fathom how big they are until you see them. The same goes for the Space Shuttle. The Atlantis Space Shuttle is on display and you can see it up close. Super cool!

Awesome, the Atlantis Space Shuttle #nasa

A post shared by Roy Cornelissen (@roycornelissen) on

Rocket science

A post shared by Roy Cornelissen (@roycornelissen) on

The biggest surprise came when we went on the bus tour to the actual launch site. Again, it’s impossible to fathom the scale of the site and the equipment there that’s used for space travel. At the end we got a great show about the Apollo missions. The actual control center used for the Apollo mission is there on display. And then there’s the overwhelming and HUGE replica of the Apollo rocket.

Appollo Control Center #nasa

A post shared by Roy Cornelissen (@roycornelissen) on

And the coolest thing was: our Uber driver who took us back to the hotel was an engineer on the Space Shuttles for 30 years! So he could give us some fun behind-the-scenes insights. Did you know for example that there was an actual Coca Cola machine installed in one of the shuttles? That was to test the effects of carbonation in space. But since Coca Cola is a commercial company, NASA was not allowed to talk about that 😉

Oh and don’t you just love these vintage posters?

Love these vintage graphic posters #nasa

A post shared by Roy Cornelissen (@roycornelissen) on

NASA is recruiting #nasa

A post shared by Roy Cornelissen (@roycornelissen) on

GMImagePicker ported to Xamarin.iOS

I ported GMImagePicker to C#. Code here, Nuget here. Happy coding!

This past week I was working on a Xamarin project where we need support for selecting multiple images and/or taking pictures and uploading them to a backend service. The default UIImagePicker control in iOS is ok but not very versatile. It can take a picture with the camera, or lets you select a single image from your gallery but that’s about it. Furthermore, working with the resulting images is quite cumbersome as you’re working with large UIImage objects in memory. A lot of performance and memory issues can happen if you’re not careful.

In order to deal with photos and videos more efficiently and in a much richer manner, Apple introduced the PhotoKit API in iOS 8. Mike Bluestein has written a nice introductory post on this API on the Xamarin blog, so I’m not going to repeat this.

In short, PhotoKit works with the notion of PHAsset objects, which are basically descriptors for media files on the device. There are API’s to query different photo galleries, etcetera. Only once you actually need the image for display or other purposed do you have to retrieve the image using the PHAsset descriptor. Very efficient.

Many apps, such as the Facebook app, allow users to select multiple images in a user friendly manner, and maybe even add pictures on the go by providing access to the camera while they are browsing their gallery. This is something that we also wanted to add to our app. Luckily, there are some nice open source projects around that implement just that. One of the nicest ones is the GMImagePicker component by Guillermo Muntaner Perelló, which uses the PhotoKit API under the hood. The user experience looks like this:


That’s slick! You can browse through several collections, and the control is highly customizable, and even contains localized texts for labels, buttons and dialogs. Only, it’s written in Objective-C…

I had two options: bind the API using Xamarin’s Objective Sharpie or port it verbatim to C#. I chose to port it, mainly to have full control over the inner workings of the control and to not have to pull in a “foreign” language into the project. The port has complete feature parity with the Objective-C version and I tried to iron out as many issues as I could. It seems to be working pretty smoothly in my Xamarin app.

The code is up on GitHub and you can use the control by either downloading the code and including the .csproj in your project, or install the Nuget package in your Xamarin.iOS app:

Install-Package GMImagePicker.Xamarin

As I said, the GMImagePicker control is highly customizable. You can change its appearance by specifying colors for different parts of the UI, and you can provide custom titles and confirmation prompts. It’s also possible to filter and limit the types of assets you want the user to select. The whole range of options can be found in the sample app that comes with the control. Here is an overview:

var picker = new GMImagePickerController {
Title = "Custom Title",
CustomDoneButtonTitle = "Finished",
CustomCancelButtonTitle = "Nope",
CustomNavigationBarPrompt = "Take a new photo or select an existing one!",
ColsInPortrait = 3,
ColsInLandscape = 5,
MinimumInteritemSpacing = 2.0f,
DisplaySelectionInfoToolbar = true,
AllowsMultipleSelection = true,
ShowCameraButton = true,
AutoSelectCameraImages = true,
ModalPresentationStyle = UIModalPresentationStyle.Popover,
MediaTypes = new [] { PHAssetMediaType.Image },
// Other customizations to play with:
//ConfirmSingleSelection = true,
//ConfirmSingleSelectionPrompt = "Do you want to select the image you have chosen?",
//PickerBackgroundColor = UIColor.Black,
//PickerTextColor = UIColor.White,
//ToolbarBarTintColor = UIColor.DarkGray,
//ToolbarTextColor = UIColor.White,
//ToolbarTintColor = UIColor.Red,
//NavigationBarBackgroundColor = UIColor.Black,
//NavigationBarTextColor = UIColor.White,
//NavigationBarTintColor = UIColor.Red,
//PickerFontName = "Verdana",
//PickerBoldFontName = "Verdana-Bold",
//PickerFontNormalSize = 14.0f,
//PickerFontHeaderSize = 17.0f,
//PickerStatusBarStyle = UIStatusBarStyle.LightContent,
//UseCustomFontForNavigationBar = true,

// You can limit which galleries are available to browse through
picker.CustomSmartCollections = new [] {

// Event handling
picker.FinishedPickingAssets += Picker_FinishedPickingAssets;
picker.Canceled += Picker_Canceled;

// Other events to implement in order to influence selection behavior:
// Set EventArgs::Cancel flag to true in order to prevent the action from happening
picker.ShouldDeselectAsset += (s, e) => { /* allow deselection of (mandatory) assets */ };
picker.ShouldEnableAsset += (s, e) => { /* determine if a specific asset should be enabled */ };
picker.ShouldHighlightAsset += (s, e) => { /* determine if a specific asset should be highlighted */ };
picker.ShouldShowAsset += (s, e) => { /* determine if a specific asset should be displayed */ };
picker.ShouldSelectAsset += (s, e) => { /* determine if a specific asset can be selected */ };
picker.AssetSelected += (s, e) => { /* keep track of individual asset selection */ };
picker.AssetDeselected += (s, e) => { /* keep track of individual asset de-selection */ };

// The GMImagePicker can be treated as a PopOver as well:
var popPC = picker.PopoverPresentationController;
popPC.PermittedArrowDirections = UIPopoverArrowDirection.Any;
popPC.SourceView = gmImagePickerButton;
popPC.SourceRect = gmImagePickerButton.Bounds;

await PresentViewControllerAsync(picker, true);

The extensibility is very convenient. For example: if you want to set a maximum to the total size of the images you want to allow the user to select, you can handle the AssetSelected event, keep track of the total size selected, and handle ShouldSelectAsset, to prevent selection if a maximum threshold has been reached. This is exactly what we wanted to have in our app.

Once the user has finished selecting assets, you can use a PHImageManager to retrieve the actual images in whatever size you like:

void FinishedPickingAssets (object s, MultiAssetEventArgs e)
  PHImageManager imageManager = new PHImageManager();

  foreach (var asset in e.Assets) {
    imagePreview.Image = null;

    imageManager.RequestImageForAsset (asset, 
      new CGSize(asset.PixelWidth, asset.PixelHeight), 
      (image, info) => {
        // do something with the image (UIImage), e.g. upload to server
        // you can get the JPEG byte[] via image.AsJPEG()

Very nice, and it’s now available for Xamarin.iOS developers as well 🙂

Photo by Andrew Illarionov (

Many thanks to Guillermo for letting me port his excellent code and publish it. I’d love to hear your feedback on the code and would love to see your PR’s for improvements.

Microsoft’s mobile future is cross platform with Xamarin

Yesterday Microsoft and Xamarin announced that Xamarin will be acquired by Microsoft. Pending approval, the Xamarin team and products will become part of the Microsoft development ecosystem.

This is an interesting move and big news in the Xamarin community, but frankly not an unexpected one. People have been speculating for years about Microsoft buying Xamarin, especially since Miguel appeared prominently in the Microsoft //build keynotes these past few years. For both parties, it seems the best possible way forward.

It’s no secret that Microsoft has been struggling to keep up in the mobile space, with Windows Phone/Mobile. Dramatic reports about Windows Phone’s “demise” were all over the blogs and forums in the past few months. It still remains to be seen wether Windows 10 Mobile can make a dent in the universe. If Continuum takes off and gets some good apps in the Store, it might play a nice role for knowledge workers in the enterprise. Still, in these modern times, employees expect consumer grade experiences and that includes being able to bring the mobile device of their own choice to the workplace: Bring Your Own Device. And frankly, that market is taken by Android and iOS.

Microsoft acknowledged this when CEO Satya Nadella announced their new Cloud First, Mobile First strategy last year, immediately followed by the introduction of Office Mobile… for iOS!

Azure is the most important horse Microsoft is betting on and that platform is shaping up quite nicely. Just last Tuesday we did a deep dive on Azure Service Fabric with the Xpirit guys and wow, it’s a nice platform. For mobile apps, there have been some interesting gems in the platform for years as well.

In order to push Azure forward, Microsoft has to make it dead simple to make apps for all platforms and connect them to their cloud. What better way than with the Xamarin stack? Quality native apps with one the most productive programming languages in the industry! Not to mention the rich ecosystem of Nuget packages and .NET API’s out there to bootstrap your app development. If I can leverage Azure yet still target the most relevant mobile OS-es in the market, than that’s awesome. And that is what counts for both developers and companies targeting employees en consumers with their apps. And maybe, just maybe, this may even help push developers to leverage the tools and programming model to start targeting their apps for Windows Mobile as well, giving that platform another push.

It’s as if Microsoft is saying “OK, we’ll leave mobile to the pros, we have the cloud and tools pros” 🙂 And why not? This is a perfectly fine execution of the Cloud First, Mobile First strategy. Mobile can mean iOS and Android just as well, as long as the Cloud is still in Azure as far as Microsoft is concerned. They set the example themselves by delivering a top notch iOS version of the Office suite.


All of this is an interesting culmination of some of the things that have been happening in the Microsoft ecosystem. After Nadella took the helm, Microsoft has become more open and collaborative towards other technologies and platforms. We can develop and run ASP.NET on a Mac nowadays using the new .NET Core and Visual Studio Code. In that regards, Mono has always lead the way that Microsoft is now following, and thats a good thing. To think that those same Mono guys are now the ones to bring Microsoft to a true cross platform mobile world is just great.

What to expect?
So what’s next? Well, here’s my take…

Better Xamarin adoption
First of all I expect this to remove a lot of constraints that we sometimes encounter with enterprises that are looking to do mobile. Should we trust a relatively small vendor like Xamarin? This was a huge problem in the early days, and has gotten better as Xamarin built up their track record. The technology sells itself easily, but what about the risks? And then the pricing… sure you can make an easy calculation that shows how quickly you earn back the license costs due to the increased developer productivity, but frankly Xamarin Platform, Xamarin Insights and Xamarin Test Cloud were perceived as pretty expensive. I expect that the Xamarin tools will be incorporated into the MSDN suite and included in the price. For Xamarin, their license fee was their bread and butter. MSDN is a means for Microsoft to push their cloud offering, so the tables are turning in that regards. Good news for developers, especially the independent ones!

Test Cloud and Xamarin Insights will be incorporated in the Azure offering. Given the much bigger scale at which Microsoft can operate, prices can be much more affordable which make these tools almost a no-brainer. My one pet peeve with Xamarin Insights has always been that it focuses on the mobile app, and doesn’t cover end-to-end (server side) monitoring. But the dashboard is much more comprehensive and mobile optimized (obviously) than what Microsoft’s Application Insights has to offer. With HockeyApp on board, and now Xamarin Insights, the best of multiple worlds can be brought together.

Furthermore, I expect a lot from the Mono and .NET teams joining together. Microsoft is already dipping its toes in cross platform development, and Xamarin now brings a full blown development stack for .NET (well, Mono) for native iOS, native Android, native Mac AND Linux! Microsoft can leverage the Mono experience to push .NET ahead and over time, that same .NET framework will be what’s under the hood of the Xamarin tool chain.

Xamarin Studio, Xamarin’s IDE on the Mac is shaping up to be a pretty solid tool. It’s still my favourite IDE when building mobile apps. Visual Studio feels too bloated to me compared to Xamarin Studio and doesn’t give me the best performance when I’m developing inside my Windows image in Parallels. At the same time, Microsoft is working on their Visual Studio Code offering, the cross platform development IDE. It’s still pretty limited, but if they can leverage the Xamarin Studio foundation to make it a full blown Mac based IDE for mobile apps, I’m all for it!

Given their efforts on Visual Studio Code, I don’t think Microsoft will discontinue Xamarin development on the Mac and force users to Windows/Visual Studio.

I still love my Mac 🙂
Xamarin.Forms and UWP
At Xpirit we’ve been contemplating about what Microsoft’s strategy would have to be in order to stay relevant in Mobile, and push their Azure cloud. UWP is an interesting application model and Xamarin.Forms has a similar premise for delivering universal but native apps on all platforms. I think it would be natural if UWP and Xamarin.Forms are brought together to make a truly universal application model for native apps. In that sense, Xamarin.Forms can be seen as the groundwork for future editions of UWP. I do hope however, that it will still be possible to target the native SDK’s and API’s as is the case with the Xamarin Platforms. Sometimes you just want to make a Storyboard and hook up your outlets to a UIViewController 🙂

And frankly, as Xamarin.Forms itself has already proven, you just can’t get away with just the UI abstractions in order to deliver quality apps. Knowledge of the underlying platform is still relevant and flexibility to reach out into native code is still needed. Only making UWP available as a programming model will be just as bad as the Cordova/PhoneGap type offerings.

Microsoft Bridges for Android and iOS
Microsoft has two initiatives out there, announced at //build last year: Microsoft Bridge for iOS (WinObjC) and the Microsoft Bridge for Android. Both technologies enable developers to run native iOS/Android apps on Windows. I’ve blogged about this at the time, and I still think this is a bad idea for the user experience. I understand where Microsoft is coming from but I have good hope that they are now turning around and facing their development platform towards iOS and Android instead of trying to bring iOS and Android into their own OS in order to fill the app gap.

Wrapping up
With all these tools and technologies coming together, Microsoft’s offer for full stack application development an a holistic end-to-end continuous delivery cycle looks very promising for developers and businesses.

It’s exactly for this reason why the pillars we founded Xpirit on in 2014 are Cloud, Mobile and ALM. Cloud first, Mobile first and an all encompassing vision on Application Lifecycle Management around that. We have deep knowledge about architecting and building systems for Azure, and mobile apps using Xamarin. We’ve been working with Xamarin since even before they were Xamarin.

I’m looking forward to all the new challenges that will come our way.

One thing I do hope though, is that this won’t be the end of the Xamarin style conferences… Evolve is a real joy and I’m looking forward to this year’s edition. Let’s hope this is not the last one, or at least that Xamarin brings their fun and coolness to Microsoft.

My Miguel
This has been a long time coming…

Don Box tried to persuade Miguel de Icaza in 2003 to come to Microsoft in his rendition of the classic Beatles song “Michelle”, now dubbed “My Miguel”. Miguel played hard to get for 13 years but as Clemens Vasters tweeted yesterday:

Partly true I guess… I think the mission has only just begun…

An NServiceBus backplane for SignalR

[UPDATE December 6th 2015: With thanks to Ramon Smits of Particular, the sample repo has now been upgraded to the latest stable versions of both NServiceBus and SignalR. Thanks Ramon!]

On March 7th 2013 I did a presentation on Microsoft Techdays NL 2013 about SignalR. This is a great framework for real time messaging in websites and other .NET clients. It also works great on mobile devices. Check out my slides in my previous post here.

In this presentation, I used a Production Monitor application that runs NServiceBus in the back end to push events to our SignalR gateway. Schematically, this looks like this:

Production Monitor

This Production Monitor gathers info from our production application at De Vries Workforce Management, a SaaS workforce planning platform for large retail organizations. Besides technical data (are our databases up?), we also gather functional data (did all shops deliver turnover data in time, did all clock times come in?).

Of course there are all kinds of monitoring applications available in the market, so why build it ourselves? First of all, our application back end is comprised of NServiceBus services, publishing all kinds of events to form our business process. By running our monitoring application as an NServiceBus service, it can also listen to those events and do its checks accordingly. The second reason for me as an architect was that this case serves as a proof of concept and exploration on how NServiceBus combines with SignalR to provide real time communication to front ends. Something we’re contemplating on putting in our application as well in due time.

Scaling out SignalR with NServiceBus
The diagram above shows how NServiceBus publishes to a SignalR Gateway, who in turn sends the information to clients connected over the web. I’ll do a separate blogpost on that later. I did a presentation on this with my lead dev and partner in crime Mark Taling at the Dutch SDN Event on March 18th in Zeist. Here are our slides from that session:

Playing with SignalR and NServiceBus together made me think about other scenario’s as well. One of the aspects that has been very nicely solved in SignalR is its scale-out scenario. Consider the following setup:


In a web farm that uses three servers running a SignalR gateway, with a load balancer in front, messages from one client connected to Server A, won’t be delivered to other clients what were routed to a different web server automatically. Server B wouldn’t know about messages sent through Server A without some extra help. For this, SignalR uses a so called “backplane”. Now, the backplane in SignalR is pluggable. Microsoft offers three possible backplanes out of the box: Redis, SqlServer and ServiceBus (built on the Azure/Windows ServiceBus).

Just for fun, I decided to build such a backplane using NServiceBus. You can find it here on GitHub.

Building a backplane for SignalR is not so difficult. Basically, you’ll need three main parts: the ScaleoutMessageBus, a Receiver, and the Backplane server process.

The ScaleoutMessageBus
You’ll need a class that inherits from Microsoft.AspNet.SignalR.ScaleoutMessageBus, which serves as the SignalR plugin for accessing the backplane.

public class NServiceBusMessageBus : ScaleoutMessageBus
internal static IBus Bus;

public NServiceBusMessageBus(IDependencyResolver resolver, IBus busInstance, ScaleoutConfiguration configuration)
: base(resolver, configuration)
Bus = busInstance;
.ConfigureProperty((r) => r.SignalRMessageBus, this);

// By default, there is only 1 stream in this NServiceBus backplane, and we'll open it here

protected override Task Send(int streamIndex, IList<Message> messages)
return Task.Factory.StartNew(() =>
ScaleoutMessage msg = new ScaleoutMessage(messages);
Bus.Send<DistributeMessages>(m => { m.Payload = msg.ToBytes(); m.StreamIndex = streamIndex; });

new internal void OnReceived(int streamIndex, ulong id, ScaleoutMessage messages)
base.OnReceived(streamIndex, id, messages);

I decided to have the constructor receive an instance of IBus from the outside. This way, the hosting application can decide for itself how NServiceBus is initialized (what transport to use, what dependency injection framework, etc.). Also, this enables the bus that might already be present in the application to be reused. Furthermore, you can specify some extra configuration for the ScaleoutMessageBus, in the form of a ScaleoutConfiguration object. For the base class, this contains only a MaxQueueLength property, but you could subclass this for your custom ScaleoutMessageBus and add more properties specific to your configuration. I decided to let the hosting application decide on the configuration, and thus pass it into the constructor as well.

SignalR will call the Send() method on this class as soon as a message needs to be sent to a group of clients. My implementation simply uses an NServiceBus command to wrap the payload, and send it via NServiceBus to the backplane server. SignalR wraps messages inside a ScaleoutMessage, which has convenient helper methods for serializing them to Byte[], so I used that to put the data on the bus.

Furthermore, I made the OnReceived method available to other classes within the same assembly via a method override. The reason for this is that the Receiver should be able to invoke OnReceived on the ScaleoutMessageBus base class, which is protected. In previous versions, I had to make sure that ScaleoutMessageBus.OnReceived could never be called in parallel, i.e. there can never be two invocations of OnReceived at the same time, so these had to be queued up. In 1.1.2, this seems to be handled by SignalR itself, so I can safely pass the call to the base class implementation.

The Receiver
The Receiver is a separate class, which is a straightforward NServiceBus message handler:

public class Receiver: IHandleMessages<MessagesAvailable>
public NServiceBusMessageBus SignalRMessageBus { get; set; }

public void Handle(MessagesAvailable message)
var messages = ScaleoutMessage.FromBytes(message.Payload);

if (SignalRMessageBus != null)
SignalRMessageBus.OnReceived(message.StreamIndex, message.PayloadId, messages);

The SignalRMessageBus property is wired up by NServiceBus’s dependency injection framework. As soon as the handler is instantiated, a backpointer to the ScaleoutMessageBus is put into this property.

The handler is pretty straightforward: deserializing the Payload into a ScaleoutMessage object and passing it to the OnReceived handler. The null check is done because the handler might start receiving messages left in the queue before the SignalR initialized its ScaleoutMessageBus. Yes, this means that some messages get lost, so this could be a bit more robust. Possibly by deferring the message, or using second level retries.

The Backplane server process
The backplane itself is quite simple as well… We basically need an NServiceBus host running an endpoint with the SignalRMessageDispatcher handler. This handler receives DistributeMessages commands from any SignalR Gateway, and re-publishes the payload using Bus.Publish(). Note that this handler also makes sure that the PayloadId is unique. This is required by SignalR. I just copied this behavior from the SqlServer backplane, and it seems to work fine.

public class SignalRMessageDispatcher: IHandleMessages<DistributeMessages>
private static ulong _payloadId = 0;

public IBus Bus { get; set; }

public void Handle(DistributeMessages message)
var evt = new MessagesAvailable()
Payload = message.Payload,
StreamIndex = message.StreamIndex,
PayloadId = (ulong) Interlocked.Increment(ref _payloadId)


You’ll just need to create an NServiceBus Endpoint (e.g. just use the generic host) and run this message handler in it. I’ve added NServiceBus.SignalR.BackplaneService assembly with an EndpointConfig to serve as a host, but you can put the handler in your own host if you will, or just tweak the NServiceBus configuration in my sample to suit your needs.

Wiring up
Now that we’ve got a ScaleoutMessageBus implementation based on NServiceBus and a backplane process, we’ll need to wire these up. First, the convention for wiring up the ScaleoutMessageBus in SignalR is to use an extension method for IDependencyResolver (the interface SignalR uses for dependency injection). This is what the UseNServiceBus() method in the DepencencyResolverExtentions class does:

public static class DependencyResolverExtensions
/// <summary>
/// Use NServiceBus backplane for SignalR.
/// </summary>
/// <param name="resolver">The dependency resolver.</param>
/// <param name="busInstance">The instance of the NServiceBus IBus instance inside the current host.</param>
/// <param name="configuration">Scaleout configuration parameters to be used by SignalR.</param>
/// <returns>The dependency resolver.</returns>
public static IDependencyResolver UseNServiceBus(this IDependencyResolver resolver, IBus busInstance, ScaleoutConfiguration configuration)
var bus = new Lazy<NServiceBusMessageBus>(() => new NServiceBusMessageBus(resolver, busInstance, configuration));
resolver.Register(typeof(IMessageBus), () => bus.Value);
return resolver;

You’ll use this extension method when initializing SignalR. As of SignalR 2.0.0, this is done through a Startup class:

public class Startup
public IBus Bus;

public void Configuration(IAppBuilder app)
// Any connection or hub wire up and configuration should go here

Bus = Configure

var config = new ScaleoutConfiguration() { MaxQueueLength = 100 }; // Or whatever you want
GlobalHost.DependencyResolver.UseNServiceBus(Bus, config);

The NServiceBusMessageBus subscribes the Receiver message handler to the MessagesAvailable event. For this, it needs to know the endpoint address of the backplane endpoint. We simply put this in the (web).config of the SignalR Gateway host:

<section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
<section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" />
<!-- the endpoint on which the backplane is listening for commands -->
<!-- SignalR will subscribe to new messages via that endpoint -->
<add Messages="SignalR.NServiceBus" Endpoint="signalr.nservicebus.backplaneservice" />

<MessageForwardingInCaseOfFaultConfig ErrorQueue="error" />

To test this, just create a SignalR web application that uses the backplane. Next, copy the finished application to a second directory and map it as an extra application in IIS. Be sure to give it its own input queue. Start up the backplane process and fire up both website instances. You’ll see that messages sent to/from one website instance, are also delivered to the other.

This was a fun exercise to show how to extend SignalR with your own backplane to support a scale out scenario. The question is how scalable the backplane process itself is. The Azure ServiceBus backplane for example can scale out itself by adding more topics. These are sharded across multiple ServiceBus instances, something not supported in my version. It all depends on how massive your messaging needs are. I have not looked into a way of increasing the topic count (i.e. the StreamCount) in this NServiceBus version for avoiding contention. I’d be interested in ways to do so.

Nevertheless, this could be a nice starting point for using NServiceBus in your application for this purpose.

Microsoft TechDays 2013 session

Today I had the pleasure of delivering a session at Microsoft’s TechDays 2013 event in The Hague. A fun conference at which I’ve had the opportunity to speak for the last three years now.

Our session last year about Cross Platform Mobile Development still gets a lot of positive feedback. I did this together with Marcel de Vries and Willem Meints. Here’s the video feed on Channel 9: link. It’s in Dutch.

Unfortunately, an updated version of this talk wasn’t accepted for this year. I did however get a slot for a session about Real Time Mobile Apps and Websites with SignalR. SignalR is also a great topic to talk about, and I got to sneak in a couple of technologies I love: NServiceBus and Xamarin.iOS 🙂 The room was packed, which was great.

No recording this time around, but the slides are on SpeakerDeck. Here they are:

Thanks to those who attended my session!