WCF服务用FaultException抛错，客户端收HTML页面而非纯错误信息求助

Hey there, let's sort out this WCF error response mess for you—no more parsing HTML with JavaScript, promise! The core issue here is that ASP.NET's default error handling is overriding WCF's intended FaultException response, dumping that messy HTML page with screenshots instead. Here's how to fix it properly:

1. Tell ASP.NET to Leave Your WCF Service Alone #

ASP.NET's custom error system can hijack error responses for WCF endpoints. In your web.config, you need to either disable custom errors for your service specifically, or adjust the global settings to skip it:

<system.web>
  <customErrors mode="RemoteOnly" redirectMode="ResponseRewrite">
    <!-- Your existing custom error rules here -->
    <error statusCode="500" redirect="~/Error.aspx"/>
    
    <!-- Add this block to exclude your WCF service from ASP.NET error handling -->
    <location path="YourService.svc">
      <system.web>
        <customErrors mode="Off"/>
      </system.web>
    </location>
  </customErrors>
</system.web>

This location block tells ASP.NET not to redirect or replace error responses for your WCF endpoint, letting WCF handle fault messages as intended.

2. Configure WCF Service Behavior for Clean Faults #

Next, make sure your WCF service is set up to return proper SOAP faults instead of falling back to ASP.NET errors. In your web.config's WCF section:

<system.serviceModel>
  <behaviors>
    <serviceBehaviors>
      <behavior name="YourServiceBehavior">
        <!-- For production, keep this FALSE (it exposes sensitive debug info) -->
        <!-- For testing, set to TRUE to verify your faults are being sent correctly -->
        <serviceDebug includeExceptionDetailInFaults="false"/>
        <serviceMetadata httpGetEnabled="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
  <!-- Your bindings and endpoint definitions go here -->
</system.serviceModel>

The serviceDebug setting controls whether internal exception details are included in faults—keep it off in production to avoid leaking sensitive data.

3. Throw Strongly-Typed FaultExceptions #

To ensure WCF sends a clean, serializable error (not HTML), use FaultException<T> where T is a data contract defining your error details. This lets you package exactly the info you want clients to receive:

// First, define a data contract for your error details
[DataContract]
public class ServiceFaultDetails
{
    [DataMember]
    public string ErrorMessage { get; set; }
    
    [DataMember]
    public int ErrorCode { get; set; }
}

// In your service operation
public void YourServiceMethod()
{
    try
    {
        // Your business logic here
    }
    catch (Exception ex)
    {
        // Log the full exception internally (don't send this to clients!)
        // Then throw a strongly-typed fault with safe, intended details
        var faultDetails = new ServiceFaultDetails
        {
            ErrorMessage = "Failed to process your request. Please try again.",
            ErrorCode = 1001
        };
        
        throw new FaultException<ServiceFaultDetails>(faultDetails, "Operation failed");
    }
}

This ensures WCF serializes the error as a proper SOAP fault, not an ASP.NET HTML error page.

4. Handle Faults Cleanly on the Client #

On the client side, catch the strongly-typed fault directly—no more parsing HTML! You can access the error details directly from the fault:

try
{
    using (var serviceClient = new YourServiceClient())
    {
        serviceClient.YourServiceMethod();
    }
}
catch (FaultException<ServiceFaultDetails> faultEx)
{
    string userFriendlyMsg = faultEx.Detail.ErrorMessage;
    int errorCode = faultEx.Detail.ErrorCode;
    
    // Handle the error with clean, structured data
    Console.WriteLine($"Error {errorCode}: {userFriendlyMsg}");
}

By following these steps, your WCF service will return only the error details you specify, no more messy HTML to scrape with JavaScript. Problem solved!

内容的提问来源于stack exchange，提问作者Ramin Ahmadi