ContractFilter mismatch at the EndpointDispatcher exception

Question

I have the following scenario that I'm trying to test for:

A common WSDL
WCF endpoint that implements objects based on the WSDL and is hosted in IIS.
A client app that uses a proxy based off the WSDL to create requests.

When I make a web service call from the client to the service endpoint, I get the following exception:

{"The message with Action 'http://IMyService/CreateContainer' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None)."}

I started using MS Service Trace Viewer, but not sure where to look. While looking at classes in client and the endpoint, they appear identical.

How does one begin to debug this problem?

What are some possible causes to this exception?

Paul Turner · Accepted Answer · 2019-01-17T14:30:26.437

A "ContractFilter mismatch at the EndpointDispatcher" means the receiver could not process the message because it did not match any of the contracts the receiver has configured for the endpoint which received the message.

This can be because:

You have different contracts between client and sender.
You're using a different binding between client and sender.
The message security settings are not consistent between client and sender.

Have at look at the EndpointDispatcher class for more information on the subject.

So:

Make certain that your client and server contracts match.

If you've generated your client from a WSDL, is the WSDL up-to-date?
If you've made a recent change to the contract, have you deployed the right version of both client and server?
If you've hand-crafted your client contract classes, make sure the namespaces, elements names and action names match the ones expected by the server.

Check the bindings are the same between client and server.

If you're using a .config file to manage your endpoints, make sure the binding elements match.

Check the security settings are the same between client and server.

If you're using a .config file to manage your endpoints, make sure the security elements match.

also make sure the service attribute is correct in the .svc file. See my answer below. — AntonK, Feb 18 '16 at 00:29
Just wanted to add to the solution above (for the newcomers) as I have encountered the same issue but the above solution didn't work for me. If you have already tried the above workarounds and still getting the same error, try updating your configuration by simple retyping endpoints involved even though its already correct on both server and client. — devpro101, Dec 01 '18 at 06:38

score 75 · Answer 2 · answered Oct 24 '11 at 15:10

75

I had this error and it was caused by the recevier contract not implementing the method being called. Basically, someone hadn't deployed the lastest version of the WCF service to the host server.

answered Oct 24 '11 at 15:10

adam

751
5
2

13

+1 - Same thing happened to me, except in my case it was me that was the "someone". I had forgot to commit & deploy the server-side code. – Jesse Webb Jul 03 '12 at 15:49
3

Yup, I had the name of the SOAP Action wrong. It wanted http://tempuri.org/ICodeGenService/RenderApp, but for some reason the code that parsed the WSDL thought just http://tempuri.org/RenderApp. – user435779 Oct 17 '12 at 13:13
Me too. I had the method in my .SVC.CS, but no corresponding OperationContract in my interface. – PahJoker May 05 '13 at 02:54
Me too :) I refreshed the WSDL in SoapUI using the local service under development, and when I created a request against the new method in the service, SoapUI used our development environment. So, method was working nicely, I just queried the wrong URL. – Larsbj Oct 19 '15 at 11:17
2

Thanks! I didn't spend hours debugging, instead after reading this I quickly realized I was sending requests to a wrong environment. – Jan Matousek Jan 28 '16 at 14:10
This same thing happened in my case. Some one overwritten the previous deployment by changing the code base without getting latest and deploying. – Yoky Apr 08 '16 at 19:03

score 27 · Answer 3 · edited Oct 29 '15 at 19:00

27

You will also get this if you try to connect to the wrong URL ;)

I have two endpoints and services defined in my system, with similar names.

Got this exact error when the URLs got swapped on my client at some point. Really scratched the head until finally figuring out this dumb mistake.

edited Oct 29 '15 at 19:00

mungflesh

776
11
22

answered Feb 20 '13 at 01:57

Brady Moritz

8,624
8
66
100

4

It's a silly mistake to make for sure, but a very useful answer here. As it's something obvious it is easily overlooked. – mungflesh Oct 29 '15 at 18:29
Wrong url gives - 'there was no endpoint listening' error – AriesConnolly Jul 03 '20 at 00:01
Can confirm, I put in swapped urls by accident and this is the error I got. Then having viewed this, I had realized this could be a problem in the first place and upon examining it closer-up, sure was the issue! – Vasily Hall Aug 04 '21 at 14:32
This answer is possible solution for given exception. Be careful with endpoint address and binding interface on different addresses – Actimele Feb 09 '22 at 00:58
Thanks. This is the same in ny case. I already on a rabbit hole of checking our proxies and turns out its just me being dumb pointing to a different endpoint – keysl Feb 20 '23 at 09:55

