WCF を使用して一連のサービスを開発しています。このアプリケーションは、Castle Windsor で依存性注入を行っています。IErrorHandler属性を介してサービスに追加される実装を追加しました。これまでのところ、すべてが機能しています。(呼び出されたクラスのIErrorHandlerオブジェクトFaultHandlerは適切に適用され、呼び出されています。

今、ロギングを追加しています。Castle Windsor は、ロガー オブジェクト (のインスタンス) を注入するように設定されていますIOurLogger。これは機能しています。FaultHandlerしかし、ロガーに追加しようとするとnull になります。

のコードは次のFaultHandlerようになります。

が呼び出されたloggerときに nullであるため、これは独自の例外をスローします。HandleError()

ロガーはサービス自体に正常に挿入されており、そこで使用できますが、何らかの理由でFaultHandler.

Update: Here is the relevant part of the Windsor configuration file (edited to protect the innocent):

すべての操作の戻り値の型が OperationStatus である WCF サービスがあります。

すべての例外をキャッチする ErrorHandler を作成してから、Success プロパティを false に設定し、StatusReason を「INTERNAL SERROR」に設定して ServiceReponse クラスのクライアント インスタンスに返すようにしたいと考えています。

今のところ、IErrorHandler を実装する独自のクラスがありますが、FaultContract を使用したくありません。StatusReason 型の通常のクライアント オブジェクトに戻りたいだけです。これはできますか？

WCF を使用して Web サービスを実装しています。この Web サービスには、各サービスのヘルス モニターとして「ping」機能が必要です。この機能は IDispatchMessageInspector を使用して実装されており、サービスのエンドポイントごとに構成されています。これは、「ping」を実際のサービス コードにできるだけ近づけるというビジネス上の要件によるものです。同時に、これを各サービス実装のコードに結び付けたくはありませんでした。IDispatchMessageInspector が適しているようです。

このサービスは、Request-Reply MEP を使用します。各要求メッセージには、必要な処理を指定する要素が含まれています。次に、サービスはこの値を使用して、メッセージ内のデータを処理する方法を決定します。同じ要素を使用して、リクエスト メッセージを「ハートビート」チェックとして定義します。

「ping」メッセージ インスペクターは、AfterReceiveRequest() メソッドで要求メッセージを前処理し、要求が「ハートビート」であると判断した場合、正しい応答を生成し、それを BeforeSendReply() メソッドに渡します。 AfterReceiveRequest() から返される相関オブジェクト。参照による AfterReceiveRequest() の要求メッセージ パラメータは、サービス実装コードによってメッセージが処理されないように null に設定されます。

リクエスト メッセージを null に設定する手法は、私が覚えていない、または URL を見つけることができない Web サイトまたはブログで見つかりました。この手法は単独でうまく機能し、「ハートビート」リクエストの場合にサービス実装コードが実行されるのを防ぐことができます。

残念ながら、メッセージ インスペクターで要求メッセージを null に設定すると、WCF ランタイムは常に NullReferenceException をスローします。スタック トレースから、ランタイムが引き続きメッセージ オブジェクト (「Ping」メッセージ インスペクターを通過した後は null になる) をディスパッチャーに渡し、ディスパッチャーが null メッセージ オブジェクトを逆シリアル化しようとすると、NullReferenceException が発生することがわかりました。

ただし、私のシステムは IErrorHandler も実装して、サービスで未処理の例外をキャッチしてログに記録します。これは、「ハートビート」リクエストが成功するたびに NullReferenceException のログ エントリが生成され、「ハートビート」が 1 分おきに発生する可能性があることを意味します。

質問 ：

「Ping」がリクエストをnullに設定することによってサービス実装コードの実行を妨げているときにスローされる「役に立たない」NullReferenceExceptionのロギングを防ぐにはどうすればよいですか。

よろしくお願いします。
~hg

IErrorHandlerを読んでいて、構成ルートに行きたいと思っています。それで、私はそれを実装する試みで以下を読みました。

MSDN

タイプの定義についてのKeyvanNayyeriブログ

ロリープリムローズブログ

これは基本的に、IErrorHandlerとIServiceBehaviourを継承するクラスにラップされたmsdnの例です...次に、BehaviourExtensionElementから継承するExtension要素にラップされ、要素をweb.configに追加できるようになります。私は何を逃しましたか？

コンパイルする必要があります。修正したさまざまなエラーから、WCFが実際にエラーハンドラーを読み込んでいるようです。私の問題は、エラーハンドラーで処理するためにスローしている例外が、それに渡された例外を取得しないことです。

私のサービス実装は、ArgumentOutOfRangeExceptionをスローする別のクラスのメソッドを呼び出すだけですが、この例外がハンドラーによって処理されることはありません。

私のweb.config

サービス契約

ErrorHandlerクラス

そして、行動拡張要素

設定ファイルを介してそれを機能させることに運がなかったので、クラスレベルの属性を介してそれを支配するより堅牢なルートに行くことを試みることにしました。これを機能させることができれば、多くのコードを繰り返すことなく、サービスレイヤーのFaultsで例外をラップするための優れた方法であることは明らかです。

ただし、属性を定義するコードが完全にコンパイルされ、IDEによって認識されているにもかかわらず、属性内のコードが実行されることはありません。私はこれを解決することに関して読むべきものを使い果たしました-ただ処理されてただ投げられる例外。

また、機能を変更せずにこの問題を単純化するために、rorysサイトにあるCodePlexで見つかったコードの一部を借用して切り刻みました（冗長なオーバーロードを削除しました）

これは私を狂わせています...助けてください！：D

RoryPrimrose-属性の実装

ロリープリムローズ-IErrorHandlerImplementation

コード：

サービスインターフェイスと実装

KnowErrorHandlerの実装：

属性の定義-問題がここにあるのではないかと疑ってください。私はそれが私がこのコードをどのように使用しているかにあるとかなり確信しています。

他のバインディングの中でも、JSON の入力/結果に WebHttpBinding を使用する WCF サービスがあります。

何か問題が発生したときに StatusCode を 400 に設定し、JSON のわかりやすいメッセージを返すことができるように、カスタム IErrorHandler 実装を作成しました。これは、どこにでもあるストレートな実装です (こちらで説明されている良い方法です)。

私の問題は、Visual Studio Web Development Server (Cassini) を使用してローカルでテストすると、完全に動作することです。ただし、テスト サーバー (IIS およびその他すべての標準構成を備えた Windows 2008) に展開すると、機能しません。

それを呼び出して Firebug でデバッグすると、リターンとして HttpStatusCode 200 が返され、応答テキストは返されません。Fiddler を使用すると、HttpStatusCode 504 が返され、まったく返されません。ただし、私が予想した動作 (およびローカルで発生する動作) は、responseText が設定された ajax 呼び出しのエラー コールバックへの呼び出しです。

リモートでデバッグしましたが、すべて問題ないようです。実行パイプラインに問題はなく、すべてのクラスがローカルと同じように呼び出されますが、機能しません。

助言がありますか？これを理解するためのオプションはほとんどありません。

どうもありがとう！

WCF を使用して、MSMQ のメッセージに応答するサービスがあります。メッセージが適切にフォーマットされていれば、正常に機能し、満足しています。メッセージが別のサービスを対象としていて、アクションが異なる場合、メッセージはキューに残り、ログ エントリを取得して修正し、満足しています。

しかし、メッセージに適切なアクションが含まれていても、サーバーによって逆シリアル化できない XML 要素が含まれている場合、メッセージはキューから消え、ログ エントリが取得されず、何が起こったのかほとんどわかりません。私たちは幸せではありません。

IErrorHandler を追加してみました。Faulted イベント ハンドラーを追加しようとしました。私にできることは、WCF に組み込まれている診断ログを使用することだけです。独自のロガーまたはエラー ハンドラーを使用して、コードでこのようなエラーに応答する方法はありますか?

私のキューはたまたまトランザクションですが、この問題に違いはないようです。これは、Windows Server 2003 上の MSMQ バージョン 3.0 で発生します。

このソース コードは問題を示しています。

私のサービスメソッドはでマークされており、サービスにPrincipalPermissionAttributeカスタムIErrorHandler実装がアタッチされています。着信要求にメソッドを実行する権限がない場合、メソッドSystem.Security.SecurityExceptionがスローされます。IErrorHandler.ProvideFault()次にトリガーされ、特別な障害を提供したいと思います。ただし、errorパラメータは元の例外ではなく、型指定されていませんFaultException。さらに、error.InnerException構成に次の設定があるにもかかわらず、はnullです。

なんで？どうすれば目的の動作を実現できますか？

WCF サービスから FaultException が返された場合、チャネルを閉じるのではなく、チャネルを中止する必要があります。私のクライアントとサービスはどちらもこのアプローチで問題なく動作しますが、サービスに IErrorHandler を実装して例外をログに記録した後、クライアントで Abort を呼び出すとサービスがログに記録されることがわかります。

System.ServiceModel.CommunicationException: ソケット接続が中止されました...

この情報でサービス ログを汚したくないので、サービス関連のエラーのみをログに記録したいと考えています。CommunicationExceptions のログ記録を停止できることは明らかですが、私のサービスは他のサービスの WCF クライアントでもあり、これらのサービスによって発生した CommunicationExceptions はログに記録する必要があります。

これをやめさせるにはどうすればよいですか？

log4netを使用して例外をログに記録するwcfサービスにエラー処理動作を実装しようとしています

次に、この動作を使用するサービスを実装します。サービス内でILog変数を宣言すると、これは正常に機能します

ただし、ILog変数が宣言されていない場合、ロギングは機能しなくなります。

理想的には、特にビヘイビアーですでに宣言されている場合は、作成するすべてのサービスでILog変数を宣言する必要はありません。

誰かがa）これが振る舞いとサービスの両方で宣言されなければならない理由を説明してもらえますか？b）二重宣言を回避する方法またはc）wcfにログインするためのより良い方法。