If you control both ends of the communication (both the server side and the client), and both are .NET, you have two options:
- either add your service references like you normally would (if you don't control both sides) - in that case, you get a client-side proxy class, which implements the proxy for the service methods, and all the data contracts are duplicated (you get classes in your client proxy namespace, that will serialize to and deserialize from the same XML representation in the message that is sent back and forth - but the classes are different, since they live in a different namespaces)
or, optionally:
- you can put all your service contracts, data contracts and so on into a separate "MyService.Contracts" assembly (call it whatever makes sense to you), and then you can share that assembly; on the server-side, your code that implements the service contract will have a reference to that shared assembly - and on the client side, you do the same thing, basically: your client project will add a reference to that shared assembly, and now you have all your data contracts (your "message" types) only once - in the shared assembly namespace.
Option #2 does have its clear advantages, but again:
- it only works if you control both sides of the communication
- it only works if both sides are .NET code
- since you don't use the built-in Add Service Reference mechanism, you might need to manually create some of your client-side configuration (it's really not that hard)
I hope this gives you a few ideas and insights - if you have further concrete questions - you know where to ask!