score 20 · Answer 4 · edited May 03 '16 at 15:03

I had this problem and found that in my proxy generator, which I copied from another service, I forgot to change the name of the service.

I changed this...

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

to...

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

It was a simple code error, but nearly impossible to debug. I hope this saves someone time.

score 14 · Answer 5 · answered Feb 24 '15 at 03:42

For a Java client calling a .net endpoint. This was caused by mismatching Soap Action header.

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

The above HTTP header or following XML tag needs to match the action/method your are trying to invoke.

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

score 9 · Answer 6 · edited Sep 07 '12 at 12:39

9

I solved this by adding the following to my contract implementation:

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

For example:

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

}

edited Sep 07 '12 at 12:39

Ben Hoffman

8,149
8
44
71

answered Apr 16 '12 at 20:01

ben

1,448
1
17
12

This solved my problem with a forwarded port. Thank you. – Mathias Müller Aug 21 '15 at 11:52
Not I got a new error, I hate IIS - CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error. – AriesConnolly Jul 03 '20 at 00:08

score 8 · Answer 7 · answered Feb 27 '14 at 09:40

I got this after i copied the svc file and renamed it. Although the file name and the svc.cs file were correctly renamed, the markup still referenced the original file.

To fix this, right click on the copied svc file and choose View Markup and change the service reference.

score 7 · Answer 8 · answered Dec 29 '15 at 15:58

7

As mentioned in other answers, such as @chinto, this happens when the SOAP:Action header element does not match the Endpoint.

You can find the correct URI to use by looking at the server's WSDL. You will see an operation element with an input child that has an "Action" attribute. That is what your SOAP:Action needs to be on the client request.

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

answered Dec 29 '15 at 15:58

Carson Evans

1,518
1
13
12

after days of googling and testing and going mad - this answer helped me. thanks. – babboon Nov 02 '17 at 05:57
in my particular scenario, I was making the call to the WebService from my java class using Apache HttpClient. In order to set the Soap action header, I called the HttpPost SetHeader method right after I called the setHeader method to setContent Type . – vofili May 19 '20 at 17:21

score 4 · Answer 9 · answered May 11 '18 at 18:56

For those who are using NodeJS with axios to make the SOAP requests you must include a SOAPAction header. Check the example below:

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

Thanks! I was missing the SOAPAction header when testing from postman — Gargamel, Feb 15 '21 at 13:08

AntonK · Answer 10 · 2023-01-25T02:04:25.373

3

I had the same issue. The problem was that I copied the code from another service as a starting point and did not change the service class in .svc file

Open the .svc file and make sure that the Service attribute is correct.

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

edited Jan 25 '23 at 02:04

answered Sep 14 '15 at 06:43

AntonK

2,303
1
20
26

score 2 · Answer 11 · answered Apr 11 '12 at 18:20

I had a similar error. This could be because you would have changed some contract setting on your config file after it was refrenced into you project. solution - Update the webservice reference on you VSstudio project or create a new proxy using svcutil.exe

score 2 · Answer 12 · edited May 20 '14 at 08:23

I spent days looking for the answer and I found it, but not in this thread. I am very new to WCF and C#, so to some the answer might be obvious.

In my situation I had a client tool that was originally developed for ASMX service, and for me it was returning that same error message.

After trying all sorts of recommendations I found this 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/

It put me on the right path. Specifically "soap:operation" - WCF was appending ServiceName to the Namespace:

client expected Http://TEST.COM/Login, but WCF sent Http://TEST.COM/IService1/Login. Solution is to add setting to [OperationContract] like this:

[OperationContract(Action = "http://TEST.COM/Login", ReplyAction = "http://TEST.COM/Login")] (Ignore blank spaces in Http)

Well. Your solution is to have the service behave as some client expects. But it could equally well (or in many cases, preferably) be solved by having the client actually conform to the server's contract! After all, the server is the publisher of the contract. — The Dag, Jul 11 '14 at 08:37

score 2 · Answer 13 · answered Dec 22 '15 at 12:45

If you are calling WCF method you should include interface in Header.

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

score 2 · Answer 14 · answered Aug 17 '17 at 18:08

2

Also it might be useful for those who are doing this by coding. You need to add WebHttpBehavior() to your added service endpoint. Something like:

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

Take a look at : https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

answered Aug 17 '17 at 18:08

Amir Dashti

369
3
14

This helped me save my time, Thanks :) – Sely Lychee Dec 28 '17 at 05:31

score 2 · Answer 15 · answered Mar 30 '11 at 14:54

2

