ContractFilter stimmt nicht mit der EndpointDispatcher-Ausnahme überein

Ich habe das folgende Szenario, auf das ich testen möchte:

1. Eine gemeinsame WSDL
2. WCF-Endpunkt, der Objekte basierend auf der WSDL implementiert und in IIS gehostet wird.
3. Eine Client-App, die einen auf der WSDL basierenden Proxy zum Erstellen von Anforderungen verwendet.

Wenn ich einen Webdienstaufruf vom Client zum Dienstendpunkt tätige, wird die folgende Ausnahme angezeigt:

{"Die Nachricht mit der Aktion ' http: // IMyService / CreateContainer ' kann auf dem Empfänger aufgrund einer ContractFilter-Nichtübereinstimmung am EndpointDispatcher nicht verarbeitet werden. Dies kann entweder auf eine Vertragsabweichung (nicht übereinstimmende Aktionen zwischen Absender und Empfänger) oder auf a zurückzuführen sein Bindung / Sicherheitsinkongruenz zwischen Sender und Empfänger. Überprüfen Sie, ob Sender und Empfänger denselben Vertrag und dieselbe Bindung haben (einschließlich Sicherheitsanforderungen, z. B. Nachricht, Transport, Keine). "}

Ich habe angefangen, MS Service Trace Viewer zu verwenden, bin mir aber nicht sicher, wo ich suchen soll. Bei der Betrachtung von Klassen im Client und im Endpunkt erscheinen sie identisch.

Wie fängt man an, dieses Problem zu debuggen?

Was sind mögliche Ursachen für diese Ausnahme?

Eine "ContractFilter-Nichtübereinstimmung am EndpointDispatcher" bedeutet, dass der Empfänger die Nachricht nicht verarbeiten konnte, da sie keinem der Verträge entsprach, die der Empfänger für den Endpunkt konfiguriert hat, der die Nachricht empfangen hat.

Dies kann sein, weil:

• Sie haben unterschiedliche Verträge zwischen Kunde und Absender.
• Sie verwenden eine andere Bindung zwischen Client und Absender.
• Die Nachrichtensicherheitseinstellungen sind zwischen Client und Absender nicht konsistent.

EndpointDispatcherWeitere Informationen zu diesem Thema finden Sie in der Klasse.

So:

Stellen Sie sicher, dass Ihre Client- und Serververträge übereinstimmen.

• Wenn Sie Ihren Client aus einer WSDL generiert haben, ist die WSDL aktuell?
• Wenn Sie kürzlich eine Vertragsänderung vorgenommen haben, haben Sie die richtige Version von Client und Server bereitgestellt?
• Wenn Sie Ihre Client-Vertragsklassen von Hand erstellt haben, stellen Sie sicher, dass die Namespaces, Elementnamen und Aktionsnamen mit den vom Server erwarteten übereinstimmen.

Überprüfen Sie, ob die Bindungen zwischen Client und Server gleich sind.

• Wenn Sie zum Verwalten Ihrer Endpunkte eine .config-Datei verwenden, stellen Sie sicher, dass die Bindungselemente übereinstimmen.

Überprüfen Sie, ob die Sicherheitseinstellungen zwischen Client und Server identisch sind.

• Wenn Sie zum Verwalten Ihrer Endpunkte eine .config-Datei verwenden, stellen Sie sicher, dass die Sicherheitselemente übereinstimmen.

Ich hatte diesen Fehler und er wurde dadurch verursacht, dass der Empfängervertrag die aufgerufene Methode nicht implementierte. Grundsätzlich hatte jemand nicht die neueste Version des WCF-Dienstes auf dem Hostserver bereitgestellt.

Sie erhalten dies auch, wenn Sie versuchen, eine Verbindung mit der falschen URL herzustellen ;)

In meinem System sind zwei Endpunkte und Dienste mit ähnlichen Namen definiert.

Ich habe genau diesen Fehler erhalten, als die URLs irgendwann auf meinem Client ausgetauscht wurden. Kratzte sich wirklich am Kopf, bis er endlich diesen dummen Fehler herausgefunden hatte.

Ich hatte dieses Problem und stellte fest, dass ich in meinem Proxy-Generator, den ich von einem anderen Dienst kopiert habe, vergessen habe, den Namen des Dienstes zu ändern.

Ich habe das geändert ...

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

zu...

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

Es war ein einfacher Codefehler, aber fast unmöglich zu debuggen. Ich hoffe das spart jemandem Zeit.

