問題タブ [ierrorhandler]

私は基本的にIErrorHandler、WCF サービスからあらゆる種類の例外をキャッチするためのインターフェイスを実装し、ProvideFaultメソッドを実装することでそれをクライアントに送信しています。

ただし、1 つの重大な問題に直面しています。すべての例外は としてクライアントに送信されますFaultExceptionが、これにより、クライアントがサービスで定義した特定の例外を処理できなくなります。

考慮してください:それは実装SomeExceptionの 1 つで定義され、スローされました。OperationContract例外がスローされると、次のコードを使用してフォルトに変換されます。

これはエラーを文字列として送信しますが、クライアントは次のような一般的な例外をキャッチする必要があります。

ではない:

SomeException のようなカスタム例外だけでなく、InvalidOperationException のようなシステム例外は、上記のプロセスを使用してキャッチすることはできません。

この動作を実装する方法についてのアイデアはありますか?

IErrorHandlerWCF サービスのすべてのエラー処理を 1 か所に集中させるために実装しています。これはかなりうまくいきます：

現在、サービスの残りの部分に依存関係を注入するために Ninject を使用しています。ここでも同じことを行いたいと思います。WCF は構成に基づいてオブジェクトを構築しており、このプロセスにフックがないと思うので、プロパティ インジェクションを使用する必要があります。

ただし、これは決して注入されないようです。Ninject の MVC 拡張機能を使用してServiceErrorHandler、フィルターのようにインジェクションを許可するように設定しようとしましたが、うまくいかないようでした。これを実現する方法はありますか？

WCF サービスに IErrorHandler を実装して、何をクライアントに送信するか (ProvideFault) を決定し、例外をログに記録する (HandleError) ようにしました。

このプロセスの一環として、次のことを行います。

1. 内部例外の詳細を非表示にする標準テキストを含むエラー コードをクライアントに送信します。
2. ログ ファイルのエントリとクライアントからのエラー レポートを照合できるように、エラーを同じエラー コードでログに記録します。

私はこれを調べてきましたが、同じエラー コードが両方のメソッドで使用されることが保証される方法を見つけることができません。HandleError は将来別のスレッドで呼び出されるためです。これは、HandleError が呼び出される前に ProvideFault が 2 回呼び出される可能性があるため、ある種のクラス レベル カウンターを持つことを除外しているように思われます。

誰かが同じ状況に遭遇し、このシナリオで使用するソリューション/パターンを考え出しましたか?

Wcf サービス プロジェクトで Castle windsor 3.0 を使用しています。Topshelf を使用して Windows サービス プロジェクトとしてホストしています。私の wcf サービス構成はすべて app.config ファイルにあります。私は城の wcffacility を使用しており、このようなサービスを登録しています -

これにより、ILog (log4net から) が問題なくサービスに挿入されますが、IErrorHandler への挿入に失敗します。

IErrorHandler を使用して ServiceBehaviour を追加したので、ユーザーの未処理の例外をキャッチし、以下のコードを使用してエラーをログに記録できます。

このstackoverflowの投稿を見ましたが、古すぎて回答が投稿されていなかったため、この新しい質問を投稿しています。

アップデート

私はgreyAlienによって提供された答えでこれを解決しました（今のところ部分的に）。私がしなければならなかったのは

1. カスタム サービス動作クラスをウィンザー城に登録します。

   /li>

2. app.config ファイルから serviceBehaviour 拡張機能を削除します。構成ファイルに動作拡張を追加すると、何らかの理由で城が依存関係を注入できず、代わりに Wcf が新しいインスタンスを作成していて、ロガーのパブリック プロパティが null になっていると思います。

現在は機能していますが、behaviourextensions を使用して依存関係を注入する方法についても (将来) 理解する必要があります。

私は実装しようとしていますが、IErrorhandlerこれは本当に苦痛であることが証明されています!

私はインターフェイスから provideFault メソッドを実装しましたIErrorhandler...

サービス操作で例外が発生した場合、このメソッドに落ちてFaultException. 私の問題は、クライアントがこれFaultExceptionを返さないことです。

ここで明らかな何かが欠けていますか？

前もって感謝します

いくつかのコンテキスト: カスタム XSD があり、WSCF.blue を使用して WSDL および C# コードを生成します。クライアント側はChannelFactory<T>、XSD の内容と一致するように WSCF.blue によって追加されたすべての属性を含むインターフェースを使用および共有します。

IErrorHandler.ProvideFaultgeneric を提供する場所を実装しようとしていますFaultException<T>が、クライアント側では非ジェネリックを取得していますFaultContract。これは私のProvideFault方法がどのように見えるかです：

