I am working on a WCF application with a server and a client (naturally). In server project, I defined the classes with contract attributes.
Now when the server is ready, I added the service reference and it created the proxy for me. I used it and it did work fine.
The question I want to ask is, is it OK if I create a common DLL which contains the class definitions with contract attributes and use it for both server and client (instead of using the classes generated for client by Visual Studio). If I use common classes, I don’t have to worry about generics collections being converted into arrays while automatic code generation. Is it silly? Is it possible? Have anyone done this before? Is it OK to do this?
The deployment scenario is such that there will be limited (few) number of clients in a secure intranet and it is OK to update existing clients whenever there is a change in server.
That approach is fine (I use that quite a bit) as long as you control the client. It won’t work (obviously) with java clients etc. If you know you will never need to support non-.NET clients, then it can be powerful, but it breaks some purist SOA rules. In particular, yes, an intranet scenario is one where I might consider this approach.
Both svcutil.exe and the IDE have options to re-use types from existing assemblies to do exactly this.
edit another advantage of this approach is if you want to use the same validation logic at the client, without coding it twice – for example
IDataErrorInfoetc.