In a typical, service-oriented scenario, you have the DataContract in your server-side service library. Anyone who will be calling you will be adding a client proxy connection to your service, and thus will be in fact duplicating your DataContract.
So in the "normal" case, you have your "master" DataContract on the server side, and a separate class in each of the client proxies accessing your service. Those client copies are "identical on the wire", e.g. they serialize into the same message format - which is really all there is between your client and your server - a serialized message being sent back and forth.
As a service developer, you definitely have to have your DataContract on the server side. But the same really also applies to the service contracts - those also have to be on the server side - otherwise you won't be able to publish your service interface to the world to be used by anyone who might connect to your service.
I would suggest the following at least two projects for each server:
- a class library which contains the service contracts (IService interfaces), the data contracts, and possibly the fault contracts
- a class library or self-hosted EXE (console app) that contains the actual service implementation (the classes implementating the service interfaces)
Marc