各サービスメソッドで、try/catch を実行すると期待どおりに動作するので、 、ファクトリ、バインディングなどはすべて正しいthrow FaultExceptionFactory.CreateFaultException(ex)と思います。[FaultContract]念のため、工場の仕組みは次のとおりです。

IErrorHandler問題は、メッセージが で、おそらく で作成される方法にあると思いますCreateMessageFault()。faultException.Actionアクションはの代わりにすべきだと読みnullましたが、実際faultException.Actionにはnullです。たぶん、これが問題の原因です。ファクトリでアクションを設定できますが、アクションはどうあるべきで、なぜそれが手動スローで表示されないのでしょうか?

私が見逃している可能性のある他のアイデアはありますか？

編集: WSDL を確認したところ、呼び出していた特定の操作とそのアクションが見つかりました。

action:Message.CreateMessage(..., "http://myNamespace/MyMethodBusinessRuleFaultExceptionTypeFault")をハードコーディングして、工場で に設定しようとし.Actionましたが、それでもうまくいきませんでした。

編集 2: throw/catch は、クライアントで一般的な例外をキャッチできる次の XML を生成します。

はIHttpErrorHandler、非ジェネリックに行く以下を生成しますFaultException:

編集 3:とを に追加する[DataContract]と、ほぼ正しい XML が得られます。[DataMember]BusinessRuleFaultExceptionType

Code と Reason の名前空間がありません。少なくともこれで絞れると思います。通常のシリアル化では and を使用し、 では[XmlType]and[XmlElement]をIErrorHandler使用[DataContract]してい[DataMember]ます。残念ながら[DataMember]、名前空間を設定することはできません。そのため、問題は .xml で XMLSerializer を使用する方法だと思いますIErrorHandler。これは私の問題を説明していますが、上記の理由で修正は機能しません: http://twenty6-jc.blogspot.com/2011/05/ierrorhandlerprovidefault-serialization.html

編集 4: 問題を部分的に見つけました。を使用してXmlSerializerいIErrorHandlerますが、運用範囲外のため、デフォルトの に戻しますDataContractSerializer。解決策は、サービスをどこでも使用するように変更するか、障害を作成するときにDataContractSerializer手動で選択することです。XmlSerializerこれらの 2 つの記事は、私が必要としていたものを提供してくれました。

http://twenty6-jc.blogspot.com/2011/05/ierrorhandlerprovidefault-serialization.html http://zamd.net/2008/08/15/serializing-faults-using-xmlserializer/

それは私を非常に近づけます。例外タイプの名前空間がないことを除いて、これは作業中の XML と同じです。

xmlns="http://myNamespace/Services"リクエストのコンテキストがないため、追加されないと思います。その名前空間はインターフェイスで定義されていますが、データ コントラクトでは定義されていません。IOperationInvokerを使用する代わりに、リクエストのコンテキスト内にとどまることを本当に強制されるのIHttpHandlerでしょうか(うまくいけばうまくいきます)。

さて、私はこれと文脈の質問に名前を付けるつもりでしたが、どうやら質問という言葉はタイトルでは許可されていません.

とにかく、ここに問題がIErrorHandlerあります。すべてのサービス コードを乱雑にすることなくログを提供するために、WCF サービスで使用しています。これまでのところ、これはうまく機能しています。ただし、完全に非同期のサービスに移行しようとしている今call stack、因果連鎖ではなくリターン スタックであるという問題に直面しています。

ここで、Stephen Cleary の論理呼び出しコンテキスト MyStackNinjectをのIntercept拡張機能と組み合わせて使用​​してみました。

注入する:

SimpleContextGenerator:

ただし、問題は 2 つあります。1)usingエラーが実際にスローされる前に が完了し、2) に到達するまでにコンテキスト全体がクリアされるため、1 も問題ではありませんIErrorHandler。のコードPopをコメントアウトできます。MyStackCurrentContext.IsEmptytrueProvideFaultIErrorHandler

したがって、私の質問も2部構成です。

IErrorHandler1)呼び出しまでコンテキストを維持する方法はありますか?

2）そうでない場合、コンテキストにアクセスできるグローバル規模でエラーをログに記録する別の方法はありますか?

.NET 4.5、Ninject 3.2、および DynamicProxy 3.2 を使用しています。

正直なところ、例外がどこでスローされたかを知っているだけでうれしいです。現在のクラスとメソッドで十分です。フルスタックは必要ありません。

編集:OperationContextを使用してに配置するとIExtension<>、 に到達するまで保持できIErrorHandlerます。ただし、メソッドがいつ終了するかはまだわからないため、どこで例外が発生したかはわかりません。