Подтвердить что ты не робот

Несоответствие ContractFilter при исключении EndpointDispatcher

У меня есть следующий сценарий, который я пытаюсь проверить для:

  • Общий WSDL
  • Конечная точка WCF, которая реализует объекты на основе WSDL и размещается в IIS.
  • Клиентское приложение, использующее прокси-сервер, основанный на WSDL для создания запросов.

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

{ "Сообщение с действием" http://IMyService/CreateContainer 'не может быть обработано в приемнике из-за несоответствия ContractFilter в EndpointDispatcher. Это может быть из-за несоответствия контракта (несоответствие действий между отправителем и получателем) или несоответствия привязки/безопасности между отправителем и получателем. Убедитесь, что отправитель и получатель имеют один и тот же контракт и одну и ту же привязку (включая требования безопасности, например сообщение, транспорт, нет). "}

Я начал использовать MS Service Trace Viewer, но не уверен, где искать. Рассматривая классы в клиенте и конечной точке, они выглядят одинаково.

Как начать отладку этой проблемы?

Каковы возможные причины этого исключения?

4b9b3361

Ответ 1

"Несоответствие ContractFilter в EndpointDispatcher" означает, что получатель не смог обработать сообщение, поскольку оно не соответствовало ни одному из контрактов, настроенных получателем для конечной точки, получившей сообщение.

Это может быть потому что:

  • У вас разные контракты между клиентом и отправителем.
  • Вы используете другую привязку между клиентом и отправителем.
  • Параметры безопасности сообщений не согласованы между клиентом и отправителем.

Взгляните на класс EndpointDispatcher для получения дополнительной информации по этому вопросу.

Так:

Убедитесь, что ваши клиентские и серверные контракты совпадают.

  • Если вы создали свой клиент из WSDL, обновлен ли WSDL?
  • Если вы недавно внесли изменения в контракт, развернули ли вы правильную версию клиента и сервера?
  • Если вы вручную создали классы клиентских контрактов, убедитесь, что пространства имен, имена элементов и имена действий соответствуют ожидаемым сервером.

Проверьте, совпадают ли привязки между клиентом и сервером.

  • Если вы используете файл .config для управления своими конечными точками, убедитесь, что элементы привязки совпадают.

Убедитесь, что настройки безопасности одинаковы между клиентом и сервером.

  • Если вы используете файл .config для управления своими конечными точками, убедитесь, что элементы безопасности совпадают.

Ответ 2

У меня была эта ошибка, и это было вызвано контрактом recevier, не реализующим вызываемый метод. В основном, кто-то не развернул последнюю версию службы WCF на хост-сервере.

Ответ 3

У меня возникла эта проблема и я обнаружил, что в моем генераторе прокси, который я скопировал с другой службы, я забыл изменить имя службы.

Я изменил это...

Return New Service1DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service1Data.svc"))

чтобы...

Return New Service2DataClient(binding, New EndpointAddress(My.Settings.WCFServiceURL & "/Service2Data.svc"))

Это была простая ошибка кода, но почти невозможно отладить. Надеюсь, это экономит время.

Ответ 4

Вы также получите это, если попытаетесь подключиться к неправильному URL;)

У меня есть две конечные точки и службы, определенные в моей системе, с похожими именами.

Получил эту точную ошибку, когда URL-адреса в какой-то момент менялись на моем клиенте. На самом деле поцарапал голову, пока, наконец, не понял эту тупую ошибку.

Ответ 5

Я решил это, добавив следующее к моей реализации контракта:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Например:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class MyUploadService : IMyUploadService
{

}

Ответ 6

Для клиента Java, вызывающего конечную точку .net. Это было вызвано несогласованностью заголовка "Мыло".

Content-Type: application/soap+xml;charset=UTF-8;action="http://example.org/ExampleWS/exampleMethod"

Вышеупомянутый HTTP-заголовок или следующий тег XML должны соответствовать действию/методу, который вы пытаетесь вызвать.

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/" xmlns:gen="http://schemas.datacontract.org/2004/07/GenesysOnline.WCFServices">
   <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsa:To>https://example.org/v1/Service.svc</wsa:To>
      <wsa:Action>http://example.org/ExampleWS/exampleMethod</wsa:Action>
   </soap:Header>
   <soap:Body>
    ...
   </soap:Body>
</soap:Envelope>

