I am confused how to add/include/reference a set of supporting classes required for both server and client projects where WCF is involved.
In my C# solution I have:
- A Server project doing server type stuff
- A Client project doing gui type stuff
- A WCF Library containing class definitions for network passed data objects
The Server project uses a normal reference to include the WCF library. The Client project uses a service reference to the WCF library.
My problem is that I have a couple of utility classes that are needed in both the Server and Client projects which use object definitions contained in the WCF library. I don’t want to have two (identical) copies of these classes placed in the Server and Client projects – I would prefer just maintain the one copy. That would suggest using a class library, but how does the referencing work then? This new class library would have a standard reference to the WCF Library, and then both the Server and Client projects would have to standard reference this new class library in turn. But wouldn’t then the Client project now have two differently defined definitions of the data objects classes contained in the WCF library? How else should these utility classes be included?
Using the service reference approach takes some of the initial sting out of using WCF because it generates code for you that simplifies your life in those early WCF days. However, as you grow more accustomed to using WCF and you realize what the service reference is actually doing, you begin to realize that the service reference approach is sometimes more of a hindrance than a help.
For example, in my case, I had a WCF service that was used by three different projects – two C# projects and one managed C++ project. Everytime I updated the WCF service interface, I had to go re-generate the service reference in each of these three projects. It quickly became a headache for me.
In addition (and you’re running into this), the service reference approach only deals with the structure of your DataContract classes, not their behavior. So if you add convenience methods to the DataContract classes on the server side, that behavior must be manually added on the client side because it is not conveyed via the metadata exchange (MEX) operation.
That’s when I stumbled across this video. In it, Miguel Castro presents a convincing case to avoid using the service reference approach altogether. And when you examine his argument, it really makes a lot of sense.
Based on his recommendations, I would suggest putting your DataContract classes and the classes that operate on them in a class library that is referenced directly (no service reference) by both the Client and Server. As you will see from the video, it is pretty straightforward to write the client-side code yourself and just update it when your WCF interface changes.
I have used this approach now for a couple of months, and I have found the solution to be much more flexible to the way I use WCF than using the service reference approach.