Setup:
- SignalRServer console app: Microsoft.AspNet.SignalR.SelfHost v2.0.3
- SignalRClient console app: Microsoft.A
I has several similar problems with SignalR (not exacly in the same scenario).
The problem was usually caused in communication model request_from_server->client->response_to_server. When I tried to call Invoke in client code (to send response to server) directly in the receiving procedure, I got strange behavior (infinite waits, strange side effects, etc.).
Solution was to divide process into two threads. One for receiving messages from server to local ConcurrentQueue. The second thread fetches messages from the queue, processes them and sends responses back to server (by Invoke). Now SignalR works as expected.
This issue was probably caused by trying to send response BEFORE receiving procedure finished. This does not happen in usual client->server->client communication model.
The SignalR team pointed me to the solution: By default SignalR uses GlobalHost, which is a singleton resolver. When disposed, it will never come back.
When creating the configuration for the hub, you should pass inn a new dependency resolver:
public class Startup
{
public void Configuration(IAppBuilder app)
{
var hubConfiguration = new HubConfiguration {Resolver = new DefaultDependencyResolver()};
app.MapSignalR(hubConfiguration);
}
}
Stian's answer is great. But if you need to use static methods defined in GlobalHost, you need to assign the Dependency resolver to GlobalHost.
The following works for me:
public void Configuration(IAppBuilder app)
{
.... Other configurations ....
GlobalHost.DependencyResolver = new DefaultDependencyResolver();
app.MapSignalR();
}
I defined the hub context this way:
public sealed class RemoteAdminHub : Hub
{
#region Properties
/// <summary>
/// Gets the SignalR Hub context.
/// </summary>
public static IHubContext HubContext
{
get
{
return GlobalHost.ConnectionManager.GetHubContext<RemoteAdminHub>();
}
}
#endregion
}