Niezgodność ContractFilter w wyjątku EndpointDispatcher

Miałem ten błąd i był on spowodowany przez kontrakt receviera nie implementujący wywoływanej metody. Zasadniczo, ktoś nie wdrożył ostatniej wersji usługi WCF na serwerze hosta.

Otrzymasz również to, jeśli spróbujesz połączyć się z niewłaściwym adresem URL ;)

Mam dwa punkty końcowe i usługi zdefiniowane w moim systemie, o podobnych nazwach.

Dostałem ten dokładny błąd, gdy adresy URL zostały zamienione na moim kliencie w pewnym momencie. Naprawdę podrapała się biedna po brodzie aż w końcu zrozumiałam ten głupi błąd.

Miałem ten problem i okazało się, że w moim generatorze proxy, który skopiowałem z innego serwisu, zapomniałem zmienić nazwę usługi.

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

Do...

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

To był prosty błąd kodu, ale prawie niemożliwy do debugowania. Mam nadzieję, że to oszczędzi komuś czasu.

Dla Klienta Javy wywołującego punkt końcowy. NET. Było to spowodowane niedopasowaniem nagłówka działania mydła.

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

Powyższy nagłówek HTTP lub następujący znacznik XML musi pasować do akcji/metody, którą próbujesz wywołać.

   <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>

Rozwiązałem to dodając do mojej realizacji umowy:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Na przykład:

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

}

Dostałem to po skopiowaniu pliku svc I zmianie jego nazwy. Chociaż nazwa pliku i svc.plik cs został poprawnie przemianowany, znaczniki nadal odwołują się do oryginalnego pliku.

Aby to naprawić, kliknij prawym przyciskiem myszy skopiowany plik svc i wybierz View Markup i zmień odniesienie do usługi.

Jak wspomniano w innych odpowiedziach, takich jak @ chinto, dzieje się tak, gdy element nagłówka SOAP: Action nie pasuje do punktu końcowego.

Możesz znaleźć poprawny URI do użycia, patrząc na WSDL serwera. Zobaczysz element operacji z wprowadzanym potomkiem, który ma atrybut "Action". To jest to, co twoje mydło: działanie musi być na życzenie klienta.

<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>

Miałem ten sam problem. Problem polegał na tym, że skopiowałem kod z innej usługi jako punkt wyjścia i nie zmieniłem klasy usługi w .plik svc

Otwórz .svc file an upewnij się, że atrybut Service jest poprawny.

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

Błąd mówi, że istnieje niedopasowanie, zakładając, że masz wspólny kontrakt oparty na tym samym WSDL, to niedopasowanie jest w konfiguracji.

Na przykład, że klient używa nettcpip, a serwer jest skonfigurowany do korzystania z podstawowego http.

Miałem podobny błąd. Może to być spowodowane zmianą ustawień umowy w pliku konfiguracyjnym po ponownym włączeniu go do projektu. rozwiązanie-zaktualizuj referencję webservice w projekcie VSstudio lub utwórz nowy serwer proxy za pomocą svcutil.exe

Jeśli wywołujesz metodę WCF, powinieneś umieścić interfejs w nagłówku.

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+ "\"");
}

Ten błąd pojawia się zazwyczaj, jeśli kod nie jest prawidłowo wdrożony.

W moim przypadku mam dwie usługi ServiceA i ServiceB. Znalazłem problem, że pliki ServiceB nie zostały poprawnie wdrożone. Z tego powodu, gdy ServiceA wywoływał ServiceB wewnętrznie, podawał poniżej błąd.

Upewnij się, że pliki i referencje są poprawnie wdrożone.

Spędziłem dni szukając odpowiedzi i znalazłem ją, ale nie w tym wątku. Jestem nowy w WCF i C#, więc dla niektórych odpowiedź może być oczywista.

W mojej sytuacji miałem narzędzie klienckie, które pierwotnie zostało opracowane dla usługi ASMX i dla mnie zwracało ten sam komunikat o błędzie.

Po wypróbowaniu różnego rodzaju rekomendacji znalazłem to miejsce:

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

Klient oczekiwał Http://TEST.COM/Login, ale WCF wysłał Http://TEST.COM/IService1/Login. Rozwiązaniem jest dodanie ustawienia do [OperationContract] w następujący sposób:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignoruj puste spacje w Http)

