Call WCF service without knowing the contract

Question

I try to do the following:

I have a Windows service which is running a TCP WCF service.

Now, I want to implement a client, which can connect to this service. But this client doesn't know the contract of the service. He knows that the service does provide a method Download (string path). I want to connect to the service and call Download("c:\\temp\\xxx.exe").

I have tried the following:

var myBinding = new NetTcpBinding(SecurityMode.None)
{
    TransferMode = TransferMode.Streamed,
    MaxBufferPoolSize = 524288,
    MaxBufferSize = 2147483647,
    MaxConnections = 254,
    MaxReceivedMessageSize = 2147483647,
    PortSharingEnabled = true
};

var myEndpoint = new EndpointAddress("net.tcp://localhost:6648/InstallerBootstrapperService");

var myChannelFactory = new ChannelFactory<IInstallerBootstrapperService>(myBinding, myEndpoint);

IInstallerBootstrapperService client = null;

try {
    client = myChannelFactory.CreateChannel();
    client.Download("c:\\temp\\xxx.exe");
    ((ICommunicationObject) client).Close();
} catch {
   if (client != null) {
        ((ICommunicationObject) client).Abort();
   }
}

But this throw an Exception when I call Download(). It says:

The message with Action 'Prayon.Service.Library/IInstallerBootstrapperService/Download' 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).

Is there a way that I can call the service method without knowing the contract? Can I change something on the service side, that this client can always call the method?

you need to provide proper namespaces for contract and operation. do service expose MEX or discovery btw ? — vittore, Oct 15 '11 at 15:02
how do you mean that about the namespace? - The Service do not expose MEX or discovery. — BennoDual, Oct 15 '11 at 15:12
In brief: NO. The contract is **THE** core piece of the entire WCF service architecture - if your client doesn't know the contract, I highly doubt you'll be able to get a client to call your service. If so, it'll be a gross hack..... — marc_s, Oct 15 '11 at 17:59
This sounds similar to http://stackoverflow.com/q/54579/701062 — Gary.S, Oct 15 '11 at 19:08
marc_s, you ought to provide your response as a real answer. It IS the answer. Not the answer he wanted but it is the correct answer. — Cheeso, Oct 15 '11 at 20:19
mmhh - perhaps there is a Way to redefine the contract-Interface in the Client like it is defined on the Server Side? — BennoDual, Oct 16 '11 at 00:51

score 2 · Accepted Answer · answered Oct 17 '11 at 13:08

Server has no idea what client has as a contract, what server knows instead is what client sends it as a SOAP request which should has proper information inside, so WCF plumbing would find appropriate contract on the service type and find operation that would match also. Depending on the filtering settings service type together with ServiceModel settings can be set up on not using filtering and in this case you do not need to match namespaces for example, moreover server can be setup in such a way that particular method catch all the calls from clients, regardless of information placed in SOAP request.

So the error you get clearly tells you that filter mismatch which means either Namespace property of contract on client is not the same as on the server or security settings are different

to fix namespace you define contract on client like this

 [ServiceContract(
      Namespace="namespaceuri",
      Name="contractname")]
 public interface IInstallerBootstrapperService {

      [OperationContract(
             Namespace="namespaceuri", 
             Action ="actionuri", 
             ReplyAction="replyactionuri")]
      void Download( string path);

 }

and namespace property of both attributes should match those on server.

to fix other settings that can mismatch you need to know what transactionFlow, transport and message security and encoding and messageversion of server endpoint

at first try netTcp default settings they are likely to match

Call WCF service without knowing the contract

1 Answers1