SignalR client library for .NET Standard 2.0

[kant2002]

Expected behavior

I expect that WebSocketTransport would be available when targeting .NET standard 2.0 projects

Actual behavior

For the .NET Standard 2.0 library used version to 1.6 If I understand correctly which does not have WebSocketTransport

The reason why I need this is that new SignalR for ASP.NET Core is not compatible with original SignalR and I have to keep original SignalR until I able to replace all clients which use old version.

[moozzyk]

SignalR 2.2.2 was shipped before .NET Standard 2.0 shipped so couldn't target .NETStandard 2.0. Some platforms (like UWP) don't support .NET Standard 2.0 at the moment. What platforms are you running your client on - maybe you could cross compile?

[kant2002]

@moozzyk I have library which target .NET standard 2.0 and in that library (let's name it ClientLib) I implement client to existing Signalr 2.2.2 server. In that project WebSocketTransport is not available. My guess is that .NET Standard 1.6 picked up.

Target application which consume SignalR 2.2.2 will be using .NET Core 2.0 (netcoreapp2.0) (let name it WebApp) and will expose existing server over new .NET Core SignalR.

ClientLib - .NET STandard 2.0 - no WebSocketTransport
WebApp - netcoreapp2.0

ClientLib - .NET STandard 2.0  + net452- has WebSocketTransport under (net452)
WebApp - netcoreapp2.0 - version .NET Standard 2.0 picked up so no (WebSocketTransport)

That's what I try so far.
What exactly do you mean under cross-compile? Do you mean manually compile SignalR client for .NET Standar 2.0 from source code, or just existing options in the .NET Core 2.0 tooling ?

[moozzyk]

By cross compiling I meant - build your library for both - netstandard and net452 and use the net452 version if/where you can. There are a couple of big hammer options like implementing a WebSocketTransport yourself (e.g. by compiling the transport we already have) and passing it to the client or compiling the client itself for netstandard2.0 and enabling the websocket transport but they feel quite involved.

[iloginov]

@kant2002 You can simply build your own version of AspNet.SignalR from sources. Simply change #if that enables WebSockets only for .NET 4.5. Net Standard 2 has all needed requirements.

[Jacknq]

+1 library for .net core 2,
u re not compatible guys when will you finally?
still have to use preview version in order to run it on linux..
u can have best library in the world but if nobody can use it, its useless.

[junkomatic]

+1 for .Net Core 2.....
Just migrated my whole client app to .NET Core 2 and find out it's useless now because I cant invoke any hub methods anymore.

[moozzyk]

@junkomatic - if you converted your client only you should be able to use the current client to invoke hub methods. The only downside currently is that you will not get WebSockets transport - only SSE and LongPolling are currently supported because WebSockets are not in netstandard1.6 which the client currently targets (because https://github.com/SignalR/SignalR/issues/3996#issuecomment-323793800).

[mariotoffia]

+1 for .Net Core 2 - I'm doing a .net core 2 application and one of the APIs that have been requested to be integrated uses this signalR server and thus incompatible with net core and do only support websocket as transport. So I'm trapped.

Cheers,
Mario

[lnaie]

We also need WebSocketTransport to connect to a 'legacy' signalr system from a dotnet core application. :)

[MagicAndre1981]

I found this Package:

https://www.nuget.org/packages/Xamarin.SignalR.WebSocketTransport

var httpClient = new Microsoft.AspNet.SignalR.Client.Http.DefaultHttpClient();

await Connection.Start(new AutoTransport(httpClient,
new IClientTransport[]
 {
    new WebSocketTransport(httpClient),
    new ServerSentEventsTransport(httpClient),
    new LongPollingTransport(httpClient)
 }));

For me it doesn't fix my issue, I still have a hang at Start, but maybe it works for you others.

[aspnet-hello]

This issue has been closed as part of issue clean-up as described in https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. If you're still encountering this problem, please feel free to re-open and comment to let us know! We're still interested in hearing from you, the backlog just got a little big and we had to do a bulk clean up to get back on top of things. Thanks for your continued feedback!