The error says that there is a mismatch, assuming that you have a common contract based on the same WSDL, then the mismatch is in the configuration.

For example that the client is using nettcpip and the server is set up to use basic http.

answered Mar 30 '11 at 14:54

Shiraz Bhaiji

64,065
34
143
252

score 1 · Answer 16 · answered Jan 14 '14 at 13:08

This error generally comes if the code is not deployed properly.

In my case, I have two services ServiceA and ServiceB. I found the problem that ServiceB files were not deployed properly. Because of which when ServiceA was calling ServiceB internally it was giving below error.

**Error**

Please make sure the files and references are deployed properly.

score 1 · Answer 17 · answered Jan 30 '15 at 11:54

So, my case was the following. I didn't use proxy for the client-server interaction, I used ChannelFactory (thus all the advice to upgrade to service reference was meaningless to me).

The service was hosted in IIS and for some reason it had wrong references in the bin folder there. The project recompilation simply didn't lead to new dlls in that folder.

So I just deleted all the stuff from there and added reference to the service in the same solution, then recompiled and now everything works.

score 1 · Answer 18 · edited Aug 31 '15 at 06:52

1

This could be for 2 reasons for this:

service ref is outdated, right click service ref n update it.
contract which you have implemented might be different what client has. Compare both service n client contract n fix the contracts mismatch.

edited Aug 31 '15 at 06:52

Michele La Ferla

6,775
11
53
79

answered Aug 31 '15 at 05:34

Abdul sami

11
1

score 0 · Answer 19 · answered Feb 26 '13 at 11:01

0

Silly, but I forgot to add [OperationContract] to my service interface (the one marked with [ServiceContract]) and then you also get this error.

answered Feb 26 '13 at 11:01

Peter

13,733
11
75
122

score 0 · Answer 20 · answered Jun 07 '13 at 20:10

0

Your client was not updated.So Update your services from Web service and then rebuild your project

answered Jun 07 '13 at 20:10

Masoud Bahrami

111
1
12

score 0 · Answer 21 · answered May 22 '14 at 18:38

I had this problem as well. It turned out it was caused by the contract serializer on server's end. It couldn't return my data contract object because some of its datamembers were readonly properties.

Make sure your objects have setters for properties meant to be serialized.

score 0 · Answer 22 · answered Jul 26 '14 at 14:27

0

Oddly enough we worked around this error by using the same casing the Path and OperationContract name used. Apparently it was case-sensitive. If anyone knows why, please comment. Thank you!

answered Jul 26 '14 at 14:27

MikeTeeVee

18,543
7
76
70

DanielV · Answer 23 · 2015-12-30T09:17:25.243

I had the same error on a WCF service deployed, the problem was related to another service deployed with another contract with the same port.

Solution

I used different ports in the web.config and the issue disappeared.

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"

Also, I ran into this situation by using diferent port for the same address between the service and the consumer.

score 0 · Answer 24 · answered Sep 22 '15 at 14:28

My issue turned out to be something rare, but I'll mention it anyway.

I encountered the issue deploying to our development environment. On that machine, our build person had created two folders (deployed two applications). An old version and the new current version. So if you don't have two versions of your application on the web server, this does not apply to you.

The new location he created had a non-standard name as the first part of the url after the host:

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

On my local machine, my client was pointing to the standard folder name as was set up on all environments (except development), including my local environment.

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

When I blew away and replaced the web.config on development with my local copy, the part of the url that needed to be special was blown away with the standard part, so as a result the client on dev pointed to the old application.

The old application had an old contract and didn't understand the request and threw this error.

score 0 · Answer 25 · answered Nov 16 '16 at 16:45

0

I had this error because I have an old version of the DLL in the GAC of my server. So make sure everything is referenced correctly and that the assembly/GAC is up to date with the good dll.

answered Nov 16 '16 at 16:45

Helpha

452
6
17

score 0 · Answer 26 · answered Apr 11 '17 at 22:02

0

I had this problem om my test server, because I was running two copies of the same wcf on the same app pool. What solved for me was create separated pools for each version on my wcf and restart the IIS after this.

answered Apr 11 '17 at 22:02

Johann

67
1
1
7

score 0 · Answer 27 · answered Mar 30 '22 at 18:57

I encountered the same issue while using SOAP Requests against a server. Apparently it was throwing the error because our java versions did not match.

The endpoint we were hitting compiled SOAP server with java 8 and I had compiled my SOAP client with java 11, apparently this can breach contract matching.

ContractFilter mismatch at the EndpointDispatcher exception

27 Answers27

Linked