7

初期のバージョンから SignalR を使用しており、途中でアップグレードしましたが、アプリケーションを Windows Server 2008 R2 運用サーバーに展開したところ、「ハブを解決できませんでした」というメッセージが表示されてアプリがクラッシュしました。例外。

編集: StackTrace 追加:

[InvalidOperationException: 'stockitems' Hub could not be resolved.]
Microsoft.AspNet.SignalR.Hubs.HubManagerExtensions.EnsureHub(IHubManager hubManager,  String hubName, IPerformanceCounter[] counters) +426
Microsoft.AspNet.SignalR.Hubs.HubDispatcher.Initialize(IDependencyResolver resolver, HostContext context) +716
Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary`2 environment) +1075
Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary`2 environment) +363
Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute() +68
Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData) +414

[TargetInvocationException: Exception has been thrown by the target of an invocation.]
Microsoft.Owin.Host.SystemWeb.CallContextAsyncResult.End(IAsyncResult result) +146
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +606
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

私の開発マシンとローカル テスト サーバーでは、問題は発生していません。

問題のハブは非常に単純です。

 [HubName("StockItems")]
public class StockItemHub : Hub
{

}

もともと HubName の問題だと思っていたので削除しましたが、それでも爆発します。

もともと依存性注入が原因だと思っていたので、Global.asax を次のように変更しました。

    var signalRResolver = new SignalRDependencyResolver();
        GlobalHost.DependencyResolver = signalRResolver;

        var configuration = new HubConfiguration { Resolver = signalRResolver };
        RouteTable.Routes.MapHubs(configuration);

        AreaRegistration.RegisterAllAreas();

        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters, config.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

編集: SignalRDependencyResolver とは何ですか? この問題を解決しようとするまで、SignalRDependencyResolver は存在しませんでした。依存性注入の問題だと思うので、DefaultDependencyResolver をラップして GetService と GetServices をオーバーライドし、最初に Ninject カーネルのタイプをチェックし、そうでない場合は DefaultDependencyResolver にフォールバックします

何か案は？

サーバーは IIS7、.Net 4.5 を搭載した Windows Server 2008 を実行しています アプリケーションは MVC 4 .Net 4.5 です

4

4 に答える 4

8

私は今この問題に苦しんでおり、もう少し深く掘り下げて、可能な解決策を見つけました. 私のハブ クラスは Web プロジェクトのアセンブリではなく、いくつかの参照アセンブリにあります。これは、マルチレイヤー アプリケーションでは非常に一般的なシナリオです。

起動時に、signalR は IAssemblyLocator インスタンスによってハブ クラスを見つけようとします。IIS サイト内に展開すると、この IAssemblyLocator インスタンスは、参照されているすべてのアセンブリを検索します。ただし、この時点では、アプリケーションは起動中です。つまり、多くの (参照されているがまだ読み込まれていない) アセンブリが、owin ホスト環境によって収集されていない可能性があります。そのため、ハブ クラスの検索は失敗します。

したがって、アセンブリを Web.Config の system.web/compilation/assemblies セクションに追加するだけです。

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

または、必要に応じて、カスタム IAssemblyLocator クラスを実装し、app.MapSignalR が呼び出されるとすぐに依存関係リゾルバーに登録することで、この問題を解決することもできます。

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());
于 2014-02-21T16:38:05.247 に答える
3

これは今では古い質問ですが、今週末また醜い頭をもたげました。調査に多くの時間を費やした後、デプロイで壊れたのは SignalR だけではなく、WebAPI もスローしていて、コントローラーの例外が見つからないことがわかりました。

これは、SignalR と WebApi の内部が Sites アセンブリのすべての型を反映していることが原因であることが判明しました。私の場合、Azure タイプである RoleEntryPoint をクラスが派生させたため、TypeLoadException がスローされていましたが、サイトが Azure 以外の環境にデプロイされていたため、問題が発生しました。Azure 以外のビルドからこのタイプを除外するだけで、問題は解決しました。

これらの TypeLoadExceptions がもっと見やすくなればいいのですが、実際にはあります。

于 2013-04-23T12:52:14.450 に答える