To może być z dwóch powodów:

1. Serwis ref jest nieaktualny, kliknij prawym przyciskiem myszy serwis ref N zaktualizuj go.

2. Umowa która została zrealizowana może być inna co klient ma. Porównaj obie usługi N umowa klienta N naprawić umowy niedopasowanie.

Również może być przydatne dla tych, którzy robią to przez kodowanie. Musisz dodać WebHttpBehavior () do dodanego punktu końcowego usługi. Coś w stylu:

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

Spójrz na : https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Głupie, ale zapomniałem dodać [OperationContract] do mojego interfejsu serwisu (tego oznaczonego [ServiceContract]) i wtedy też dostajesz ten błąd.

Twój Klient nie był updated.So Zaktualizuj swoje usługi z serwisu internetowego, a następnie Przebuduj swój projekt

Ja też miałem ten problem. Okazało się, że jest to spowodowane serializerem kontraktu na końcu serwera. Nie mógł zwrócić mojego obiektu kontraktu danych , ponieważ niektóre jego membrany danych były właściwościami readonly .

Upewnij się, że obiekty mają ustawione właściwości, które mają być serializowane.

O dziwo obejdzieliśmy ten błąd, używając tej samej obudowy, której użyto nazwy ścieżki i operacji. Najwyraźniej rozróżniała wielkość liter. Jeśli ktoś wie dlaczego, proszę o komentarz. Dziękuję!

Więc moja sprawa była następująca. Nie używałem proxy do interakcji klient-serwer, użyłem ChannelFactory (więc wszystkie porady dotyczące aktualizacji do referencji usługi były dla mnie bez znaczenia).

Usługa była hostowana w IIS i z jakiegoś powodu miała błędne odniesienia w folderze bin. Rekompilacja projektu po prostu nie prowadziła do nowych bibliotek DLL w tym folderze.

Więc po prostu usunąłem wszystkie rzeczy stamtąd i dodałem odniesienie do usługi w tym samym rozwiązaniu, a następnie przekompilowane i teraz wszystko działa.

Mój problem okazał się czymś rzadkim, ale i tak o tym wspomnę.

Napotkałem problem z wdrożeniem do naszego środowiska programistycznego. Na tej maszynie nasza osoba budująca stworzyła dwa foldery (wdrożyła dwie aplikacje). Stara wersja i nowa aktualna wersja. więc jeśli nie masz dwóch wersji aplikacji na serwerze WWW, Nie dotyczy to Ciebie.

Nowa lokalizacja, którą stworzył, miała niestandardową nazwę jako pierwsza część adresu url po host:

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

Na mojej lokalnej maszynie mój klient wskazywał na standardową nazwę folderu ustawioną we wszystkich środowiskach( poza deweloperem), w tym w moim środowisku lokalnym.

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

Kiedy rozwaliłem i wymieniłem sieć.config przy rozwoju z moją lokalną kopią, część adresu url, która musiała być specjalna, została zdmuchnięta ze standardową częścią, więc w rezultacie klient na dev wskazał na starą podanie.

Stary wniosek miał starą umowę i nie zrozumiał żądania i wyrzucił ten błąd.

Miałem ten sam błąd na wdrożonej usłudze WCF, problem był związany z inną usługą wdrożoną z innym kontraktem z tym samym portem.

Rozwiązanie

Używałem różnych portów w sieci.config i problem zniknął.

serwis 1

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

serwis 2

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

również , napotkałem tę sytuację, używając różnych portów dla tego samego adresu między usługą a konsumentem.

Miałem ten błąd, ponieważ mam starą wersję DLL w GAC mojego serwera. Więc upewnij się, że wszystko jest odwołane poprawnie i że assembly / GAC jest aktualny z dobrym dll.

Miałem ten problem z moim serwerem testowym, ponieważ uruchamiałem dwie kopie tego samego wcf na tej samej puli aplikacji. To, co dla mnie rozwiązało, to tworzenie oddzielonych PUL dla każdej wersji na moim wcf i ponowne uruchomienie IIS po tym.

Dla tych, którzy używają NodeJS z axios do składania żądań SOAP należy dołączyć SOAPAction header. Sprawdź poniższy przykład:

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)
  })