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?

319858 次浏览
小开

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.

小开
最佳答案

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.
小开

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.

小开

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

小开

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
{


}
小开

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.

小开

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

小开

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

小开

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.

小开

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

小开

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.

小开

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!

小开

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.

小开

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.

小开

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.

小开

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" %>
小开

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.

小开

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

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.

小开

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.

小开

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

小开

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

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.


提交答案