Home/ Questions/Q 6329523
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T17:41:00+00:00

It seems like I’ve been banging my head with custom faults in my Silverlight

  • 0

It seems like I’ve been banging my head with custom faults in my Silverlight WCF service forever so I will happily DO MY BEST TO BUY A BEER for anyone who can help me solve this!!!

After much pain I finally have my WCF service throwing custom errors (ParameterValidationFault) and using Fiddler I know that the service’s response contains my serialized fault object, but the HTTP response code is 500, not 200, so the client starts throwing exceptions rather than reading the response.

I know my SilverlightFaultBehavior class is supposed to take care of changing the response status code, but the breakpoints I set there are never being hit, so I’m hoping this is a simple web.config issue (web.config at end of post).

If this is relevant my web.config shows “the element ‘behavior’ has invalid child element ‘silverlightFaults’…”, in the section

  <endpointBehaviors>
    <behavior name="SilverlightFaultBehavior">
      <silverlightFaults/>
    </behavior>
  </endpointBehaviors>

but I thought this wasn’t a problem as I can view the service’s metadata without error. However now I’m thinking this is the missing link that’s preventing my status code from being changed on the way out. I have read that this error indicates a problem with the type attribute within my behaviorExtension element not exactly matching what .NET thinks it should be, but I have checked this a million times and the namespace and assembly name are definitely correct. I haven’t messed with the version, culture, or public key stuff.

Is there a simple way for .NET to tell me exactly what this type string should be (spaces, commas, and all)? I have viewed the dll’s properties in explorer but I’m still no closer.

Any other suggestions on where this might be coming from would be hugely appreciated.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name="silverlightFaults" type="my.namespace.SilverlightFaultBehavior, AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
      <endpointBehaviors>
        <behavior name="SilverlightFaultBehavior">
          <silverlightFaults/>
        </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <bindings>
      <customBinding>
        <binding name="my.namespace.IService.customBinding0">
          <binaryMessageEncoding />
          <httpTransport />
        </binding>
      </customBinding>
    </bindings>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    <services>
      <service name="my.namespace.IService">
        <endpoint address="" binding="customBinding" bindingConfiguration="my.namespace.IService.customBinding0" contract="my.namespace.IService" behaviorConfiguration="SilverlightFaultBehavior" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

My SilverlightFaultBehavior class starts like this and is a copy-paste of this MSDN post with a namespace change

namespace my.namespace
{
    public class SilverlightFaultBehavior : BehaviorExtensionElement, IEndpointBehavior
    {
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    OK so this problem has not been resolved but worked-around. I finally saw in this very useful post that I can have anonymous endpointBehaviors. The behaviour is now applied and custom faults are correctly (in a non-standard kind of way) returned as HTTP 200s. Making the behavior anonymous means it is applied to all endpoints, but as my service currently only needs a single endpoint this works for me.

    It truly sucks that I had all this grief after reading the friggin manual and implementing it word for word. In the end my config parse error “the element ‘behavior’ has invalid child element ‘silverlightFaults’…” was irrelevant, but a very smelly red-herring along the way as it very well could have been the cause (and still may be).

    In case anyone is wondering, I just drank the beer.

    • 0