I have a multi-paged ASP.NET core web app, with MVC, which i want to use SignalR with. As far as i know, the SignalR HubConnection is dropped every time on navigation, page refresh etc...
Is it possible to maintain long live access to the hub ?
For this scenario, should i go with the Javascript or the .Net implementation of the SignalR on the Client side ?
For example.:
register it as a singleton service in DI
Use it in a "shared" _Layout
create some kind of "static" .js file which i could access from all Views
I was thinking about the "Reconnection" method as a solution, but for some reason, it is unavailable for me, i can't see the override method at server side.
I am using Microsoft.AspNetCore.SignalR (1.0.4 ) right now ... Should i change the server side to Microsoft.AspNetCore.SignalR.Core (1.0.4 ) ?
I have a multi-paged ASP.NET core web app, with MVC, which i want to use SignalR with. As far as i know, the SignalR HubConnection is dropped every time on navigation, page refresh etc...
Is it possible to maintain long live access to the hub ?
This is simply the way web sites work. The entire SignalR application is running in the browser. A refresh or going to a new pages causes the entire SignalR application to reload and connect. Look into building a Single Page Application (SPA) where the
SignalR app is loaded once.
I have a multi-paged ASP.NET core web app, with MVC, which i want to use SignalR with. As far as i know, the SignalR HubConnection is dropped every time on navigation, page refresh etc...
As you said, when a browser client closes a browser window or tab, or navigates to a new page or refreshes the page, the SignalR connection immediately ends, because SignalR client code handles that browser event for us.
Besides, in JavaScript client we usually create and start the connection after web page is ready, if navigation or refresh occurs, the code would be executed again and a new connection would be established. If possible, as mgebhard mentioned, you can try
to build it with Single Page Application.
With Regards,
Fei Han
.NET forums are moving to a new home on Microsoft Q&A, we encourage you to go to Microsoft Q&A for .NET for posting new questions and get involved today.
None
0 Points
3 Posts
SignalR Long Live Access From Client Side
Nov 06, 2018 08:52 AM|ImHoTeP_Hun|LINK
Hey all,
I have a multi-paged ASP.NET core web app, with MVC, which i want to use SignalR with. As far as i know, the SignalR HubConnection is dropped every time on navigation, page refresh etc...
Is it possible to maintain long live access to the hub ?
For this scenario, should i go with the Javascript or the .Net implementation of the SignalR on the Client side ?
For example.:
I was thinking about the "Reconnection" method as a solution, but for some reason, it is unavailable for me, i can't see the override method at server side.
I am using Microsoft.AspNetCore.SignalR (1.0.4 ) right now ... Should i change the server side to Microsoft.AspNetCore.SignalR.Core (1.0.4 ) ?
All-Star
53641 Points
24007 Posts
Re: SignalR Long Live Access From Client Side
Nov 06, 2018 12:40 PM|mgebhard|LINK
This is simply the way web sites work. The entire SignalR application is running in the browser. A refresh or going to a new pages causes the entire SignalR application to reload and connect. Look into building a Single Page Application (SPA) where the SignalR app is loaded once.
All-Star
40565 Points
6233 Posts
Microsoft
Re: SignalR Long Live Access From Client Side
Nov 07, 2018 06:50 AM|Fei Han - MSFT|LINK
Hi ImHoTeP_Hun,
As you said, when a browser client closes a browser window or tab, or navigates to a new page or refreshes the page, the SignalR connection immediately ends, because SignalR client code handles that browser event for us.
For detailed information, please check "Client disconnection scenarios".
Besides, in JavaScript client we usually create and start the connection after web page is ready, if navigation or refresh occurs, the code would be executed again and a new connection would be established. If possible, as mgebhard mentioned, you can try to build it with Single Page Application.
With Regards,
Fei Han