When I expose a WCF service using DataContact/DataMember attributes, each service reference I make in other projects to this service generates classes with DataContract/DataMember attributes (as well as IExtensibleDataObject interface implementation, etc.).
In another project, I have to use a SOAP service whose WSDL has not been generated by WCF, but by some other tool I don't know and can't change the behavior.
My problem is that the code generated by my svcutil proxy is a little bit less flexible:
- The classes use the Serializable attribute instead of DataContract (GeneratedCode attribute specifies the use of System.Xml instead of System.Runtime.Serialization)
- IExtensibleDataObject is not implemented
- OptionalField attributes are not used
- Order of XmlElement is fixed, which results in deserialization fails when a new xs:element is inserted in the middle of a wsdl xs:sequence...
What happened in the svcutil tool / the wsdl I use, that it has to generate code in this way?
The Svcutil.exe tool can be used to create client proxies for both WCF and ASMX services. When Svcutil.exe is used create a proxy from an ASMX service, the data types that are generated in the code usually use XML serialization.
http://msdn.microsoft.com/en-us/library/cc304837.aspx
UPDATE:
My best guess is it is the schema specified in the WSDL determines which serialization has to be used by the the svcutil.exe.
The namespace of data contract serialization schema is http://schemas.microsoft.com/2003/10/Serialization and you can get much details about that here.
So if the svcutil sees this schema specified in the wsdl then it go for data-contract serializer else the xml serializer.
I also checked with WSDLs of WCF and ASMX. The WSDL of WCF service contains the following XSD sections and they are missing in the ASMX's one.