Für einen Java-Client, der einen .net-Endpunkt aufruft. Dies wurde durch eine Nichtübereinstimmung des Soap Action-Headers verursacht.

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

Der obige HTTP-Header oder das folgende XML-Tag muss mit der Aktion / Methode übereinstimmen, die Sie aufrufen möchten.

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

Ich habe dies gelöst, indem ich meiner Vertragsumsetzung Folgendes hinzugefügt habe:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Beispielsweise:

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

}

Ich habe dies erhalten, nachdem ich die SVC-Datei kopiert und umbenannt habe. Obwohl der Dateiname und die Datei svc.cs korrekt umbenannt wurden, verwies das Markup weiterhin auf die Originaldatei.

Um dies zu beheben, klicken Sie mit der rechten Maustaste auf die kopierte SVC-Datei, wählen Sie Markup anzeigen und ändern Sie die Dienstreferenz.

Wie in anderen Antworten wie @chinto erwähnt, geschieht dies, wenn das SOAP: Action-Headerelement nicht mit dem Endpunkt übereinstimmt.

Den richtigen URI für die Verwendung finden Sie in der WSDL des Servers. Sie sehen ein Operationselement mit einem untergeordneten Eingabeelement mit dem Attribut "Aktion". Das muss Ihre SOAP: Action auf der Client-Anfrage sein.

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

Ich hatte das gleiche Problem. Das Problem war, dass ich den Code von einem anderen Dienst als Ausgangspunkt kopierte und die Dienstklasse in der SVC-Datei nicht änderte

Öffnen Sie die SVC-Datei und stellen Sie sicher, dass das Service-Attribut korrekt ist.

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

Der Fehler besagt, dass eine Nichtübereinstimmung vorliegt, vorausgesetzt, Sie haben einen gemeinsamen Vertrag, der auf derselben WSDL basiert, und die Nichtübereinstimmung befindet sich in der Konfiguration.

Zum Beispiel, dass der Client nettcpip verwendet und der Server so eingerichtet ist, dass er grundlegende http verwendet.

Ich hatte einen ähnlichen Fehler. Dies könnte daran liegen, dass Sie einige Vertragseinstellungen in Ihrer Konfigurationsdatei geändert hätten, nachdem diese in Ihr Projekt übernommen wurden. Lösung - Aktualisieren Sie die Webservice-Referenz für Ihr VSstudio-Projekt oder erstellen Sie mit svcutil.exe einen neuen Proxy

Dieser Fehler tritt im Allgemeinen auf, wenn der Code nicht ordnungsgemäß bereitgestellt wird.

In meinem Fall habe ich zwei Dienste ServiceA und ServiceB. Ich habe das Problem festgestellt, dass ServiceB-Dateien nicht ordnungsgemäß bereitgestellt wurden. Aus diesem Grund gab ServiceA beim internen Aufruf von ServiceB den folgenden Fehler aus.

Bitte stellen Sie sicher, dass die Dateien und Referenzen ordnungsgemäß bereitgestellt werden.

Ich habe tagelang nach der Antwort gesucht und sie gefunden, aber nicht in diesem Thread. Ich bin sehr neu in WCF und C #, daher könnte für einige die Antwort offensichtlich sein.

In meiner Situation hatte ich ein Client-Tool, das ursprünglich für den ASMX-Dienst entwickelt wurde, und für mich gab es dieselbe Fehlermeldung zurück.

Nachdem ich alle möglichen Empfehlungen ausprobiert hatte, fand ich diese Seite:

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

Es hat mich auf den richtigen Weg gebracht. Speziell "soap: operation" - WCF hat ServiceName an den Namespace angehängt:

Client erwartet Http://TEST.COM/Login, aber WCF gesendet Http://TEST.COM/IService1/Login. Die Lösung besteht darin, folgende Einstellungen hinzuzufügen [OperationContract]:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Leerzeichen in HTTP ignorieren)

Dies kann zwei Gründe haben:

1. Service Ref ist veraltet. Klicken Sie mit der rechten Maustaste auf Service Ref und aktualisieren Sie es.

2. Der von Ihnen implementierte Vertrag unterscheidet sich möglicherweise vom Vertrag des Kunden. Vergleichen Sie beide Dienste n Kundenvertrag n Beheben Sie die Vertragsinkongruenz.

Wenn Sie die WCF-Methode aufrufen, sollten Sie die Schnittstelle in den Header aufnehmen.

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

