SignalR Requests Throwing “Hub could not be resolved.”

做~自己de王妃 提交于 2019-12-05 10:45:42

I had this same error due to my Hub class being internal, therefore SignalR couldn't find it within my assembly.

Setting the hub to public solved the issue.

I suffer from this problem just now, and I dig in a little deeper, and have just found out a possible solution. My hub class are not in assembly of the web project, they are in some referenced assemblies. This is a very common scenario in a multi-layer application.

When starting up, signalR will try to find hub class by an IAssemblyLocator instance. When deployed within an IIS site, this IAssemblyLocator instance find through all referenced assemblies. But at this point of time, the application is just during the startup, which means many (referenced but not loaded yet) assemblies may had NOT been gathered by owin host environment. So the lookup for hub classes fails.

So, just add your assembly into system.web/compilation/assemblies section of Web.Config:

<system.web>
  <compilation targetFramework="4.5">
    <assemblies>
      <add assembly="HubAssembly, Version=1.0.0.0, Culture=neutral"/>
    </assemblies>
  </compilation>
</system.web>

Or if you like, you can also solved this problem by implementing a custom IAssemblyLocator class, register it into the dependency resolver as soon as app.MapSignalR is invoked.

using Microsoft.AspNet.SignalR.Hubs;
public class AssemblyLocator : IAssemblyLocator {
     public IList<System.Reflection.Assembly> GetAssemblies()
     {
         // list your hubclass assemblies here
         return new List<System.Reflection.Assembly>(new []{typeof(HubAssembly.HubClass).Assembly});
     }
}


// add following code to OwinStartup class's Configuration method
app.MapSignalR();
GlobalHost.DependencyResolver.Register(typeof(Microsoft.AspNet.SignalR.Hubs.IAssemblyLocator), () => new AssemblyLocator());

This is now an old question but it reared its ugly head again this weekend. After spending alot of time investigating I have found that SignalR wasn't the only thing broken in the deployment, my WebAPI was also throwing could not find controller exceptions.

Turns out this is caused by the internals of SignalR and WebApi reflecting over all the types in the Sites assembly. A TypeLoadException was being thrown , in my case due to having a class derive RoleEntryPoint which is an Azure type but as the site was being deployed in a non Azure Environment things fell apart. Simply excluding this type from non Azure builds resolved the issue.

It would be nice if these TypeLoadExceptions were more visible but there it is.

Similar to @Jijie Chen, when I hit this issue I found that it was not able to load my assembly containing my hub. The fix for me was more straightforward though. In my case I had three projects. All the logic, including the hub was in a project of its own and I had two projects intended to host using owin. One was a console project that was working fine. I then adapted that to a windows service to host it. Well, somehow I managed to forget to include a reference to the project containing my hub. This still compiled fine because the host code relies on the signalr/owin mapping functions which load the hub(s) at runtime not compile time. So when I would start up the service and try to connect I got the hub no defined error described here because it couldn't find the assembly with my hub.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!