Anyone who talked to me at any point between May 2008 and July 2008 would've heard me whining about how awful SvcUtil can be. If you don't know what SvcUtil is, then you haven't done enough with WCF to really understand what's going on. If this is working out for you, then go on in blissful ignorance; read no further.
If you're still reading, and you know what SvcUtil is, then there's an excellent chance you only know because you've run into issues with it generating duplicate type definitions in your service's proxy. Well, the semi-good news is that, SvcUtil is the sickness and the cure. There is a way to get SvcUtil to tell you the problems with your data contract(s). But before I go further, now seems as good a time as any to inject a rant/disclaimer:
I still believe SvcUtil is a pile of monkey excrement and that the architect(s) responsible should blush with embarrassment every time WCF or SvcUtil is mentioned. If the Microsoft Kool-Aid is made with ridiculous amounts of GUIs and designers and nifty little tools I can click around in to get the bits I need while creating my solution, shouldn't those things be designed intelligently enough that they at least pinpoint the areas of my code which are causing it problems? For the love of single button mice, if you're going to give me tools that encourage me to be blissfully ignorant of the guts I'm working in, at least make the tool alert me when I do something spectacularly idiotic.
Ok, now that that's out of my system (for the moment), the way to determine the cause for your pain in this case will lead you to the command line. For my example, let's pretend we have a single assembly with all the data contracts and it's living at "c:\folder\Data.Contracts.dll", the command line you'll want to use is:
svcutil /target:metadata /dconly c:\folder\Data.Contracts.dll
One of two things will happen: either you'll get a list of XSDs (one for each namespace in the assembly) or you'll get an error which tells you what's preventing SvcUtil from generating a set of data contracts that is DataContractSerializable. This is valuable information because the thing that's causing SvcUtil to flip out and re-create all your data contracts in the proxy is that if *any* of the classes are not DataContractSerializable compliant, then *all* of them will be serialized by the XmlSerializer instead.
Hopefully this will be as helpful to you as it was to me. After having this problem come up multiple times for several reasons, I got angry enough that I started reading everything I could find on SvcUtil specifically. We have over 60 business objects at this point which means that playing "pin the diagnosis on the bad contract" becomes a trail and error filled time-sink. Fortunately after using this approach I had my solution in 10 minutes.
Tags: