Compatibility between Core SignalR server and Net 4 SignalR clients.

[tdhintz]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

We have a Net 4 winform providing a bridge between browsers and Windows TWAIN scanners. It was migrated to Net Core and now the negotiate fails. Research suggests this is because there is no compatibility option between Core and Net 4 SignalR servers and clients. The impact is that it is not possible to update either the SignalR server or client without requiring a reinstall of the winform bridging component across the entire customer base. This is a huge logistical issue.

Describe the solution you'd like

Provide a Net 4 SignalR compatibility mode for Core, or describe how Core can be configured for compatibility.

Additional context

Trace:

Debug: 2025-01-03 09:22:25.757 1 candidate(s) found for the request path '/s/negotiate'
Debug: 2025-01-03 09:22:25.758 Request matched endpoint '/s/negotiate'
Debug: 2025-01-03 09:22:25.760 The maximum request body size has been set to 104857600.
Information: 2025-01-03 09:22:25.761 Executing endpoint '/s/negotiate'
Information: 2025-01-03 09:22:25.763 Executed endpoint '/s/negotiate'
Information: 2025-01-03 09:22:25.764 Request finished HTTP/2 GET https://localhost:59754/s/negotiate?clientProtocol=2.1&connectionData=%5B%7B%22name%22%3A%22s%22%7D%5D&_=1735912793367 - 405 0 text/plain 14.2070ms

[willdean]

This was pretty much the exact issue which annoyed me several years ago to the extent that we abandoned SignalR altogether - we couldn't update all our clients and the servers they talked to simultaneously in a massive high-risk big-bang.

However, I did once berate the SignalR guys about this at a conference and they pointed-out that the new ("SignalR Core") client can actually run on old-style .NET framework. So you could, in theory, gradually upgrade your clients to support both the old and new flavours of SignalR and only once you'd done that would you need to switch over your server side.

I doubt that helps you, and I am fully in agreement that this was an absolutely horrible decision - new SignalR could have supported the old protocol, it just didn't, and presumably the fact that a web-browser can replace its client on a single refresh blinded them to the fact they'd completely screwed-over their native client users. The early days of 'core' were an absolute wild-west of casual compatibility breaks and this was one of the victims which never got fixed.

[davidfowl]

How much compatibility to you need? We've build some experiments in the past but they come with constraints and performance issues. Is this something that would would be using to migrate to the new client eventually or something more permanent?

I doubt that helps you, and I am fully in agreement that this was an absolutely horrible decision - new SignalR could have supported the old protocol, it just didn't, and presumably the fact that a web-browser can replace its client on a single refresh blinded them to the fact they'd completely screwed-over their native client users. The early days of 'core' were an absolute wild-west of casual compatibility breaks and this was one of the victims which never got fixed.

The old protocol leaves much to be desired... 😄. I wouldn't say it was designed like a protocol, it was more about making scenarios work way before websockets were ubiquitous. The new protocol was designed with lots of experience working on the original and even has specs and support for various serialization formats.