4

I was wondering how a client project in Visual Studio could reference a WCF service that doesn't have a mex binding. Whenever I remove the default mex binding in any sample WCF service, the client apps cannot find the service and in the auto-generated comments, it's recommended that in production environment, mex binding should be removed. Then how are the client apps supposed to find the service and reference it?

user1137993
  • 101
  • 2
  • 9

2 Answers2

10

If you have access to the assemblies which contain the types which define the service contract, operations, and data contracts, then you can just create a proxy on the fly using ChannelFactory. In this instance you would not need to retrieve any service metadata as you already have access to all the information you need to call the service.

For example

// Create service proxy on the fly
var factory = new ChannelFactory<IMyServiceContract>("NameOfMyClientEndpointInConfigFile");
var proxy = factory.CreateChannel();

// Create data contract
var requestDataContract = new MyDataContract();

// Call service operation.
var responseDataContract = proxy.MyServiceOperation(requestDataContract);

It also helps if you have access to the service-side config file so you can copy the endpoint details out of there into your client config.

tom redfern
  • 30,562
  • 14
  • 91
  • 126
0

The mex endpoint is a necessary part of WCF SOAP services. It is what enables client toolkits to pull down the WSDL and auto-generate proxy classes. As you point out, without it, clients have no way to get the information to consume the service. If you want clients to be able to consume and find your service, you should leave it available when your service is in production.

Joe Alfano
  • 10,149
  • 6
  • 29
  • 40
  • Thanks Joe. You mentioned WCF SOAP services and it arose another question in my mind. Does WCF offer types of service other than SOAP? What does it mean exactly when you say a SOAP service? – user1137993 Jan 15 '12 at 04:48
  • Wcf supports SOAP and RESTful services. Soap services offer a tremendous amount of functionality (transactions, security, etc) based on the ws-* protocols. But they tend to be more complex and usually require a client toolkit to consume. Restful services have less functionality out of the box but are more lightweight and are easier to consume. The choice on which to use really depends upon you application – Joe Alfano Jan 15 '12 at 05:02
  • 2
    This is not the full story - you can have a WCF client without auto generating client proxies. Instead you reference the assembly of the service contract and use ChannelFactory to give you a proxy. When you call the proxy your call uses the transport and bindings etc from the client config file. Refer @hugh's answer. – saille Jan 16 '14 at 21:04
  • Although this is the accepted answer it should be noted that a service reference is almost always an inferior solution to calling the service directly. The only times you should consider using one is if either of the following two conditions are met: 1. You don't have access to the service binaries. Obvioulsy you must be able to consume the actual types used to define the service. or, 2.The service binaries are available, but are compiled into an "uber-assembly" containing all sorts of stuff you don't care about and don't necessarily want to consume from your client app. – tom redfern Apr 25 '16 at 14:36