SignalR WebSocket exception when upgrading to latest System.Collections.Immutable library

[jc1001]

Describe the bug

I have a .NET Core 2 application that is targeting the full .NET Framework (v4.8).
It hosts a web server (using HttpSys) that exposes a SignalR hub.
I can make a successful call from a client (in this case a .NET console application) to the SignalR hub.

When I upgrade the System.Collections.Immutable library on the server to v1.7.1, the connection call from the client application to the SignalR hub on the server fails with a WebSocketException.

To Reproduce

I have attached a sample solution that reproduces the problem.
SignalRBug.zip

The solution contains 2 projects: "Client" and "Server".
An instance of "Server" must be running (hosting on http://localhost:8080) before you can execute "Client".
The example (as attached) will run without any errors.

When you edit the Server.csproj file to include the latest version of the System.Collections.Immutable library, the client application will fail as described above.

Exceptions (if any)

WebSocketException

Message: The remote party closed the WebSocket connection without completing the close handshake.
Stack trace:

   at System.Net.WebSockets.WebSocketBase.WebSocketOperation.<Process>d__19.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Net.WebSockets.WebSocketBase.<ReceiveAsyncCore>d__45.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Http.Connections.Client.Internal.WebSocketsTransport.<StartReceiving>d__19.MoveNext()
   at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at System.IO.Pipelines.Pipe.DefaultPipeReader.GetResult(Int16 token)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at Microsoft.AspNetCore.SignalR.Client.HubConnection.<HandshakeAsync>d__61.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.SignalR.Client.HubConnection.<StartAsyncCore>d__47.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.SignalR.Client.HubConnection.<StartAsyncCore>d__47.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.SignalR.Client.HubConnection.<StartAsync>d__39.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at Client.Program.<Main>d__0.MoveNext() in D:\Temp\SignalRBug\Client\Program.cs:line 17

Further technical details

• .NET Framework 4.8
• Microsoft Visual Studio Enterprise 2019, Version 16.7.1
• Windows 10, version 2004 (Build: 19041.450)

[BrennanConroy]

The error is on the server side:

System.IO.FileLoadException: 'Could not load file or assembly 'System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'

[jc1001]

Thank you for the feedback.

I had a look at the fusion log viewer and can see that the server is trying to load both version 4.1.4 and version 4.1.3 of the System.Numerics.Vectors dll.

The output directory of the server does contain version 4.1.4 of this dll, so that one loads successfully. 4.1.3 fails because there does not seem to be a binding redirect in the config file.

I did confirm that manually adding a binding redirect solves the problem, but I would have expected this to be done by the compiler (like it does for all the other required binding redirects)?

[BrennanConroy]

Glad you got it working. I don't think there is anything we can do on our side here.

You might want to try asking in the NuGet repo: https://github.com/NuGet/NuGet.Client

[jc1001]

@BrennanConroy, I've raised this issue on the runtime project (dotnet/runtime#41597). Seems that it is caused by an older version of the System.Net.WebSockets.WebSocketProtocol library (v4.5.1). The latest version of the library (v4.7.1) does fix this issue. They provided a workaround (adding a reference to the latest library).

I'm not sure if it would be possible to update the relevant NuGet packages to reference the newer libraries to prevent other people from running into the same error? If not, I can always stick with the workaround.