The project I am working on, Lydia, has several layers which exchange information using SignalR, on top of Nancy. I wanted to move away from the current mix of PCL and .NET 4.5 Framework-targeting assemblies and unify the whole solution behind the new .NET Standard.

Switching to Nancy and SignalR for .NET Standard

A prerelease version of Nancy can be added to a .NET Standard 1.6 project. I got it to run on top of Kestrel thanks to OWIN, after battling with the tools.

SignalR is currently (December 2016) being rewritten in order to run on top of Kestrel too, as a server component using the NuGet package Microsoft.AspNetCore.SignalR.Server. However, I’ve not been able to find the client counterpart to SignalR Server. The current samples rely on a WebSockets client to talk to the server.

Current WebSockets support

.NET Core comes with a clean asynchronous WebSockets client API, found in the NuGet package System.Net.WebSockets.Client, available on multiple platforms (apparently Windows, macOS and Linux). However, my first tests broke down with a PlatformNotSupportedException.

Windows 7 is not supported by System.Net.WebSockets.Client for now. Minimum requirement is Windows 8. However, my workstation is still running Windows 7 and I have no plans to replace it in the near future.

So, what are my options? There are several client implementations of the WebSocket protocol. I explored:

• WebSocketSharp
  Can be built as a single assembly, however not for .NET core. So I cannot use it from class libraries targeting .NET Standard 1.3. However, there is a pull request by galister who has a fork for .NET Core, which I discovered after having spent about two hours of coding to make my own port.
• WebSocket4Net
  Available as a NuGet package, compatible with .NET Standard 1.3.

Both project expose WebSockets in a similar way, yet neither has true async support (i.e. Task based). I found WebSocketSharp to have a richer API (with asynchronous methods based on callbacks) and WebSocket4Net to use more .NET-friendly naming conventions.

But for now, I really just need the most basic support to get things rolling. So I’ll start with WebSocket4Net and wrap it in such a way that I can easily replace it once WebSocketSharp is ripe.