4

解決：

少しトレースすると、例外Tが正しくシリアル化されないという問題があったため、CommunicationExceptionがスローされていたことがわかりました。なぜなら、2層の深さで、匿名で型付けされたオブジェクトがあり、それはシリアル化できなかったからです。それを削除し、変更をバブリングすると、修正されたように見えます。その前に私がやったことは他にもありましたが、それが何であったかを一生思い出せません。それは設定で行われなかったということだけです。

トレースから次のようなメッセージを受け取っていました。

Type 'RebuiltWCFService.Requests.HelloWorldRequest' with data contract name 'HelloWorldRequest:http://schemas.datacontract.org/2004/07/RebuiltWCFService.Requests' is not expected. 
Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.

元の投稿

今日、私は答えを見つけることができないという一見奇妙な問題に遭遇しました！

問題：FaultExceptionをスローすると、サービスがCommunicationExceptionをスローします。例外をスローしない限り、これは行われません。

私のサービスでは、障害契約を適切に定義しています。

[OperationContract]
[FaultContract(typeof(Faults.HelloWorldFault))]
Responses.HelloWorldResponse HelloWorld(Requests.HelloWorldRequest parameter);

次に、エラー状態で、正しいタイプの例外をスローします。

if (_errors.Count() > 0)
{
    Faults.HelloWorldFault fault = new Faults.HelloWorldFault(_errors);
    throw new FaultException<Faults.HelloWorldFault>(fault, new FaultReason("There are one or more errors in the request. Check the 'Errors' property for more detaisl"));
}

そして、私はクライアント側でそれをキャッチしています：

try
{
    response = client.HelloWorld(new BasicService.HelloWorldRequest() { Number = 49 });
    client.Close();
    Console.WriteLine(String.Format("Response message: {0}, Response number: {1}", response.Message, response.Number));
}
catch (FaultException<BasicService.HelloWorldFault> ex)
{
    ...
}

それはすべて私には問題ないように思えます、そしてそれがうまくいくはずです。ただし、エラー句をテストする（フィールドの欠落などの不正なデータを提供する）とすぐに、すべてが死んでしまいます。FaultExceptionをスローすると、代わりにサービスはメッセージとともにCommunicationExceptionをスローします

An error occurred while receiving the HTTP response to http://localhost:8732/Design_Time_Addresses/RebuiltWCFService/Service1/. 
This could be due to the service endpoint binding not using the HTTP protocol. 
This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). 
See server logs for more details.

誰かがこれについていくつかの洞察を提供できますか？basicHttpバインディングを使用しており、wsHttpでも試しました。リクエストに応じて設定ファイルを投稿します。

4

3 に答える 3

7

FaultExceptionは、CommunicationExceptionの子です。したがって、コードで何が起こっているかには何の問題もありません。

処理中に例外が何であるかわからない場合は、通常、CommunicationExceptionとして報告されます。特定の例外を独自の方法で処理する場合は、次の構造を使用してください。

try
{ ... }
catch (FaultException<MyDemoException> me)
{ ... }
catch (FaultException fe)
{ ... }
catch (CommunicationException ce)
{ ... }
catch (Exception ex)
{ ... }

上記の構造では、ExceptionはCommunicationExceptionの親です。CommunicationExceptionは、FaultExceptionなどの親です。

System.Object 
  System.Exception
    System.SystemException
      System.ServiceModel.CommunicationException
        System.ServiceModel.FaultException
          System.ServiceModel.FaultException<TDetail>
            System.ServiceModel.Web.WebFaultException<T>
于 2011-07-01T13:26:31.790 に答える
0

みんなありがとう、あなたは私がより良い方法で問題を理解するのを手伝ってくれました。私の観察：私はリストMyDataを保持しました-シリアル化できなかった汎用/動的コレクションを保持するため、接続が閉じられ、通信例外が発生しました。

フォールトコントラクトからリストを削除し、フォールトスタイルをスローすると、通信例外ではなく、明らかにフォールトコントラクト例外が発生していました。

それがお役に立てば幸いです、HydTechie。

于 2013-12-02T10:53:01.747 に答える
0

間違った場所に1つ以上のブレークポイントがあったため、この問題が発生しました。Debug..Delete all Breakpoints（ ）を使用してすべてのブレークポイントを削除するCtrl-Alt-F9と、CommunicationException例外がすべて消え、正しいメッセージが返されるように置き換えられました。

はい、タイムアウトは60秒です。したがって、これは発生するはずがなかったため、おそらくVisualStudio2012の奇妙なアーティファクトでした。

于 2013-12-05T16:45:47.610 に答える