Несовпадение ContractFilter в исключении EndpointDispatcher

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Новое созданное им местоположение получило нестандартное имя в качестве первогочасть URL после хоста:

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

Ваш клиент не обновлялся. Поэтому обновите ваши сервисы с помощью веб-сервиса и затем пересоберите ваш проект

Answer 10

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

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

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