LUKE PUPLETT

Problem and Background

A few weeks ago I got a message stating that I needed to add DataContractAttributes to my enums. I can't remember the details but I know I thought it was strange as it was all working without them. I added the attribute and got another message about not having EnumMemberAttributes on the actual enums values. I obliged and the errors went and I thought that was the end of it.

Today, while coding in the client app, I discovered that my types had properties with Specified appended. The suffix is apparently only added when you reference an old ASMX from WCF. But I'm not, so my suspicions were aroused. Furthermore, my setup is that I reference a shared assembly so I shouldn't have generated types at all..!

Solution and Bug

Had I setup some decent tests then I should have spotted the problem as soon as the change was made three weeks ago because - and I really dislike WCF for its ability to throw a curveball in your face every day - the root of the problem became clear when I rolled back and forward my enums.

It appears that the codebase was alright again (no errors) with the version that didn't include the DataContracts on my enums. While in the source, I noticed that I'd missed decorating EnumMember on some of the values.

I then rolled back again to the working snapshot and added DataContract to the enum but did not add EnumMember to anything. The result was that my working codebase broke - that is, when I updated my client service reference, types were generated and not re-used from the shared DLL.

You guessed it: adding EnumMember to all members of the enum with the DataContractAttribute and recompiling, re-updating the reference, fixed it again so I was re-using my shared lib.

This has got to be a bug. The compiler or the WSDL page should be spitting feathers and not letting me continue to code with the corrupted service state.

Update 1

This morning, after settling on the conclusion that I needed to add EnumMember to all my enum values I found that this actually didn't solve the problem and the solution was to remove all DataContractAttributes from all enums which meant foregoing my service having corporate domain namespaces for every single type - although I will look into using the assembly-level ContractNamespaceAttribute attribute.

Update 2

Further tests show that svcutil making a mess of things might only occur when FlagsAttribute is also applied.