I’m trying to get SignalR working in a Servicestack Blazor application with no luck. I originally wanted to use ServiceStack Server Events - but was blocked by technical difficulties (see here). Rather than wrestle with JavaScript interop, I took a look at SignalR - and it looks like a good solution (failing over from Websockets to Server Events to Longpolling, works in blazor webassembly, will allow me to avoid the complexity of invoking C# code via JavaScript).
If I follow the standard SignalR Blazor tutorial from Microsoft (here) I am able to successfully communicate with the blazor client application. However, if I follow a similar process when using servicestack’s blazor-wasm template - I get the following errors:
I am at a loss to try and troubleshoot this…and I was hoping that you had some ideas on how to tackle this. Could it be SS Routing that is causing the issue? Could it be Authentication?
My Program.cs File looks like this (I originally had the SignalR configuration in a modular startup file, and tried to follow the MS tutorial more closely, thinking it might be an order-of-operations issue):
The only thing I can suggest is moving SignalR registration before ServiceStack so that it’s able to handle the request before it reaches ServiceStack.
Otherwise you’d need to report any SignalR issues into MS repos as I’ve never used SignalR and have no experience with any of its errors, all I can go off is the exceptions in the StackTrace suggesting it’s unable to use the LongPolling and ServerSentEvents transports, if you use a HTTP Inspector to analyze those failed requests it should provide better information about why its requests are failing.
just to make sure I’m understanding - in my startup process I have the SignalR registration happening on line 5, and ServiceStack happening on line 33…so I am already registering SignalR prior to SS (according to your suggestion)…right? or am I missing what you’re suggesting?
What happens in builder.Services only controls what dependencies are registered in the IOC, it has no effect on the order in which different handlers are registered, which starts after:
var app = builder.Build();
i.e. app is where ASP .NET Core Middleware is registered, that are run in the order they’re registered.
for the sake of posterity, and for anyone else with the same issue stumbling across this post - moving the App.MapHub<> declarations above the servicestack declarations resolved the issue…
