2012-02-22 11 views
1

私はUnityを使用してインスタンスを解決します。 WCFサービスを含める。WASアプリケーションプールをリサイクルした後、Unityを使用してインスタンスを解決すると失敗する

しかし、私はトリックの問題を発見しました。 WCFプログラムをIIS(WAS)にデプロイしています.Webサービスを実行しても問題ありません。

IIS(WAS)アプリケーションプールをリサイクルした後、私のレジスタコードが実行されたと確信しています。 しかし、今のWebサービスが例外をスローは、

「中に例外が発生しました。:解決中」と言います

次に、IISサービスから情報を記録します。このタイプは登録しません。

+0

は、今私はユニティコンテナの登録を確認し、タイプとマッピングのタイプを登録し、両方のあなたはWCFとUnityに統合するにはどうすればよいのユニティ・コンテナ登録コレクション – metavige

+0

に存在していますか?カスタムの 'ServiceHostFactory'や何か別のものを経由しますか?あなたは例外を投げた同じスレッドの登録をチェックしていますか? WCFは本質的にマルチスレッドであり、登録コードが適切なスレッド上で実行されないと問題を引き起こす可能性があります。 –

+0

はい、ServiceHostFactoryを使用し、InstanceProviderを実装します。 InstanceProviderの内部では、UnityContainerを使用してサービスインスタンスを作成します。 しかし、インターフェイスとその実装タイプを登録するには、Asp.Netテンプレートフォルダのアセンブリではなく、binディレクトリでアセンブリを使用します。 – metavige

答えて

3

私はこの問題を自分で解決しました。

場合は、アプリケーションプールのリサイクルと新しいアプリケーションプールを起動作成、すべてのDLLは、新しいAsp.Netテンプレートフォルダにコピーします。

私はアプリケーションドメインにすべての「bin」DLLをロードするように強制するとき、私はビンのアセンブリにタイプを登録します。 Asp.net Tempフォルダのアセンブリではありません。だからUnityはそれが違いのタイプだと思った。

は、今は固定の問題次に

string binPath = System.IO.Path.Combine(System.AppDomain.CurrentDomain.BaseDirectory, "bin"); 
foreach (string dll in Directory.GetFiles(binPath, "*.dll", SearchOption.AllDirectories)) 
{ 
    var assemblyFromCurrentDomain = Assembly.Load(Assembly.LoadFile(dll).FullName); 

    Debug.Print("Add Assembly : {0}, {1}", assemblyFromCurrentDomain.FullName, assemblyFromCurrentDomain.Location); 
} 

現在のドメインにアセンブリをロードする方法を変更します。

関連する問題