Client side configuration
The client can be configured similarly to the service side with the app.config. The configuration is inferred automatically when you use visual studio to generate your proxy. This holds true for the SvcUtil, as long as you will not use the /noconfig
switch.
One thing to look out for, is that you will need to specify unique names for each of your client endpoints. This is required so that a client can instantiate a proxy for the specific endpoint, which can be a mixture of several servicecontracts. If the name is not unique or not defined WCF throws a runtime error.
A client can match an endpoint of a service exactly, but also can define many endpoints with different configurations to same or different endpoints or combinations of that Service. This is opposed to the service side, where you need to supply a specifiy endpoint and cannot mix endpoint configurations.
In the wake of this section I want to let you know that WCF comes with a GUI configuration editor for both client and service side (which I personally have not tried out yet) It is called SVCConfigEditor.exe and is capable of editing both host and client configuration. It is accessible by using the contextmenu on app.config and clicking on EditWcfConfig.
Working with the proxy on the client side:
The generated proxy derives from the ClientBase<T> class, where the TypeParameter T is of the type of the service contract. This class also has a property of type T called Channel. With this you can Invoke the methods on the Service remotely. (see Working with Channels below and the auto generated proxy).
To use the Proxy you can call new myServiceClient(“EndpointNameInConfig”). If you have more than one Endpoint specified in the client config, and do not call the ctor with the Name, you’ll encounter an exception. The same happens if you supply a name that is not found in the config file.
Remember that when you use a Proxy you should always close the proxy when you are done with the call. That releases the connection and Channel to the service, which is of particular importance for transport session bindings.
Instead of calling Close() you could also use the Dispose() method, which internally calls close, but also lets you use the using syntax.
With each proxy call you utilize the WCF runtime, this means among other things, that for each call you get a TimeOut. To be more explicit, on the client side it is the SendTimeout. This is a benefit in its own regard, because with this way the proxy handles server deadlocks and such on your behalf, after the timeout has expired (defaults to 60seconds).
Working with Channels
As you can tell by the Channel property of the ClientBase<T>, WCF also allows you to work directly with Channels to invoke operations on the remote service.
I personally tend to use this approach most of the time, because it gives me the control over the use of the channel and also over the source code itself. You can see my CommunicationClient in the heitech.WCFUtilXt nuget package and on GitHub. For the Channel the same best practices like working with a client proxy apply, e.g. closing the channel if you are done with the calls to the service.
internal static class MyChannelProxy
{
internal static IMyService FromChannel()
{
var endpointAddress = new EndpointAddress("net.tcp://localhost:8080");
return ChannelFactory<IMyService>.CreateChannel(MyCustomBinding.GetBinding(), endpointAddress);
}
}
...
var proxyFromChannel = MyChannelProxy.FromChannel();
proxyFromChannel.Connect();
result = proxyFromChannel.ReturnName();
proxyFromChannel.Disconnect();
// either cast to IDisposable or to ICommunicationObject
if (proxyFromChannel is IDisposable disposable)
disposable.Dispose();
Console.WriteLine(result);
Console.ReadLine();
0 Comments