Ответ 7

Я получил это после того, как скопировал файл svc и переименовал его. Хотя имя файла и файл svc.cs были правильно переименованы, разметка все еще ссылалась на исходный файл.

Чтобы исправить это, щелкните правой кнопкой мыши на скопированном файле svc и выберите Просмотр разметки и измените ссылку на службу.

Ответ 8

У меня была такая же проблема. Проблема заключалась в том, что я скопировал код из другой службы в качестве отправной точки и не изменил класс службы в файле .svc

Откройте файл .svc и убедитесь, что атрибут Service правильный.

 <%@ ServiceHost Language="C#" Debug="true" Service="SME.WCF.ApplicationServices.ReportRenderer" CodeBehind="ReportRenderer.svc.cs" %>

Ответ 9

Как упоминалось в других ответах, таких как @chinto, это происходит, когда элемент заголовка SOAP: Action не соответствует конечной точке.

Вы можете найти правильный URI для использования, посмотрев сервер WSDL. Вы увидите элемент операции с дочерним элементом, который имеет атрибут "Действие". Это то, что должно быть в вашем SOAP: Action на клиентском запросе.

<wsdl:operation name="MethodName">
<wsdl:input wsaw:Action="http://tempuri.org/IInterface/MethodName" message="tns:IInterface_MethodName_InputMessage"/>
<wsdl:output wsaw:Action="http://tempuri.org/IInterface/MethodNameResponse" message="tns:IInterface_MethodName_OutputMessage"/>
</wsdl:operation>

Ответ 10

Ошибка говорит о несоответствии, предполагая, что у вас есть общий контракт на основе того же WSDL, тогда несоответствие находится в конфигурации.

Например, клиент использует nettcpip, и сервер настроен на использование базового http.

Ответ 11

У меня была аналогичная ошибка. Это может быть связано с тем, что вы изменили некоторые параметры контракта в своем конфигурационном файле после того, как он был переопределен в ваш проект. Решение. Обновите ссылку webservice на проекте VSstudio или создайте новый прокси-сервер, используя svcutil.exe.

Ответ 12

Я потратил дни на поиск ответа, и я нашел его, но не в этой теме. Я очень новичок в WCF и С#, поэтому для некоторых ответ может быть очевиден.

В моей ситуации у меня был клиентский инструмент, который был первоначально разработан для службы ASMX, и для меня он возвращал то же сообщение об ошибке.

После выполнения всех рекомендаций я нашел этот сайт:

http://myshittycode.com/2013/10/01/the-message-with-action-cannot-be-processed-at-the-receiver-due-to-a-contractfilter-mismatch-at-the-endpointdispatcher/

Он поставил меня на правильный путь. В частности, "soap: operation" - WCF добавлял ServiceName в пространство имен:

ожидаемый клиент Http://TEST.COM/Login, но WCF отправлен Http://TEST.COM/IService1/Login. Решение состоит в том, чтобы добавить настройку к [OperationContract] следующим образом:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Игнорировать пробелы в Http)

Ответ 13

Это может быть по двум причинам:

  • service ref устарел, щелкните правой кнопкой мыши службу ref n, чтобы обновить его.

  • контракт, который вы внедрили, может отличаться от того, какой клиент есть. Сравните и клиентский контракт службы n, зафиксируйте контракты несоответствие.

Ответ 14

Если вы вызываете метод WCF, вы должны включить интерфейс в заголовок.

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(Url);
if (Url.Contains(".svc"))
{
    isWCFService = true;
    req.Headers.Add("SOAPAction", "http://tempuri.org/WCF_INterface/GetAPIKeys");
}
else 
{
    req.Headers.Add("SOAPAction", "\"http://tempuri.org/" + asmxMethodName+ "\"");
}

Ответ 15

Также это может быть полезно для тех, кто делает это путем кодирования. Вам нужно добавить WebHttpBehavior() в вашу добавленную конечную точку обслуживания. Что-то вроде:

restHost.AddServiceEndpoint(typeof(IRestInterface), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior()); 

Взгляните на: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Ответ 16

Глупо, но я забыл добавить [OperationContract] к моему сервисному интерфейсу (тот, который помечен [ServiceContract]), а затем вы также получите эту ошибку.

Ответ 17

Ваш клиент не был обновлен. Так что обновите свои службы с веб-службы, а затем перестройте свой проект

