3

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 Customer.

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!

Jamie Chapman
  • 4,229
  • 5
  • 29
  • 47

1 Answers1

4

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.

blowdart
  • 55,577
  • 12
  • 114
  • 149
  • blowdart, just tried your solution (data contract’s in a separate assembly) and it seems to work quite nicely. Thanks very much :-) – Jamie Chapman Jan 26 '10 at 14:49
  • Just out of interest, this means that I won’t be using [DataContract] and [DataMember] annotations on my classes, do you know of any consequences for doing so? – Jamie Chapman Jan 26 '10 at 14:52
  • I would put them on, as it still controls the shape of the messages, what's optional etc. They are still used to create the messages it's just now you're sharing that implementation – blowdart Jan 26 '10 at 16:57