Несоответствие ContractFilter при исключении EndpointDispatcher
У меня есть следующий сценарий, который я пытаюсь проверить для:
- Общий WSDL
- Конечная точка WCF, которая реализует объекты на основе WSDL и размещается в IIS.
- Клиентское приложение, использующее прокси-сервер, основанный на WSDL для создания запросов.
Когда я делаю вызов веб-службы от клиента к конечной точке службы, я получаю следующее исключение:
{ "Сообщение с действием" http://IMyService/CreateContainer 'не может быть обработано в приемнике из-за несоответствия ContractFilter в EndpointDispatcher. Это может быть из-за несоответствия контракта (несоответствие действий между отправителем и получателем) или несоответствия привязки/безопасности между отправителем и получателем. Убедитесь, что отправитель и получатель имеют один и тот же контракт и одну и ту же привязку (включая требования безопасности, например сообщение, транспорт, нет). "}
Я начал использовать MS Service Trace Viewer, но не уверен, где искать. Рассматривая классы в клиенте и конечной точке, они выглядят одинаково.
Как начать отладку этой проблемы?
Каковы возможные причины этого исключения?
Ответы
Ответ 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)
})