Ali Aghareza posted a reply to my earlier messages with a really insightful example that presents one reason for ASP.NET to change the element name the type is serialized as: when the method returns two different instances of the same type.
However, all is not that rosy. If no element name is specified in the type's XmlRoot attribute, then ASP.NET will default to serializing the type with the
This behavior, however, breaks if you specify an element name in the types XmlRoot attribute, since the serialization will break (multiple elements with the same name introduced). This can be avoided, though, with careful use of the XmlElementAttribute in the method's signature.
Which brings me to another tricky little detail: Using the XmlElementAttribute without filling in the namespace argument can lead to unexpected results. Consider this new code:
<%@ WebService Language="C#" class="Weird2" %>
[ XmlRoot(Namespace="/schemas/client") ]
public class Client
[ XmlAttribute("id") ]
public int ID;
[ XmlElement("name") ]
public string Name;
[ WebService(Namespace="/services/Weird2") ]
public class Weird2
[ WebMethod ]
[ return: XmlElement("client") ]
public Client GetClient(int id)
Client c = new Client();
c.ID = id;
c.Name = "Tomas";
This code, when invoked via SOAP, will return something like this:
Notice how the client element is now serialized outside the /schemas/client schema and instead is serialized in the WebService's default namespace. The reason I point this out as a potential problem is that since the Client type is serialized with an attribute, that attribute has just been left hanging, too (Yes, I'm aware of the special way attributes fit within XSD).
OK, maybe it's not a problem, but I sure as hell know this wasn't what I originally expected to happen :)