ContractFilter stimmt nicht mit der EndpointDispatcher-Ausnahme überein
Ich habe das folgende Szenario, das ich testen möchte:
- Eine allgemeine WSDL
- WCF-Endpunkt, der Objekte basierend auf der WSDL implementiert und in IIS gehostet wird.
- Eine Client-App, die einen Proxy verwendet, der auf der WSDL basiert, um Anforderungen zu erstellen.
Wenn ich einen Webdienstanruf vom Client an den Dienstendpunkt tätige, erhalte ich die folgende Ausnahme:
{"Die Nachricht mit Action ' http: // IMyService/CreateContainer ' kann nicht vom Empfänger verarbeitet werden, weil ein ContractFilter-Konflikt am EndpointDispatcher. .__ vorliegt. Dies kann auf einen Konflikt mit einem Konflikt (nicht übereinstimmende Aktionen) zurückzuführen sein zwischen Absender und Empfänger) oder eine verbindliche/Sicherheitsabweichung zwischen Absender und Empfänger. Prüfen Sie, ob Sender und Empfänger den gleichen Vertrag und dieselbe Bindung haben (einschließlich Sicherheitsanforderungen, z. B. Nachricht, Transport, Keine). "}
Ich fing an, MS Service Trace Viewer zu verwenden, wusste jedoch nicht, wo ich suchen sollte. Wenn Sie die Klassen im Client und den Endpunkt betrachten, erscheinen sie identisch.
Wie fängt man an, dieses Problem zu debuggen?
Was sind mögliche Ursachen für diese Ausnahme?
Ein "ContractFilter-Konflikt am EndpointDispatcher" bedeutet, dass der Empfänger die Nachricht nicht verarbeiten konnte, weil er mit keinem der Verträge übereinstimmt, die der Empfänger für den Endpunkt konfiguriert hat, der die Nachricht erhalten 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.
Schauen Sie sich die Klasse EndpointDispatcher an, um weitere Informationen zu diesem Thema zu erhalten.
So:
Stellen Sie sicher, dass Ihre Client- und Server-Verträge übereinstimmen.
- Wenn Sie Ihren Client aus einer WSDL generiert haben, ist die WSDL auf dem neuesten Stand?
- Wenn Sie kürzlich eine Vertragsänderung vorgenommen haben, haben Sie die richtige Version von Client und Server bereitgestellt?
- Wenn Sie Ihre Client-Vertragsklassen manuell erstellt haben, stellen Sie sicher, dass die Namespaces, Elementnamen und Aktionsnamen mit den vom Server erwarteten übereinstimmen.
Prüfen Sie, ob die Bindungen zwischen Client und Server identisch sind.
- Wenn Sie eine .config-Datei zum Verwalten Ihrer Endpunkte verwenden, stellen Sie sicher, dass die Bindungselemente übereinstimmen.
Prüfen Sie, ob die Sicherheitseinstellungen zwischen Client und Server identisch sind.
- Wenn Sie eine .config-Datei zum Verwalten Ihrer Endpunkte 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 Host-Server bereitgestellt.
Ich hatte dieses Problem und stellte fest, dass ich in meinem Proxy-Generator, den ich von einem anderen Dienst kopiert hatte, vergessen hatte, 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 erspart jemandem Zeit.
Sie erhalten dies auch, wenn Sie versuchen, eine Verbindung zur falschen URL herzustellen ;).
In meinem System sind zwei Endpunkte und Dienste mit ähnlichen Namen definiert.
Dieser genaue Fehler ist aufgetreten, als die URLs zu irgendeinem Zeitpunkt auf meinem Client ausgetauscht wurden. Wirklich den Kopf gekratzt, bis dieser dumme Fehler endlich herausgefunden wurde.
Für einen Java-Client, der einen .net-Endpunkt aufruft. Dies wurde durch nicht übereinstimmende Soap Action-Header 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 dieses Problem gelöst, indem ich Folgendes zu meiner Vertragsimplementierung hinzugefügt habe:
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
Zum Beispiel:
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
public class MyUploadService : IMyUploadService
{
}
Ich habe es bekommen, nachdem ich die SVC-Datei kopiert und umbenannt habe. Obwohl der Dateiname und die Datei svc.cs korrekt umbenannt wurden, referenzierte das Markup weiterhin auf die Originaldatei.
Um dies zu beheben, klicken Sie mit der rechten Maustaste auf die kopierte svc-Datei, wählen Sie View Markup und ändern Sie die Servicereferenz.
Ich hatte das gleiche Problem. Das Problem war, dass ich den Code von einem anderen Dienst als Ausgangspunkt kopiert habe und die Dienstklasse in der SVC-Datei nicht geändert habe
Ö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" %>
Wie in anderen Antworten, z. B. @chinto, erwähnt, geschieht dies, wenn das Headerelement SOAP: Action nicht mit dem Endpunkt übereinstimmt.
Die richtige URI finden Sie in der WSDL des Servers. Sie sehen ein Operationselement mit einem Eingabe-Kind, das über das Attribut "Action" verfügt. Dies ist, was Ihre SOAP: Action auf der Client-Anfrage sein muss.
<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>
Der Fehler besagt, dass ein Konflikt vorliegt, vorausgesetzt, Sie haben einen gemeinsamen Vertrag, der auf derselben WSDL basiert, und dann ist der Konflikt in der Konfiguration enthalten.
Zum Beispiel, dass der Client nettcpip verwendet und der Server für die Verwendung von grundlegendem http eingerichtet ist.
Ich hatte einen ähnlichen Fehler. Dies kann daran liegen, dass Sie einige Vertragseinstellungen in Ihrer Konfigurationsdatei geändert haben, nachdem sie in Ihr Projekt eingefügt wurden. solution - Aktualisieren Sie die Webservice-Referenz in Ihrem VSstudio-Projekt oder erstellen Sie einen neuen Proxy mit svcutil.exe
Ich habe tagelang nach der Antwort gesucht und sie gefunden, aber nicht in diesem Thread ... Ich bin sehr neu in WCF und C #, daher ist die Antwort für manche offensichtlich.
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:
Das brachte mich auf den richtigen Weg. Speziell "soap: operation" - WCF hat ServiceName an den Namespace angehängt:
client erwartet Http://TEST.COM/Login, aber WCF hat Http://TEST.COM/IService1/Login..__ gesendet. Die Lösung besteht darin, die Einstellung [OperationContract] wie folgt hinzuzufügen:
[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Leerzeichen in HTTP ignorieren)
Wenn Sie die WCF-Methode aufrufen, sollten Sie die Schnittstelle in Header einfügen.
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+ "\"");
}
Dies kann aus zwei Gründen dafür sein:
dienstreferenz ist veraltet, Rechtsklick-Dienstreferenz aktualisieren.
vertrag, den Sie implementiert haben, kann anders sein als der Kunde Vergleichen Sie beide Service n-Client-Verträge. N Legen Sie die Verträge fest Nichtübereinstimmung.
Es kann auch für diejenigen nützlich sein, die dies durch Codierung tun. Sie müssen WebHttpBehavior () zu Ihrem hinzugefügten Serviceendpunkt hinzufügen. So etwas wie:
restHost.AddServiceEndpoint(typeof(IRestInterface), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior());
Werfen Sie einen Blick auf: https://docs.Microsoft.com/de-de/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf- Bedienung
Dieser Fehler tritt im Allgemeinen auf, wenn der Code nicht ordnungsgemäß bereitgestellt wird.
In meinem Fall habe ich zwei Dienste ServiceA und ServiceB. Ich fand das Problem, dass ServiceB-Dateien nicht ordnungsgemäß bereitgestellt wurden. Wenn ServiceA intern ServiceB anrief, gab es einen Fehler.
Bitte stellen Sie sicher, dass die Dateien und Referenzen ordnungsgemäß bereitgestellt werden.
Ich hatte dieses Problem auf meinem Testserver, weil ich zwei Kopien desselben WCF im selben App-Pool ausgeführt habe. Was für mich gelöst wurde, war das Erstellen separater Pools für jede Version in meinem WCF und das Starten von IIS danach neu.
Dumm, aber ich habe vergessen, [OperationContract] zu meiner Service-Schnittstelle hinzuzufügen (die mit [ServiceContract] markierte), und dann wird auch diese Fehlermeldung angezeigt.
Ich hatte auch dieses Problem. Es stellte sich heraus, dass es durch den Vertragsserialisierer am Server verursacht wurde. Es konnte mein Datenvertragsobjekt nicht zurückgeben weil einige seiner Datenelemente nur lesbare Eigenschaften waren .
Stellen Sie sicher, dass Ihre Objekte über Setter für Eigenschaften verfügen, die serialisiert werden sollen.
Mein Fall war also der folgende. Ich habe keinen Proxy für die Client-Server-Interaktion verwendet, ich habe ChannelFactory verwendet.
Der Dienst wurde in IIS gehostet und hatte aus irgendeinem Grund falsche Verweise im Ordner bin dort. 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 der gleichen Lösung hinzugefügt, dann neu kompiliert und jetzt funktioniert alles.
Bei einem bereitgestellten WCF-Dienst war der gleiche Fehler aufgetreten. Das Problem war auf einen anderen Dienst zurückzuführen, 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.
Dienst 1
contract="Service.WCF.Contracts.IBusiness1"
baseAddress="net.tcp://local:5244/ServiceBusiness"
Dienst 2
contract="Service.WCF.Contracts.IBusiness2"
baseAddress="net.tcp://local:5243/ServiceBusiness"
Auch, ich bin auf diese Situation gestoßen, indem ich einen unterschiedlichen Port für dieselbe Adresse zwischen dem Service und dem Consumer verwendet habe.
Ihr Client wurde nicht aktualisiert. Aktualisieren Sie Ihre Dienste über den Webdienst, und erstellen Sie dann Ihr Projekt neu
Ich hatte diesen Fehler, weil ich eine alte Version von DLL im GAC meines Servers habe. Stellen Sie daher sicher, dass alles korrekt referenziert ist und dass die Assembly/GAC mit der guten DLL auf dem neuesten Stand ist.
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 dieser Maschine hatte unser Build-Mitarbeiter 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 von ihm erstellte neue Ort 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 wies mein Client auf den Standard-Ordnernamen, der in allen Umgebungen (außer in der Entwicklung) eingerichtet wurde, einschließlich meiner lokalen Umgebung.
net.tcp://dev.umbrellacorp.com/AppServices/MyProvider
Als ich die web.config in der Entwicklung durch meine lokale Kopie ersetzt habe, wurde der Teil der URL, der speziell sein musste, mit dem Standardteil weggeblasen, sodass der Client von dev auf die alte Anwendung verwies.
Die alte Anwendung hatte einen alten Vertrag und verstand die Anfrage nicht und warf diesen Fehler.
Seltsamerweise haben wir diesen Fehler umgangen, indem wir dasselbe Gehäuse wie der Name von Path und OperationContract verwendet haben. Anscheinend wurde zwischen Groß- und Kleinschreibung unterschieden. Wenn jemand weiß warum, bitte kommentieren. Vielen Dank!
Für diejenigen, die NodeJS mit axios verwenden, um die SOAP - Anforderungen auszuführen, müssen Sie einen SOAPAction header angeben. Überprüfen Sie das Beispiel unten:
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)
})