wcfwcfserviceclientwcf-behaviour

WCF - Does a client must have the same behavior as the endpoint?


I have the following WCF endpoint configuration:

      <service behaviorConfiguration="MyNamespace.ContainerManagementServiceBehavior"
    name="MyNamespace.ContainerManagementService">
    <endpoint address="" binding="basicHttpBinding"
       name="ContainerManagementbasicHttpEndpoint" contract="MyNamespace.IContainer"/>                  
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
  </service>      
   <behaviors>      
    <behavior name="MyNamespace.ContainerManagementServiceBehavior">
      <serviceMetadata httpGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="false" />
    </behavior>
</behaviors>

Here is my client configuration:

<client>
  <endpoint address="http://localhost:3227/Services/ContainerManagementService.svc"
    binding="basicHttpBinding" 
    contract="MyNamespace2.IAQSIDMService" name="externalService" />
</client>

I am doing a web service call dynamically, providing a different address :

var svc = new AQSIDMServiceClient(Constants.External_Service_ConfigurationName, serviceAddress);

When I call the endpoint, I get the following error message:

{"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)."}

Could this be due to the fact that my client does NOT have the same serviceBehavior as the endpoint? Is there something else I can be missing?

Thanks!


Solution

  • The exception tells you exactly what is wrong. Are you using the same contract on both sides of the request? Are the bindings and security the same?

    If you can respond to those queries first, we should be able to see what the request is failing. You should also enable tracing on the service and see what error/warning level traces are emitted. That should also help you diagnose the issue.