問題タブ [faultexception]

System.ServiceModel.FaultExceptionWindows Phone アプリで次のメッセージが表示されます。この例外について少し調べたところ、SOAP 障害に関連していることがわかりました。特に例外が発生した場合は、soap 呼び出しを行っていないため、これは奇妙です。

ページ間を移動した後に発生するようで、アプリを使用しようとすると次第に悪化します.

2 つの Webclient 呼び出しがありますが、ほとんどの場合、それらはデータのローカル キャッシュによって回避されます (そのため、コメント アウトしてもアプリを使用できます) が、それでもこれらのエラーが発生します。

オンラインで有用なソースが見つからないようですので、誰かがこれとそれを回避する方法について知っていることを願っています. 例外を飲み込むことができたとしても、それは今日の助けになるでしょう。

これを入力しているので、分離ストレージにキャッシュしている xml データの xmlnamespace と関係があるのではないかと考えています。これが起こったことを聞いた人はいますか？

更新:
XML をロードして逆シリアル化しないと、FaultExceptions が発生しません。おそらく、名前空間を取り除くことができれば...

ワークフロー 4 で、別のサービスを呼び出そうとする try catch ブロックを設定しようとしています。このサービスは、特定の、一般的に型指定されたフォルト例外をいくつかスローする可能性があります。

FaultException<MySpecificFault>

トライキャッチでは、それぞれの個性に対応するキャッチを連発していきたいです。ただし、上記のように、特定のタイプの障害をキャッチしようとすると、常にブロックの最後にある一般的な FaultException に失敗します。

私が欠けているものはありますか？これはWF4で可能ですか？

Web サービス (WCF なし) に問題があります。

そのため、サーバー (Windows 2008 R2) に Web サービスを保存しています。XmlTextWritter で XML ファイルを作成する機能があります。サーバーのブラウザーで Web サービスを起動し、機能をテストすると、すべて正常に実行されます。しかし、クライアント アプリ (サーバーではなくコンピューター上の WPF) でこの関数を呼び出すと、次のエラーが発生します。

XmlTextWritter はファイルを作成する必要がありますが、見つからないと言われました。このエラーは、クライアント側を使用しているときに発生しました。

これは、変数「パス」が世界の名前（関数の文字列パラメーター）である私の関数GenerateXMLです：

サーバー側、すべての実行、およびクライアント側で、スクリプトがファイルを作成/検出できない理由を誰かが知っていますか?

私のサービスは、ビジネス ロジック全体が配置されている BusinessLogicLayer メソッドを呼び出すだけです。BL によって発生した例外を処理するためのベスト プラクティスは何ですか? (致命的な例外だけでなく、ユーザーが見つからないときに BL がスローする UserNotFoundException のような「論理的な」ApplicationExceptions も知りたいです)。

これらの例外を、クライアントが表示する FaultExceptions にどこで変換する必要がありますか?

BL からビジネス例外をスローし、それらをサービス呼び出しにキャッチして FaultException に変換し、クライアントに返す必要がありますか? または BL は、すでに「クライアントに優しい」FaultExceptions を発生させる必要がありますか?

前もって感謝します ：）

DuplexChannelFactory生成されたプロキシではなく、を使用してWCFクライアントチャネルを作成しています。

FaultException<MyFault>特定の方法については、サーバー側で既知のものをスローしています。必要に応じて、サービスインターフェイスをマークアップしました[FaultContract(typeof(MyFault))]。

クライアント側では、これをキャッチしFaultException<MyFault>てエラーを表示します。

これはすべて問題なく機能しますが、何らかの理由で、WCFはクライアントコードに制御を戻す前にサービス呼び出しを5回再試行しています。これにより、クライアントで顕著な遅延が発生しています。

デバッガーは、コードの次の行に進む前に、クライアントコードのサービス呼び出しで5回中断します。それに踏み込むことはできませんが、呼び出しスタックは、WCFの奥深くで例外がスローされていることを示しています。

サービス側のブレークポイントは1回だけ起動します。

制御が私に戻ったら、チャネルに障害は発生しません。

デバッガーの出力は次のことを示しています。

これは正常な動作ですか？予想される既知の障害を返すときに、WCFが再試行するのはなぜですか？

私は WCF を学んでおり、現在は障害の章に焦点を当てています。

私が理解しているように、サービスによってスローされた場合、WCF は FaultException 例外を少し異なる方法で処理します。

そのため、サービスからスローされるすべての例外を FaultException にラップすることをお勧めします。

設計に関しては、WCF が好むと思われる設計 (実際のロジックと「サービス」構成/ホスティング/サービスのような詳細との間の明確な分離) に関して、私にとっては少し直感に反するようです。

これは良い習慣ですか？または、使用すべき他のテクニックはありますか？

私はこのようにcustom FaultExceptionを使いたい

...

...

インターフェース

しかし、クライアントに到達すると、FaultException に変換されます

clint のカスタム フォールトをキャッチできますか? または、WCF が自動的にそれを FaultException に変換します。この問題を機能させるにはどうすればよいですか

