[wcf] ContractFilter mismatch at the EndpointDispatcher exception

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

1. A common WSDL
2. WCF endpoint that implements objects based on the WSDL and is hosted in IIS.
3. 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?

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)

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.

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.

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://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/calling-a-rest-style-service-from-a-wcf-service

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

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

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.

Please make sure the files and references are deployed properly.

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.

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>

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.

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.

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

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>

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!

This could be for 2 reasons for this:

1. service ref is outdated, right click service ref n update it.

2. contract which you have implemented might be different what client has. Compare both service n client contract n fix the contracts mismatch.

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

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

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.

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.

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.

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.

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.

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
{

}

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.

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 an make sure that the Service attribute is correct.

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