April 26th, 2019

Azure SignalR Service now supports ASP.NET!

Zhidi Shang
Principal Program Manager

We’ve just shipped the official version of the SignalR Service SDK with ASP.NET support:

Azure SignalR Service is a fully managed Azure service for real-time messaging. It is a preferred way for scaling ASP.NET Core SignalR applications. However, SignalR Service is built on SignalR for ASP.NET Core 2.0, which is not 100% compatible with ASP.NET SignalR. Code changes are required to make ASP.NET SignalR application work with SignalR Service. The service SDK also needs to add ASP.NET support specifically.

At Microsoft Ignite 2018, we announced ASP.NET support preview. Customers have been using the preview version SDK to develop ASP.NET SignalR applications with SignalR Service. Today, we are excited to announce that we have released the generally available version 1.0.0 of service SDK with ASP.NET support!

Typical architecture for ASP.NET support

This diagram illustrates the typical architecture to use Azure SignalR Service with an application server in either ASP.NET Core or ASP.NET.

arch.png

For self-hosted SignalR application, the application server listens to clients’ connection requests and manages client connections. With SignalR Service, the application server only responds to clients’ negotiate requests and redirects clients to SignalR Service to establish the persistent client-server connections.

With the ASP.NET support for Azure SignalR Service you can:

  • continue to keep SignalR application in ASP.NET, and work with fully managed ASP.NET Core based SignalR Service.
  • change a few lines of SignalR API codes, to switch to use SignalR Service instead of self-hosted SignalR Hubs.
  • leverage Azure SignalR Service’s built-in features and tools to help operate the SignalR application, with guaranteed SLA.

Supported SDK versions

To receive the full benefit from the new ASP.NET support, please download and upgrade your SDKs to the latest supported versions:

  • .NET: 4.6.1+
  • Microsoft.AspNet.SignalR.*: 2.4.1
  • Microsoft.Azure.SignalR.AspNet: 1.0.0

What features are not supported?

Many factors, including non-technical ones, make it difficult to migrate the web application from ASP.NET SignalR to ASP.NET Core. The goal of this ASP.NET support is to make this migration easier with little code changes.

Some APIs and features are no longer supported:

  • Automatic reconnects
  • Forever Frame transport
  • HubState
  • PersistentConnection class
  • GlobalHost object
  • HubPipeline module
  • Client-side Internet Explorer support before Microsoft Internet Explorer 11

ASP.NET support is focused on compatibility, so not all new features from ASP.NET Core SignalR are supported. For example, MessagePack, Streaming, etc., are only available for ASP.NET Core SignalR applications.

SignalR Service can be configured for different service mode: Classic/Default/Serverless. In this ASP.NET support, the Serverless mode is not supported.

For a complete list of feature comparison between ASP.NET SignalR and ASP.NET Core SignalR, and the recommended alternatives to features discontinued, please refer to doc here.

Next steps

We’d like to hear about your feedback and comments. You can reach the product team at the GitHub repo, or by email.

Author

Zhidi Shang
Principal Program Manager

Zhidi Shang is a Principal Program Manager in Visual Studio China team, focusing on developer services on Azure.

3 comments

Discussion is closed. Login to edit/delete existing comments.

  • Lyudmil Petrov

    But if I am channel to use Azure SignalR what is the monetary cost vs self host SignalR

    • Zhidi ShangMicrosoft employee Author

      There is a pricing page detailing the cost https://azure.microsoft.com/en-us/pricing/details/signalr-service/ . Also for real-world scenarios, you will need to do the capacity planning based on how much resources you'll need to meet the performance requirements. Some guidances can be found at this doc: https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-performance In general, the costs are comparable for most typical scenarios, but you will save lots of developer costs on coding and operating. When scaling out with more client connections, it will actually...

      Read more