+3  A: 

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
blowdart, just tried your solution (data contract’s in a separate assembly) and it seems to work quite nicely. Thanks very much :-)
Jamie Chapman
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
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