There are two ways to accomplish giving a DataContract class a constructor. Probably the most consistent way is to move the DataContract into a separate class library which you reference in your service and client. As stated by John Saunders there is a way to tell Visual Studio to use an existing class when generating the proxy code for the referenced service. After this you can just add the constructor to that class normally.
If you want the constructor to only appear on the client side or for some other reason are unable to use a shared class library, you can create a partial class. There is really no defined 'location' for such a class. All that is required for providing the constructor through a partial class is to create a new class file which defines the same class as your proxy.
So assuming you have a proxy class ReferencedServiceProxy.ContractClass you need to create a new code file which defines the partial class
namespace ReferencedServiceProxy
{
partial class ContractClass
{
// Constructor. Naturally the constructor cannot overwrite one
// defined in the proxy class already. Not sure if those define
// a default constructor.
public ContractClass()
{
// Implementation
}
}
}
As long as the file is compiled normally, the compiler does all the rest.
However, without knowing the need for a constructor, it's probably worth pointing out that a constructor is not called when deserializing the object on client-side as the object is not 'constructed' as such.
http://mehranikoo.net/CS/archive/2007/11/09/DataContractConstructorsInWCF.aspx has something related to what happens during deserialization and how to affect it. Just something which I learned the hard way.. with silverlight which doesn't even support the OnDeserialization attribute.