WCF существует и частично работает, но для некоторых вызовов возвращает «нет прослушивания конечной точки - (404) не найден». - PullRequest
12 голосов
/ 14 июля 2011

У нас есть сервис, который работает с небольшими или большими наборами данных (генерация документов), и он отлично работает для некоторых вызовов, но для некоторых конкретных запросов (точно такой же метод, разные аргументы) он просто возвращает:

System.ServiceModel.EndpointNotFoundException: не было конечной точки, прослушивающей http://localhost:8010/MyService/MyService.svc, которая могла бы принять сообщение.Это часто вызвано неправильным адресом или действием SOAP.Смотрите InnerException, если имеется, для более подробной информации.---> System.Net.WebException: удаленный сервер возвратил ошибку: (404) Not Found.

Обратите внимание, что служба работает , документы создаются, но какЯ сказал, что не все из них ... (и службу можно открыть из браузера)

Я включил трассировку (system.diagnostics) в web.config и не получил никакой дополнительной информации в svclog.

Привязка (wsHttp) настроена следующим образом:

    <binding name="wsHttpWithTrans" transactionFlow="True" messageEncoding="Mtom"  maxReceivedMessageSize="65536000" maxBufferPoolSize="124288000">
      <readerQuotas maxDepth="32" maxStringContentLength="819200" maxArrayLength="16384000" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
        <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" />
      </security>
    </binding>

, а также:

<configuration>
  <system.web>
    <httpRuntime maxRequestLength="124288000" />
  </system.web>
</configuration>

Я считаю, что сообщение должно находиться в пределах maxReceivedMessageSize, идругие атрибуты.

В настоящее время я с подозрением отношусь к размеру сообщения, но просто не могу быть уверен - у вас есть идеи, как я могу отладить это дальше?

Ответы [ 4 ]

22 голосов
/ 21 июля 2011

Я обнаружил, что что-то не так, используя инструкции для Устранение неполадок с ошибочными запросами при использовании трассировки в IIS 7 (кстати, очень крутые вещи)

Там я увидел, что ошибка на самом деле была 404.13 , что легко привело меня к тому, что действительно неправильно: Слишком большая длина контента .

В конце концов, решение было добавить это в веб-конфигурацию:

<configuration>
...
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="204800000" />
      </requestFiltering>
    </security>
  </system.webServer>  
</configuration>

, а также убедитесь, что веб-сайт по умолчанию не переопределяет его, используя:

"% WINDIR% \ System32 \ inetsrv \ appcmd.exe" list config "Веб по умолчаниюсайт "-секция: requestFiltering

3 голосов
/ 13 ноября 2012

Я обнаружил в дополнение к maxAllowedContentLength, maxRequestLength на стороне сервера в вашей конфигурации WCF также необходимо увеличить. Я обнаружил, что оба значения должны были быть увеличены, чтобы исключение было разрешено. В .config для серверной части службы WCF обязательно добавьте следующее:

<system.web>
  <!--Increase 'maxRequestLength' to needed value: 100mb (value is in kilobytes)-->
  <httpRuntime maxRequestLength="102400"/>
</system.web>
0 голосов
/ 08 февраля 2016

Проверьте атрибут имени элемента службы в web.config:

<configuration>
    <system.serviceModel>
        <services>
            <service name="...">

Имя службы должно содержать правильное пространство имен + имя класса. Вы можете найти это в коде de или в разметке файла .svc (или открыть файл .svc с помощью блокнота) для атрибута Service = "...".

0 голосов
/ 14 июля 2011

Если вы с подозрением относитесь к содержанию и / или длине сообщения, вы можете попытаться перехватить вызовы, используя что-то вроде Fiddler - что должно успокоить вас в этих вопросах.

...