Creating Schemas from Assemblies

Creating a schema from a compiled .NET assembly is as simple as creating a schema from a sample XML document. The XSD tool will extract the XML layout for all public classes in the assembly and combine them in an XML schema.

Extracting a Schema

You indicate to xsd.exe that you want to create a schema from an assembly simply by providing a file name with an “.exe” or “.dll” extension. No additional command-line switches are required. To see this in action we need to build an assembly “garage.dll” with the code file in listing C.3 and then run the assembly through the XSD tool:

xsd.exe garage.dll

The output is a schema file schema0.xsd. The schema contains elements and type definitions for the public classes in the assembly, unless a class is decorated with an XmlTypeAttribute with the IncludeInSchema property of set to false.

9           Listing C.9 Schema generated by the  XSD tool from an assembly.

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema

  elementFormDefault="qualified"

  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="garage" type="garage" />        | #1

  <xs:complexType name="garage">                    |

    <xs:sequence>

      <xs:element

        minOccurs="0" maxOccurs="1"                 | #2

        name="desc" type="xs:string" />             |

      <xs:element                                   |

        minOccurs="0" maxOccurs="unbounded"         |

        name="car" type="garageCar" />              |

    </xs:sequence>

  </xs:complexType>

  <xs:complexType name="garageCar">                

    <xs:attribute name="make" type="xs:string" />   | #2

    <xs:attribute name="model" type="xs:string" />  |

    <xs:attribute name="year" type="xs:string" />   |

  </xs:complexType>                                

  <xs:element name="garageCar"                      | #1

    nillable="true" type="garageCar" />             |

  <xs:complexType name="NewDataSet">

    <xs:sequence>

      <xs:element minOccurs="0" maxOccurs="unbounded"

        name="garage" type="garage" />

    </xs:sequence>

  </xs:complexType>

</xs:schema>

(annotation) <#1 Each public class in an assembly results in and an element and its complexType definition. >
(annotation) <#2 The each public field of a class results in an element or attribute declaration in the schema. >

The generated schema contains three top-level elements and their type definitions, one for each class in the assembly: car, garageCar and NewDataSet. The type definitions contain an element, or an attribute, for each public field or property of the classes, depending on whether or not an XmlAttributeAttribute is present. The generated schema also reflects the array nature of the cars field. The schema defines the corresponding car particle in the sequence group of the garage type with a maxOccurs="unbounded" attribute, which means each XML instance of the garage type contains zero or more car elements following the desc element. Of course the conversion will take into account all other XML serialization attributes found in the assembly and create the appropriate XSD description. Section C.6.2 will show in detail how XSD and serialization attributes map to each other.

If you remember, the class in the assembly was originally created from the schema in listing C.2. While the schema in listing C.9 doesn’t look quite like the schema we started out with, the information in this schema is very similar. The schema in listing C.9 uses named complexTypes instead of anonymous, inline type declarations. There is no significant difference between using named and anonymous type definitions for the complexTypes car and garageCar in this simple case(!), but the extra top level element garageCar, makes a real difference when it comes to validating documents. The original schema did not define a top-level element garageCar. The element was added to the schema because the garageCar class definition was not nested within the garage class. The next section investigates this problem further.