SignalR client not reporting version correctly

[lukedukeus]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using the ts/js signalr library, if you write your own hub protocol that implements signalR.IHubProtocol, the version number is always reported as 1, even if you set it to something else.

I have an ASP.NET Core project that has a GRPC API, so I thought it made sense to use protobuf serialization instead of JSON serailization for my hubs. I wrote a C# class that implements IHubProtocol that looks like this:

    public class ProtobufProtocol : IHubProtocol
    {
        public string Name => "protobuf";

        public int Version => 3;

        public TransferFormat TransferFormat => TransferFormat.Binary;

        public bool IsVersionSupported(int version)
        {
            return Version == version;
        }

        ... omitted for berevity ...
    }

I then wrote the corresponding implementation in TS, but this time, implementing signalR.IHubProtocol:

export class ProtobufProtocol implements signalR.IHubProtocol {
	name = "protobuf";
	version = 3;
	transferFormat = TransferFormat.Binary;

        ... omitted for berevity ...
}

The result is that C# clients can connect to the hub fine, but TS clients cannot, and the error that they recieve is: SignalR connection failed Error: Server returned handshake error: The server does not support version 1 of the 'protobuf' protocol.. I would not expect this error, because neither end of the protocol reports to be version 1.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[BrennanConroy]

That version isn't intended for users to create new version numbers for. It's only for versions of the SignalR protocol.

e.g. If we added a new type that IHubProtocol implementations need to handle then we'd increment that version and avoid using the new type if that version isn't supported by the IHubProtocol that was negotiated between client and server.

[lukedukeus]

That makes sense. I thought it was so that the implementer could have multiple versions of the same protocol, like proto2 / proto3 in my case. I think instead I should include the version number in the name field