Description
Reporting this because it took me a couple hours to figure out.
One must be sure to invoke the same AddSignalR and UseSignalR overloads, otherwise confusing dependency resolution errors occur. For example, if one invokes:
services.AddSignalR(signalRSettings, streamToClient)
// Oops, forgot to pass in streamToClient
app.UseSignalR(signalRSettings)
The following runtime error occurs when attempting to connect to the hub:
fail: Microsoft.AspNetCore.SignalR.HubConnectionHandler[1]
Error when dispatching 'OnConnectedAsync' on hub.
System.InvalidOperationException: Unable to resolve service for type 'Fable.SignalR.BaseFableHubOptions`2[Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Core.Unit]' while attempting to activate 'Fable.SignalR.BaseFableHub`2[Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Core.Unit]'.
at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService(IServiceProvider sp, Type type, Type requiredBy, Boolean isDefaultParameterRequired)
at lambda_method(Closure , IServiceProvider , Object[] )
at Microsoft.AspNetCore.SignalR.Internal.DefaultHubActivator`1.Create()
at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.OnConnectedAsync(HubConnectionContext connection)
at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.OnConnectedAsync(HubConnectionContext connection)
at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.RunHubAsync(HubConnectionContext connection)
Steps to reproduce
- Per the above, you just need a mismatch between
AddSignalR and UseSignalR overloads, which causes a mismatch between types registered and types requested during resolution
Expected behavior
At minimum, it would be nice to have a good runtime error message guide the dev here. But I'm also not sure why the split between send/invoke and streaming exists. If Settings had streaming-related properties in it too, there would be no need for multiple overloads and hence no chance of mismatching calls.
Description
One must be sure to invoke the same
AddSignalRandUseSignalRoverloads, otherwise confusing dependency resolution errors occur. For example, if one invokes:The following runtime error occurs when attempting to connect to the hub:
Steps to reproduce
AddSignalRandUseSignalRoverloads, which causes a mismatch between types registered and types requested during resolutionExpected behavior
At minimum, it would be nice to have a good runtime error message guide the dev here. But I'm also not sure why the split between send/invoke and streaming exists. If
Settingshad streaming-related properties in it too, there would be no need for multiple overloads and hence no chance of mismatching calls.