IIS and SignalR background thread
I need to have a background thread that does some work and sends data to users connected to the service via SignalR.
I was thinking about hosting this topic in IIS and showing it up when I first run Application_Start or in a separate workflow.
If I host it in IIS and create it at the start of the application - The thread only starts the first time the application is clicked. I need it to work as soon as I start the service. - I have no control over this thread through the desktop GUI, I cannot stop or pause it in an easy way.
If I host it in a separate process such as a Windows service - I don't have access to the SignalR service instance - I don't want to connect to the SignalR service as a user to pass data to other users. I take a different approach to this, which does not imply that the worker is a client of SignalR itself.
What is your opinion on this? Do you see any other solution?
source to share
We addressed this to create a separate endpoint in the web application that your Windows service can call.
Imagine the following URI exists in an ASP.NET MVC controller: http: // [myserver] / api / TellUsers / [msg] . Inside this method, you can get the connected hub clients and make the call.
[HttpPut]
public void TellUsers(string msg)
{
var connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
var demoClients = connectionManager.GetClients<MyHubDerivedClass>();
demoClients.TellUsers(msg);
}
[Insert a warning about correct error checking here.]
Of course, you don't need to use MVC. Any public URI will work. As far as security is concerned, you can use any valid method for securing ASP.NET endpoints.
source to share
I know the question is pretty old, but:
In truth, I really like the "client" example. This gives you control from many different points, not just one. Example. Several services can call to operate the service. I see no reason why you don't have an administrator who can invoke special commands that other users cannot.
This is a proven design for many systems. I would stick with that.
source to share