I’m building an ASP.NET Core app with a SignalR hub. Even though I’m running in Visual Studio 2017, I found that websockets don’t work because my development machine is still running Windows 7 (gotta love Enterprise). However, I’ll be deploying to a Windows Server 2012 R2 machine, which will support websockets, so I want to go that route when it’s available. I realized that I could use the rejected promise to reinitialize the SignalR hub connection with long-polling as the transport method, but there seems like there should be a better way. Namely, from what I’ve read, SignalR is supposed to fallback to long-polling on its own if websockets aren’t supported, but that doesn’t seem to be the case. This might be due to running the SignalR 1.0.0-alpha2-final (the best available for ASP.NET Core), or it might be due to the fact that the server (IIS Express, in this case) is actually reporting that it supports websockets in the payload of response to the OPTIONS request. In truth, it does, but the OS-level support, unfortunately is not there.
Anyways, this is the code I’m running. Since I’ve just started with SignalR, I wanted to get some input on whether what I’m doing is the best way to go about handling this situation. Any other comments or suggestions would also be more than appreciated.
(function () { function GetConnection(webSockets) { let transportType = webSockets ? signalR.TransportType.WebSockets : signalR.TransportType.LongPolling; let connection = new signalR.HubConnection('/foo', { transport: transportType }); connection.on('done', jobId => { // do stuff }); return connection; } function CreateSubscriptions(connection) { @foreach (var job in Model.Jobs.Where(j => !j.HasFile)) { @:connection.invoke('subscribe', @job.Id); } } let connection = GetConnection(true); connection.start() .then(() => CreateSubscriptions(connection)) .catch(() => { connection = GetConnection(false); connection.start() .then(() => CreateSubscriptions(connection)); }); })();