Es kann auch für diejenigen nützlich sein, die dies durch Codierung tun. Sie müssen WebHttpBehavior () zu Ihrem hinzugefügten Service-Endpunkt hinzufügen. Etwas wie:

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

Schauen Sie sich Folgendes an: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Dumm, aber ich habe vergessen, [OperationContract]zu meiner Service-Oberfläche (die mit gekennzeichnete [ServiceContract]) hinzuzufügen , und dann erhalten Sie auch diesen Fehler.

Ihr Client wurde nicht aktualisiert. Aktualisieren Sie also Ihre Dienste über den Webdienst und erstellen Sie dann Ihr Projekt neu

Ich hatte auch dieses Problem. Es stellte sich heraus, dass dies durch den Vertragsserialisierer auf Serverseite verursacht wurde. Mein Datenvertragsobjekt konnte nicht zurückgegeben werden, da einige seiner Datenmitglieder schreibgeschützte Eigenschaften waren .

Stellen Sie sicher, dass Ihre Objekte Setter für Eigenschaften haben, die serialisiert werden sollen.

Seltsamerweise haben wir diesen Fehler umgangen, indem wir das gleiche Gehäuse wie den Namen Path und OperationContract verwendet haben. Anscheinend wurde zwischen Groß- und Kleinschreibung unterschieden. Wenn jemand weiß warum, bitte kommentieren. Danke dir!

Mein Fall war also der folgende. Ich habe keinen Proxy für die Client-Server-Interaktion verwendet, sondern ChannelFactory (daher waren alle Ratschläge zum Upgrade auf die Dienstreferenz für mich bedeutungslos).

Der Dienst wurde in IIS gehostet und hatte aus irgendeinem Grund falsche Verweise im Ordner bin. Die Neukompilierung des Projekts führte einfach nicht zu neuen DLLs in diesem Ordner.

Also habe ich einfach alles von dort gelöscht und einen Verweis auf den Dienst in derselben Lösung hinzugefügt, dann neu kompiliert und jetzt funktioniert alles.

Mein Problem stellte sich als etwas Seltenes heraus, aber ich werde es trotzdem erwähnen.

Ich bin auf das Problem bei der Bereitstellung in unserer Entwicklungsumgebung gestoßen. Auf diesem Computer hatte unsere Build-Person zwei Ordner erstellt (zwei Anwendungen bereitgestellt). Eine alte Version und die neue aktuelle Version. Wenn Sie also nicht zwei Versionen Ihrer Anwendung auf dem Webserver haben, gilt dies nicht für Sie.

Der neue Speicherort, den er erstellt hat, hatte einen nicht standardmäßigen Namen als ersten Teil der URL nach dem Host:

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

Auf meinem lokalen Computer zeigte mein Client auf den Standardordnernamen, der in allen Umgebungen (außer in der Entwicklung) einschließlich meiner lokalen Umgebung eingerichtet wurde.

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

Als ich die web.config bei der Entwicklung weggeblasen und durch meine lokale Kopie ersetzt habe, wurde der Teil der URL, der speziell sein musste, mit dem Standardteil weggeblasen, sodass der Client auf dev auf die alte Anwendung verwies.

Die alte Anwendung hatte einen alten Vertrag und verstand die Anfrage nicht und warf diesen Fehler.

Ich hatte den gleichen Fehler bei einem bereitgestellten WCF-Dienst. Das Problem hing mit einem anderen Dienst zusammen, der mit einem anderen Vertrag mit demselben Port bereitgestellt wurde.

Lösung

Ich habe verschiedene Ports in der web.config verwendet und das Problem ist verschwunden.

Service 1

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

Service 2

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

Außerdem bin ich auf diese Situation gestoßen, indem ich einen unterschiedlichen Port für dieselbe Adresse zwischen dem Dienst und dem Verbraucher verwendet habe.

Ich hatte diesen Fehler, weil ich eine alte Version der DLL im GAC meines Servers habe. Stellen Sie also sicher, dass alles korrekt referenziert ist und dass die Assembly / GAC mit der guten DLL auf dem neuesten Stand ist.

Ich hatte dieses Problem auf meinem Testserver, weil ich zwei Kopien desselben wcf im selben App-Pool ausführte. Was für mich gelöst wurde, war, separate Pools für jede Version auf meinem wcf zu erstellen und den IIS danach neu zu starten.

Für diejenigen, die NodeJS mit Axios verwenden , um die SOAP-Anforderungen zu stellen, müssen Sie a einschließen SOAPAction header. Überprüfen Sie das folgende Beispiel:

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