Incompatibilité de ContractFilter à l’exception de EndpointDispatcher

J’ai le scénario suivant que je tente de tester:

  1. Un WSDL commun
  2. Endpoint WCF qui implémente des objects basés sur le WSDL et qui est hébergé dans IIS.
  3. Une application cliente qui utilise un proxy basé sur le WSDL pour créer des requêtes.

Lorsque je lance un appel de service Web du client vers le noeud final du service, j’obtiens l’exception suivante:

{“Le message avec l’action ‘ http: // IMyService / CreateContainer ‘ ne peut pas être traité par le destinataire, en raison d’une incompatibilité ContractFilter au niveau de EndpointDispatcher. Cela peut être dû à une incompatibilité de contrat (actions incompatibles entre expéditeur et destinataire) ou incompatibilité de liaison / de sécurité entre l’expéditeur et le destinataire Vérifiez que l’expéditeur et le destinataire ont le même contrat et la même liaison (y compris les exigences de sécurité, par exemple, message, transport, aucun).

J’ai commencé à utiliser MS Service Trace Viewer, mais je ne savais pas où chercher. En regardant les classes dans le client et le noeud final, elles apparaissent identiques.

Comment commence-t-on à déboguer ce problème?

Quelles sont les causes possibles de cette exception?

Une “non-correspondance de ContractFilter à EndpointDispatcher” signifie que le destinataire n’a pas pu traiter le message car il ne correspondait à aucun des contrats configurés par le destinataire pour le noeud final ayant reçu le message.

Cela peut être parce que:

  • Vous avez différents contrats entre le client et l’expéditeur.
  • Vous utilisez une liaison différente entre le client et l’expéditeur.
  • Les parameters de sécurité du message ne sont pas cohérents entre le client et l’expéditeur.

Regardez la classe EndpointDispatcher pour plus d’informations sur le sujet.

J’ai eu cette erreur et celle-ci était due au contrat recevier qui ne mettait pas en œuvre la méthode appelée. En gros, quelqu’un n’a pas déployé la dernière version du service WCF sur le serveur hôte.

J’ai eu ce problème et j’ai constaté que dans mon générateur de proxy, que j’ai copié depuis un autre service, j’ai oublié de changer le nom du service.

J’ai changé ça …

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

à…

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

C’était une simple erreur de code, mais presque impossible à déboguer. J’espère que cela fera gagner du temps à quelqu’un.

Vous obtiendrez également ceci si vous essayez de vous connecter à la mauvaise URL 😉

J’ai deux points de terminaison et services définis dans mon système, avec des noms similaires.

J’ai eu cette erreur exacte lorsque les URL ont été échangées sur mon client à un moment donné. Vraiment griffé la tête jusqu’à finalement comprendre cette erreur stupide.

J’ai résolu ce problème en ajoutant ce qui suit à mon implémentation de contrat:

[ ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

Par exemple:

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

Je l’ai eu après avoir copié le fichier svc et l’ai renommé. Bien que le nom de fichier et le fichier svc.cs aient été correctement renommés, le balisage faisait toujours référence au fichier d’origine.

Pour résoudre ce problème, cliquez avec le bouton droit sur le fichier svc copié et choisissez Afficher le marquage et modifiez la référence du service.

Pour un client Java appelant un noeud final .net. Cela était dû à un en-tête d’action de soap incompatible.

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

L’en-tête HTTP ci-dessus ou la balise XML suivante doit correspondre à l’action / à la méthode que vous essayez d’appeler.

    https://example.org/v1/Service.svc http://example.org/ExampleWS/exampleMethod   ...   

J’ai eu le même problème. Le problème était que j’ai copié le code d’un autre service comme sharepoint départ et que je n’ai pas modifié la classe de service dans le fichier .svc.

Ouvrez le fichier .svc et assurez-vous que l’atsortingbut Service est correct.

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

Comme mentionné dans d’autres réponses, telles que @chinto, cela se produit lorsque l’élément d’en-tête SOAP: Action ne correspond pas au noeud final.

Vous pouvez trouver l’URI correct à utiliser en consultant le WSDL du serveur. Vous verrez un élément d’opération avec un enfant en entrée qui possède un atsortingbut “Action”. C’est ce que votre action SOAP: doit être à la demande du client.

     

L’erreur indique qu’il existe une non-concordance, en supposant que vous avez un contrat commun basé sur le même WSDL, alors la non-concordance est dans la configuration.

Par exemple, le client utilise nettcpip et le serveur est configuré pour utiliser http de base.

J’ai eu une erreur similaire. Cela peut être dû au fait que vous avez modifié certains parameters de contrat dans votre fichier de configuration après avoir été ré-inséré dans votre projet. solution – Mettez à jour la référence webservice sur votre projet VSstudio ou créez un nouveau proxy à l’aide de svcutil.exe

J’ai passé des jours à chercher la réponse et je l’ai trouvée, mais pas dans ce fil. Je suis tout à fait nouveau à WCF et C #, donc pour certains la réponse pourrait être évidente.

Dans mon cas, j’avais un outil client développé à l’origine pour le service ASMX, et pour moi, il renvoyait le même message d’erreur.

Après avoir essayé toutes sortes de recommandations, j’ai trouvé ce site:

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

Cela m’a mis sur le bon chemin. Plus précisément, “soap: operation” – WCF ajoutait ServiceName à l’espace de noms:

le client s’attendait à Http://TEST.COM/Login , mais WCF a envoyé Http://TEST.COM/IService1/Login . La solution consiste à append le paramètre à [OperationContract] comme ceci:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignorer les espaces vides dans HTTP)

Cela pourrait être pour 2 raisons à cela:

  1. service ref est obsolète, cliquez avec le bouton droit de la souris sur n ref update this.

  2. Le contrat que vous avez mis en place peut être différent de celui du client. Comparez les deux services n contrat client n corrigez la non-concordance des contrats.

Si vous appelez la méthode WCF, vous devez inclure l’interface dans l’en-tête.

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

J’ai eu la même erreur sur un service WCF déployé, le problème était lié à un autre service déployé avec un autre contrat avec le même port.

Solution

J’ai utilisé différents ports dans le fichier web.config et le problème a disparu.

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" 

En outre , j’ai rencontré cette situation en utilisant différents ports pour la même adresse entre le service et le consommateur.

En outre, cela pourrait être utile pour ceux qui le font en codant. Vous devez append WebHttpBehavior () à votre noeud final de service ajouté. Quelque chose comme:

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

Jetez un oeil à: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

Silly, mais j’ai oublié d’append [OperationContract] à mon interface de service (celle marquée avec [ServiceContract] ) et vous obtenez également cette erreur.

Votre client n’a pas été mis à jour. Mettez à jour vos services à partir du service Web, puis reconstruisez votre projet

Cette erreur survient généralement si le code n’est pas déployé correctement.

Dans mon cas, j’ai deux services ServiceA et ServiceB. J’ai trouvé le problème que les fichiers ServiceB n’étaient pas déployés correctement. À cause de cela, quand ServiceA appelait en interne ServiceB, il donnait moins d’erreur.

**Erreur**

Assurez-vous que les fichiers et les références sont correctement déployés.

J’ai eu ce problème aussi. Il s’est avéré qu’il était causé par le sérialiseur de contrat à la fin du serveur. Il ne pouvait pas retourner mon object de contrat de données car certains de ses membres étaient des propriétés en lecture seule .

Assurez-vous que vos objects ont des parameters pour les propriétés destinées à être sérialisées.

Curieusement, nous avons contourné cette erreur en utilisant le même nom que le nom Path and OperationContract utilisé. Apparemment, il était sensible à la casse. Si quelqu’un sait pourquoi, veuillez commenter. Je vous remercie!

Donc, mon cas était le suivant. Je n’ai pas utilisé de proxy pour l’interaction client-serveur, j’ai utilisé ChannelFactory (tous les conseils pour passer à une référence de service n’avaient donc aucun sens pour moi).

Le service était hébergé dans IIS et pour une raison quelconque, il y avait des références incorrectes dans le dossier bin. La recompilation du projet n’a tout simplement pas abouti à la création de nouvelles DLL dans ce dossier.

Donc, je viens de supprimer toutes les choses à partir de là et ajouté une référence au service dans la même solution, puis recompilé et maintenant tout fonctionne.

Mon problème s’est avéré être quelque chose de rare, mais je le mentionnerai quand même.

J’ai rencontré le problème de déploiement dans notre environnement de développement. Sur cette machine, notre compilateur avait créé deux dossiers (deux applications déployées). Une ancienne version et la nouvelle version actuelle. Donc, si vous n’avez pas deux versions de votre application sur le serveur Web, cela ne vous concerne pas.

Le nouvel emplacement qu’il a créé avait un nom non standard comme première partie de l’URL après l’hôte:

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

Sur mon ordinateur local, mon client indiquait le nom de dossier standard tel qu’il avait été configuré sur tous les environnements (à l’exception du développement), y compris mon environnement local.

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

Lorsque je suis tombé sur l’explosion et que j’ai remplacé web.config sur le développement par ma copie locale, la partie de l’URL qui devait être spéciale a été supprimée avec la partie standard, de sorte que le client dev a mis l’ancienne application.

L’ancienne application avait un ancien contrat et ne comprenait pas la demande et a jeté cette erreur.

J’ai eu cette erreur parce que j’ai une ancienne version de la DLL dans le GAC de mon serveur. Donc, assurez-vous que tout est référencé correctement et que l’assembly / GAC est à jour avec la bonne DLL.

J’ai eu ce problème avec mon serveur de test, car j’exécutais deux copies du même fichier wcf sur le même pool d’applications. Ce qui a été résolu pour moi, c’est de créer des pools séparés pour chaque version sur mon wcf et de redémarrer IIS après cela.

Pour ceux qui utilisent NodeJS avec axios pour effectuer les requêtes SOAP, vous devez inclure un en SOAPAction header . Consultez l’exemple ci-dessous:

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