ありがとう

現在、WCF バックエンドを使用して WPF アプリケーションに取り組んでいます。例外処理用にクライアント ロギング ソリューションとサーバー ロギング ソリューションを実装しましたが、それらはうまく機能しますが、多くの場合、ネットワーク上で情報を結び付けるのは困難です。サーバーで例外が発生した場合、例外トークンをネットワーク経由で返す方法が必要でした。これにより、例外をクライアントに記録できるようになります。そうすれば、クライアント エラーのトラブルシューティングを行っているときに、それをサーバーの例外と簡単に関連付けることができます。

私たちのアーキテクチャについてもう少し情報を提供したいと思います。それから私の問題を述べます。

私たちの WCF 実装は、サービス参照を設定するためのすぐに使える方法よりも少し堅牢です。クライアントに動的プロキシ生成を実装しました。クライアントとサーバーで共有される Web サービス インターフェイスを作成し、Castle.DynamicProxy.ProxyGenerator クラスと CreateInterfaceProxyWithoutTarget メソッドを使用してプロキシを作成することで、これを実現しました。さらに、CreateInterfaceProxyWithoutTarget メソッドを呼び出すときに、IInterceptor 実装を指定します。サーバーには、トレースと障害の動作に使用される 3 つの主要なクラスがあります。

FaultOperationInvoker (IOperationInvoker を実装): IOperationInvoker.Invoke を使用してサービス メソッドの呼び出しを試みます。フォールト例外タイプの場合は再スローし、例外の場合は、特定の詳細タイプを持つフォールト コントラクトがあるかどうかを判断しようとし、存在する場合はラップしてから、詳細情報を使用して新しいフォールト例外を発生させます。

FaultOperationBehavior (Implements IOperationBehavior) は、ディスパッチ操作の呼び出し元を上記の障害操作の呼び出し元にポイントします。

IServiceBehavior を実装する例外を処理するための ExceptionTraceBehavior (属性を継承、IServiceBehavior を実装)。クラス（FaultOperationBehavior）もあります

すべてのサービス インターフェイスには、具体的な実装があります。すべてのサービスは、ExceptionTrace 属性で装飾された基本サービス クラスも継承します。

さて、背景情報を踏まえて、ここに問題があります。すべてのサービス操作に詳細型 WCFServiceFaultDetail のエラー コントラクトを持たせたいのですが、すべてのサービス操作に FaultContract 属性を設定したくありません。ExceptionTraceBehavior でわかるように、障害コントラクトをプログラムで追加する方法を理解しました。これは、操作に障害を追加するのに最適です。通常の古い例外がオペレーション インボーカーでキャッチされると、適切なフォールト コントラクトがあることがわかり、新しい FaultExcption がスローされます。ただし、例外がクライアントにキャッチされると、catch (FaultException fe) コードではなく、catch (FaultExcection fe) コードに分類されます。

ただし、プログラムでフォールト コントラクトに追加するコードを削除すると、すべてのサービス操作を [FaultContract(typeof(WcfServiceFaultDetail))] で装飾すると、クライアントは期待どおりに例外をキャッチします。

私が把握できる唯一のことは、プロキシが WSDL やその他のメタデータからではなくインターフェイスから動的に生成されており、インターフェイスにフォルト コントラクトの装飾がないため、プログラムによるフォルト コントラクトが尊重されていないことです。

その考えを念頭に置いて、IInterceptor 実装にフォールト コントラクトを追加する方法を見つけようとしましたが、成功しませんでした。

したがって、誰かがすでにこれを行っており、詳細を提供できることを願っています。どんな助けでも大歓迎です。

WCF サービスに FaultException を実装しようとしています。いろいろな記事を参考にしました。ただし、クライアントで FaultExceptions がキャッチされることはないようです。私はこのようなコードを書きました、

サービス契約 -

サービスの実装 -

クライアント (aspx.cs ページ) -

サービス層は例外をスローしますが、クライアントは例外を受け取りません。次のような未処理の例外が発生しています。

基になる接続が閉じられました: 接続が予期せず閉じられました。

VS 2012 で .net 4.5 の Telerik OpenAccess で WCF Plain サービスを使用しようとしています。

私は telerik 開発者マニュアルを試し、サービスとクライアントを作成しました。

私が入れたサービスインターフェース IEntitiesModel に

メソッドの EntitiesModel.SVC では、最初の試行として簡単な構成を使用しました。

Consumer のユーザー コードに、例外のキャッチを追加しました。

問題は次のとおりです。

サービスが呼び出されるたびに、Visual Studio が "throw new FaultException" で停止し、FaultException がユーザーコードによって処理されなかったというエラー メッセージが表示されます。F5 を押し続けると、消費者のユーザーコードによっても例外がキャッチされます。

サービスで停止するのはなぜですか？

私の理解では、FaultException はサービスの消費者に渡されるべきものです。

FaultException を正しくスローするにはどうすればよいですか?