Part 1: Getting SignalR running on Asp.Net MVC Core

Microsoft has a very powerful implementation of WebSockets available named SignalR. Personally, I like the fact it automatically scales down if needed to other communication solutions if WebSockets is not working (like long polling).

I used it in the past several times for dashboards but in my current project, I had a new challenge. We are using Asp.Net MVC Core. This is ‘the latest’ flavor of Asp.Net and our websites can now run on both Windows and Linux.

But Asp.Net MVC Core has broken with the past, which is a good thing but it also needs a different way to activate SignalR.

Microsoft has provided documentation but it was written towards the standard, non-MVC applications.

It took me a while to get SignalR running.

But first, let me introduce you to the steps to be taken to get SignalR running on Asp.Net MVC Core.

Advertentie

SignalR is easy in Azure Mobile Services

SignalR is a great way for adding (semi) real-time communication technology to your applications and apps. It is open sourced and it is based on industry standards like HTML5 WebSockets.

It makes it possible to send messages from one client to all other clients (or a selection of them) in real-time. Or you can send messages back from the server to (a selection of) clients.

Think about that. How could you use this in your app? Add some chat functionality, automatic refreshing or push notification in your website or app? There are multiple client SDK’s available so use it so It could work in your app!

And SignalR has some tricks for older browsers or bad connections. So it will always try to communicate in the best possible ways. But in that case, the communication will be less (semi) live…

As you can see in the picture, each client is connected to one server when they make contact for the first time. They will try to hold this connection during the session for as long as possible. Websockets technology is optimized to send almost no data over the line as long as the connection is open so it’s very cheap in usage and the server load is still acceptable. The fall-back techniques like Ajax long polling is not that much optimized.

The only drawback in this picture is scaling. If you use multiple servers, messages received from a client on one server have to be transmitted to clients on the other servers also. For that, you need a backplane. This could be a message bus, for example. Normally you have to design and build your own backplane (see the wiki for in-depth information) or you can use Azure Mobile services. With AMS, this backplane is already available.

To get started with SignalR on AMS, just start a new AMS service in the portal and directly download the code generated for the service and two example clients (Windows universal app and Windows Phone ) from the portal.

And after compiling and testing the app (just to see if it is connected to Azure and working), add some Nuget packages both to the service and the clients. Use these Nuget package commands:

• Install-Package WindowsAzure.MobileServices.Backend.SignalR
• Install-Package Microsoft.AspNet.SignalR.Client

In the service, we need a simple initialization of SignalR when that service is activated. Add the following line in the Register method in the WebApiConfig.cs class:

• SignalRExtensionConfig.Initialize();

So it should look like this:

The only thing more that has to be done server-side is adding the actual logic to interact with. So add a map to the service project file tree and call it something like SignalR. And inside that map, add a SignalR hub:

This hub is the actual logic behind the SignalR endpoint. And it does multiple things…

Most importantly, the Send method can be called by any client. And doing so, the message passed will be broadcasted to all clients (including the caller).

And we assume on each client a method will be available and it will be named something like broadcastMessage. This is written with the first character in lower case (this is called camel casing) because the method will be written on the (browser) client, like JavaScript notation.

We also react to people connecting and disconnecting. We add the unique context id in a list so we know how many clients at any moment are connected. And when somebody connects or disconnects, all clients will receive a message informing them who joined or left.

We are now ready on the server. Deploy the server to Azure.

So the only thing we need to do now is actually consuming Azure Mobile Services SignalR on the client.

I added an extra XAML page to the Windows Store client and I added a broadcast button (which will connect the first time I hit it) and a disconnect button. When the app is running and we have broadcasted, it will look like:

The code behind the buttons is not that hard to understand also:

First of all, we need the HubConnection instance. It is created when we call ConnectToSignalR. See we also added some delegate methods to the  Error and SlowConnection events. And we create a proxy for the hub on the server and we establish the communication for broadCastMessage.

So now we can Connect and disconnect from the hub using the Hub connection, we can receive messages broadcasted by the server and we can send messages to the server.

Just play with it and deploy the app on multiple devices.

With this basic SignalR example, we have put already a lot of power in the client and service. And this solution is already scalable on the server by the automatically generated Backplane.