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

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

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

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

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

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

Как начать отлаживать эту проблему?

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

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

Это может быть связано с тем, что:

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

Посмотрите на class EndpointDispatcher для получения дополнительной информации по этому вопросу.

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

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

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

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

чтобы …

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

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

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

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

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

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

[ ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Например:

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

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

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

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

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

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

    https://example.org/v1/Service.svc http://example.org/ExampleWS/exampleMethod   ...   

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

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

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

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

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

     

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

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

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

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

В моей ситуации у меня был клиентский инструмент, который был первоначально разработан для службы 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)

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

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

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

Если вы вызываете метод 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+ "\""); } 

У меня была такая же ошибка при развертывании службы 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" 

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

Также это может быть полезно для тех, кто делает это путем кодирования. Вам нужно добавить 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

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

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

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

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

**Ошибка**

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для тех, кто использует 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) }) 
Давайте будем гением компьютера.