Ответ 18

Эта ошибка обычно возникает, если код не развернут должным образом.

В моем случае у меня есть две службы ServiceA и ServiceB. Я обнаружил, что файлы ServiceB не были развернуты должным образом. Из-за чего, когда ServiceA вызывал ServiceB внутренне, он приводил ниже ошибки.

**Error**

Убедитесь, что файлы и ссылки развернуты правильно.

Ответ 19

У меня тоже была эта проблема. Оказалось, что это было вызвано сериализатором контрактов на сервере. Он не смог вернуть мой контрактный объект данных , потому что некоторые из его данных были только свойствами readonly.

Убедитесь, что у ваших объектов есть сеттеры для свойств, предназначенных для сериализации.

Ответ 20

Как ни странно, мы работали над этой ошибкой, используя ту же оболочку, что и имя пути и OperationContract. По-видимому, это было чувствительно к регистру. Если кто-нибудь знает, почему, прокомментируйте. Спасибо!

Ответ 21

Итак, мое дело было следующим. Я не использовал прокси для взаимодействия клиент-сервер, я использовал ChannelFactory (поэтому все советы по обновлению ссылки на обслуживание были для меня бессмысленными).

Служба была размещена в IIS и по какой-то причине она имела неправильные ссылки в папке bin. Рекомпиляция проекта просто не привела к появлению новых DLL в этой папке.

Итак, я просто удалил все вещи оттуда и добавил ссылку на сервис в том же решении, а затем перекомпилировал и теперь все работает.

Ответ 22

У меня была такая же ошибка при развертывании службы WCF, проблема была связана с другой службой, развернутой с другим контрактом с тем же портом.

Решение

Я использовал разные порты в файле web.config, и проблема исчезла.

Сервис 1

contract="Service.WCF.Contracts.IBusiness1" 
baseAddress="net.tcp://local:5244/ServiceBusiness" 

Сервис 2

contract="Service.WCF.Contracts.IBusiness2"
baseAddress="net.tcp://local:5243/ServiceBusiness"

Кроме того, я столкнулся с этой ситуацией, используя другой порт для одного и того же адреса между сервисом и потребителем.

Ответ 23

Моя проблема оказалась чем-то редким, но я все равно упомянул.

Я столкнулся с проблемой развертывания в нашей среде разработки. На этой машине наш создатель создал две папки (развернуто два приложения). Старая версия и новая текущая версия. Итак, если у вас нет двух версий вашего приложения на веб-сервере, это не относится к вам.

Новое место, которое он создал, было нестандартным именем в качестве первой части URL-адреса после хоста:

net.tcp://dev.umbrellacorp.com/ DifferentFolderName /MyProvider

На моей локальной машине мой клиент указывал на стандартное имя папки, которое было настроено во всех средах (кроме разработки), включая мою локальную среду.

net.tcp://dev.umbrellacorp.com/ AppServices /MyProvider

Когда я сдул и заменил web.config на разработку своей локальной копией, часть URL-адреса, которая должна была быть специальной, была удалена со стандартной частью, так что клиент на dev указал на старый приложение.

Старое приложение имело старый контракт и не понимало запрос и выбросило эту ошибку.

Ответ 24

У меня была эта ошибка, потому что у меня есть старая версия DLL в GAC моего сервера. Поэтому убедитесь, что все правильно указано и что сборка /GAC обновлена ​​с хорошей dll.

Ответ 25

У меня была эта проблема с моим тестовым сервером, потому что я запускал две копии одного и того же wcf в одном и том же пуле приложений. Для меня решили создать отдельные пулы для каждой версии на моем wcf и перезапустить IIS после этого.

Ответ 26

Для тех, кто использует NodeJS с Аксиос, чтобы сделать запросы SOAP вы должны включать в себя SOAPAction header. Посмотрите пример ниже:

axios.post('https://wscredhomosocinalparceria.facilinformatica.com.br/WCF/Soap/Emprestimo.svc?wsdl',
           xmls,
  {headers:
  {
    'Content-Type': 'text/xml',
    SOAPAction: 'http://schemas.facilinformatica.com.br/Facil.Credito.WsCred/IEmprestimo/CalcularPrevisaoDeParcelas'}
  }).then(res => {
    console.log(res)
  }).catch(err => {
    console.log(err.response.data)
  })