WCF with multiple services and namespace issues

I have created a number of WCF Services, for arguments sake they are called Service1 and Service2.

Both of the services return (at some point, possibly through a relationship inside an object) a Customer object.

For testing sake, I have added a GetCustomer() method to both Service1 and Service2 and I have added a service reference to both services in a basic WinForms application.

Service1Client proxy1 = new Service1Client();

Customer customer1 = proxy1.GetCustomer(); //

^^^^^^ Ambiguous reference, requires me to name as WcfTestClient.Service1.Customer

Service2Client proxy2 = new Service2Client();

Customer customer2 = proxy2.GetCustomer();

^^^^^ Ambiguous reference, requires me to name as WcfTestClient.Service2.Customer

The problem is, the Customer object returned by Service1 and Service2 are both the same type of Customer (WcfTestService.Customer). To remedy this I need to include the full assembly name rather than just Cus开发者_如何学Gotomer.

I have read a few posts on Stack Overflow stating that it is possible to compile the Data Contracts into a separate assembly, I don’t particularly like this idea as it may still cause problems with clients using other languages, such as Java.

Another solution I have seen is the SvcUtil.exe method, but from what I have seen this solution doesn’t address my namespace issue as I need to run the Util for each service individually?

If anyone has any helpful suggestions, please get in touch!

---

Both of the services return (at some point, possibly through a relationship inside an object) a Customer object.

Here's where you're wrong. WCF doesn't return objects, REST doesn't return objects, SOAP doesn't return objects. They all pass messages.

Now what happens when you add a reference to a web service is Visual Studio happily creates a wrapper class for these messages, exposing their contents as properties, nothing more. Because you are adding two services these wrapper classes have no knowledge of each other and thus you end up with two namespaces and two wrapper classes.

Yes, as you say you could move the message classes to a separate assembly, link that and avoid Add Reference and that will then act as a proper object, but still behind the scenes it's messages being passed and serialized and deserialized into this shared object. Stop thinking in terms of object passing and start thinking in terms of messages and you'll realise you're either stuck with two wrapper objects, or you need to link an external assembly.