The standard way of obtaining a WCF client that corresponds to a WCF service is to use the Service Reference utility of VS 2008 (or VS 2005). This is a fine way of generating a quick out-of-the-box proxy client that provides what is needed to communicate with the service.
When you dig into what is provided for you, you find a fairly straight forward implemented file called reference.cs containing an extension of the ClientBase class as well as an implementation of the service contract exposed by the service. Included in the same file is all DataContracts involved in methods provided by the service. Additionally, an application config file is created (if not already present) including a huge amount of settings – all reflecting the corresponding service settings.
The generated lot will suffice in scenarios where you start out using WCF and try to get a grasp of it. This is fine when you have a regular A calls B calls C chain of services. C exposes the DataContract D1 so B will one Service Reference to C and A will have another Service Reference to B. Actually this means that the DataContract D1 is implemented three times each one with an individual namespace.
Now trouble realises its ugly head when you occasionally need to call service C from service A. To facilitate this, a new Service Reference is added to service A providing a new implementation of the DataContract D1. Obviously, this additional implementation is truly unnecessary and moreover the namespace is different from the namespace obtained from the Service Reference to service B. This makes the two implementations of DataContract D1 incompatible even though they actually origin from the same class.
The generated configurations are also duplicated for each Service Reference and are placed in the project that contains the Service Reference. But if your project containing the Service References isn’t the project hosting your client you need to move these new configuration settings each time you update your Service Reference.
I know you can try to tweek the way Service References can be made by forcing reuse of already generated references. But it’s a hassle and to my experience it rarely works as expected.
What I suggest is to drop the use of auto generated Service References. Instead, place all Service Contracts in one project, place all DataContracts in another (or optionally the same) project and let both the services and the clients reference these projects. Next you implement your own proxy client classes, which is done fairly easy (see the following listing).
[DataContract]
public class DataContractD1
{
[DataMember]
public string MyData { get; set; }
}
[ServiceContract]
public interface IAService
{
[OperationContract]
void AddMyData(DataContractD1 data);
}
public class Client1 : ClientBase<IAService>, IAService
{
public void AddMyData(DataContractD1 data)
{
Channel.AddMyData(data);
}
}
What is missing is altering the configuration file as exemplified in the following listing.
<client> <endpoint address="net.tcp://localhost:7001/AService" binding="netTcpBinding" contract="MyServices.IAService"/> </client>
This is basically what is to it.
Tags: Service Reference, SOA, WCF
