XmlTypeAttributes in proxy classes

Topics: Service Factory Modeling Edition Forum
Mar 25, 2008 at 12:55 AM

Just wondered if there's some sort of known issue (the we don't know about!) before i start posting contracts / code samples.

When generating a proxy class via the Deployment Host, the resulting proxy class contains System.Xml.Serialization.XmlTypeAttribute types for all types exposed from our data contract, along with duplicate members marked up with System.Runtime.Serialization.DataContractAttribute.

If we manually create the proxy (without specifying the serializer) using:
svcutil http://localhost:2020/Test.svc /out:TestProxy.cs /namespace:*,Test.ClientServiceBroker.CardDataServiceProxy /noConfig

the correct proxy class is created. So it seems the problem lies in the Deployment Host maybe using the XmlSerializer or something ? We've double checked that the service / datacontract all specify the DataContractSerializer, and WCF as the implementation technology. Is there maybe some rogue metadata lying around somewhere which could cause this?

Mar 25, 2008 at 1:00 AM
Edited Mar 25, 2008 at 1:06 AM

I was wrong, the proxy created manually above does contain duplicates, so we get:

System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "")
public partial class Farm : object, System.Runtime.Serialization.IExtensibleDataObject

and then later on in the file:

System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "3.0.4506.30")
public partial class FarmType

So i guess the question is, what might the cause be? If i add the DataContractSerializer option to the svcutil command, none of the datacontract types are included...
Mar 25, 2008 at 4:28 AM
Cool, runnig my own discussion :-)

The issue is solved - i'm not sure yet how :-(

I grabbed a previous version of the service / datacontracts from TFS, then proceeded to manually rebuild them working towards the current version - periodically generating proxy classes to check the result. I've now fully rebuilt the contracts with no {obvious} difference (i didn't actually compare the source of the contracts or the designer files but it all looked identitcal on the design surfice)...

Possibly there was some illegal construct that caused the DataContractSerializer to fall back to XmlSerializer?
Mar 26, 2008 at 6:43 AM
That might be one reason. Another reason might be if you are using version 2005, a bug was fixed regarding this issue.