Служба WCF Silverlight возвращает пользовательскую ошибку, но в качестве ответа HTTP 500, а не 200


Похоже, что я уже целую вечность бьюсь головой о нестандартные ошибки в моем сервисе Silverlight WCF, поэтому я с радостью сделаю все возможное, чтобы купить пиво для всех, кто может помочь мне решить эту проблему!!!

После долгих мучений у меня, наконец, есть моя служба WCF, выбрасывающая пользовательские ошибки (ParameterValidationFault) и с помощью Fiddler я знаю, что ответ службы содержит мой сериализованный объект ошибки, но код ответа HTTP равен 500, а не 200, поэтому клиент начинает выбрасывать исключения, а не читать ответ.

Я знаю, что мой класс SilverlightFaultBehavior должен заботиться об изменении кода состояния ответа, но точки останова, которые я там устанавливаю, никогда не попадают, поэтому я надеюсь, что это простая сеть.проблема конфигурации (web.config в конце поста).

Если это имеет отношение к моей паутине.конфиг показывает "поведение элемента 'имеет недопустимый дочерний элемент 'silverlightFaults'...", в разделе

  <endpointBehaviors>
    <behavior name="SilverlightFaultBehavior">
      <silverlightFaults/>
    </behavior>
  </endpointBehaviors>
Но я думал, что это не проблема, так как я могу просматривать метаданные сервиса без ошибок. Однако теперь я ... думая, что это недостающее звено, которое мешает изменить мой код статуса на выходе. Я читал, что эта ошибка указывает на проблему с атрибутом type в моем элементе behaviorExtension, не совсем совпадающим с тем, что .NET считает, что это должно быть, но я проверил это миллион раз, и пространство имен и имя сборки определенно правильные. Я не связывался с версией, культурой или открытым ключом.

Есть ли простой способ для .NET, чтобы сказать мне, что именно этот тип строки должно быть (пробелы, запятые и все)? Я просмотрел свойства библиотеки dll в проводнике, но я все еще не ближе.

Любые другие предложения о том, откуда это может исходить, будут чрезвычайно оценены.
<?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>

Мой класс SilverlightFaultBehavior начинается так и является копипастом этого сообщения MSDN с изменением пространства имен

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

1 ответ:

Итак, эта проблема не была решена, но была обойдена. Я, наконец, увидел в этой очень полезной записи , что я могу иметь анонимные endpointBehavior s. поведение теперь применяется, и пользовательские ошибки правильно (нестандартным способом) возвращаются как HTTP 200s. делая поведение анонимным, это означает, что оно применяется ко всем конечным точкам, но поскольку моей службе в настоящее время нужна только одна конечная точка, это работает для меня.

Это действительно отстой, что у меня было все это горе после прочтения чертова руководства и реализуя его слово в слово. В конце концов моя конфигурация разбирает ошибку "элемент' behavior 'имеет недопустимый дочерний элемент 'silverlightFaults'..."не имеет значения, но очень вонючий отвлекающий маневр на этом пути, поскольку он очень хорошо мог быть причиной (и все еще может быть).

На случай, если кому-то интересно, я просто выпил пиво.