开发者

WCF : FaultContract(typeof(ExceptionDetail)) issue

开发者 https://www.devze.com 2022-12-24 11:14 出处:网络
I have put the attribute [FaultContract(typeof(ExceptionDetail))] for my operation contract. When I am trying to add the service to a client application, I get this error - \"Custom tool error: Failed

I have put the attribute [FaultContract(typeof(ExceptionDetail))] for my operation contract. When I am trying to add the service to a client application, I get this error - "Custom tool error: Failed to generate code for the service reference 'ServiceReference1'. Please check other error开发者_如何学Python and warning messages for details."

But when I comment out the FaultContract Attribute, I am able to add the wcf service reference th' my client app.


The point of having FaultContracts is to make it possible to first of all pass back SOAP faults from the service which will not break the communication channel between the server and the client (handling error conditions like .NET exceptions gracefully and interoperably), and secondly, using FaultContracts, your server than throw typed faults (FaultException<T>) and your client can catch those.

If you want or need to be really interoperable, you need to:

  • define all your FaultContract types as classes decorated with the [DataContract] attribute
  • catch all .NET exceptions on the server (using e.g. IErrorHandler interface) and turn them into interoperable SOAP faults

If you control both ends of the wire and both ends are .NET, then you can simplify this by one step: on the server, handle all .NET exceptions and turn them into e.g. FaultException<ArgumentOutOfRangeException>, that is, create a "fault of (whatever .NET exception)" and then on the client, catch those typed FaultException and handle them:

[FaultContract(typeof(ArgumentOutOfRangeException)]
[OperationContract]
public void CallService(.......)

and then in your implementation, use this:

try
{
    clientProxy.CallService();
}
catch(FaultException<ArgumentOutOfRangeException> ex)
{
   // handle the most specific exception first
}
catch(FaultException ex)
{
   // handle all other, unspecific server faults
}
catch(CommunicationException ex)
{
   // handle all other, client-proxy related WCF errors
}
catch(Exception ex)
{
   // handle anything else....
}


Remove that FaultContract, and instead configure includeExceptionDetailInFaults:

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Behavior">
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>


Use Service Trace Viewer tool from http://msdn.microsoft.com/en-us/library/ms732023.aspx, to view the activity trace .


I had the same problem few minutes ago. It was due to the absence of a default constructor. Also remember that all properties must have public get/set accessors.

0

精彩评论

暂无评论...
验证码 换一张
取 消