We were given external SOAP services that we have to consume in our project. All of these provide WSDL data, but a lot of them are not .NET services (most of them were written in Java). We have generated a number of client proxies with wsdl.exe tool. This tool does what it's supposed to do, it creates proxies for us to consume.
The problem appears once we try to call methods on these services using generated proxies. We intercept all SOAP requests for logging purposes and XML data looks different from the one specified in WSDL schema.
For instance, if a field is called "Name", our proxies will serialize it as "nameField". I guess this is because the property called "Name" uses a backing field called "nameField". Services on the other side obviously can't interpret this kind of naming convention.
This wouldn't be happening if our ASMX proxies used the old XmlSerializer, but for some reason they opt for DataContractSerializer, which completely messes up serialization and breaks compatibility between clients and services.
My colleagues have resorted to manually constructing XML data and then sending it with HttpWebRequest class. I think this is completely unacceptable in 2011, this is what automated proxy generation is for.
My question is: why is this happening? Why are our proxies using DataContractSerializer and thus ignoring all xml serialization attributes in the process? Is there a way to force them to use XmlSerializer once again?
We use .NET 4.0.
If you are using WCF the default is DataContractSerializer. And if the types do not have explicit [DataContract]/[DataMember] markers, then DataContractSerializer will use the fields, which sounds like what is happening.
To use XmlSerializer instead, add [XmlSerializerFormat] to your service. See MSDN.
You could also try adding [XmlType] or [XmlRoot] to your classes (if it isn't already there).
来源：https://stackoverflow.com/questions/8246676/forcing-asmx-proxy-to-use-xmlserializer-instead-of-datacontractserializer