Lesson learnt: Implement IXmlSerializable to override Wsdl definition (Part II)

It is fine to override IXmlSerializable if you only intend to use XmlSerializer. If you want to generate web service wsdl definition as well, there is a problem. Our http://MyNamespace.Jingye.com/SomeWebService.asmx?wsdl gives you something like this:

<s:element minOccurs="0" maxOccurs="unbounded" name="Foo">
<s:complexType>
<s:sequence>
<s:any namespace="http://mynamespace.jingye.com /Foo" />
</s:sequence>
</s:complexType>
</s:element>
…

<s:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace=" http://mynamespace.jingye.com" id="Foo">
<xs:element name="Foo">
<xs:complexType>
<xs:sequence>
<xs:element name="MemberVar" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</s:schema>

Although look like we have the schema definition for Foo and would be able to use it to validate a Foo object and provide type info for de-serialisation. It is not. Any short-circuits our wsdl tool to combine external and internal schemas into one service description. If the message object is of a different XML namespace than the service, duplicate schema information is generated in the subsequent WSDL file (one for the correct XML namespace, and one for the service). If your message object is of the same XML namespace as the service, then the WSDL generation fails because the document can't contain the same namespace twice. In either of these cases, you do not get the behaviour that you are looking for. Article WSE 2.0: Give Your Web Services Consumers the Exact XML They Need to Succeed explains this.

It seemed that .NET Framework 2.0, this problem is solved by allowing the object to return an element of a schema instead of an entire schema document, which makes it possible to merge schemas during the WSDL generation step. Read this "New Features for Web Service Developers in Beta 1 of the .NET Framework 2.0".