XsdTidy is a refactoring tool to overcomes some silly limitations of the exceptional Xsd.exe  tool provided with the .NET framework. More specifically, XsdTidy addresses the following problems:

• Name normalization: if your XSD schema is using lower case names or more generally non ".NET" normalized names, you will end up with types that will make the FxCop spit out hundreds of infractions,
• Fields not properties: xsd.exe creates fields and does not "hide" them in properties which is bad OO design.
• Fixed Array Sizes: xsd.exe handles multiple elements by creating an array. There is no problem when you are loading the data, but unfortunately this is not convenient if you want to populate a document since arrays do not support Add or Remove. XsdTidy provides strongly-typed collection that support Add, Remove, etc...
• Default Constructor: Xsd.exe does not care about providing a default constructor that initializes the fields with the proper values. If the object structure is getting big, it becomes very difficult to properly initializes fields,
• Serializable: Xsd.exe does not tag classes with serializable

Note that XsdTidy uses Refly for building the source code and is also maintained by Marcus Mac Innes.

What does XsdTidy fix ?

Name conversion

The .NET standards define specific naming convention for all types of data: arguments should be camel case, function names capitalized, etc... This is really helpful to keep the framework consistent. Tools like FxCop help us stay on the "normalized" side.

This problem is tackled the dumb way: given a dictionary of "common" words, the class NameConformer tries to split a name in separate words, after that it renders it to the needed convention. Of couse, this feature can be disabled.

FixedArraySize and "Multi" Strongly-Typed Collections

Arrays are replaced by inner strongly-type collections which are much more flexible to use. Moreover, array fields are created by default using their default constructor. This is to economize you the hassle of creating a collection before using it. If an array can support multiple object type, the generate collection will be "multi" strongly typed:

public class TestClass
{
    [XmlArray("values")]
    [XmlArrayItem("car",typeof(Car));
    [XmlArrayItem("car",typeof(Bike));
    public Object[] values;
}

becomes

public class TestClass
{
    private ValueCollection values = new ValueCollection();

    [XmlArray("values")]
    [XmlArrayItem("car",typeof(Car));
    [XmlArrayItem("car",typeof(Bike));
    public ValueCollection Values
    {
        get { return this.values;}
    }

    public class ValueCollection : CollectionBase
    {
        public void AddCar(Car car)
        {
            this.List.Add(car);
        }
        public void AddBike(Bike bike)
        {
            this.List.Add(bike);
        }
        ... // the implementation of the collection
    }
}

Properties

Fields are hidden in properties, which is more convenient to use. Moreover, collection fields do not have set property according to FxCop rule.

public class testclass
{
    [XmlAttribute("values")]
    public String values;
}

becomes:

public class TestClass
{
    private String values;

    [XmlAttribute("values")]
    public String Values
    {
        get
        {
            return this.values;
        }
        set
        {
            this.values = value;
        }
    }
}

Serializable

The output classes are tagged with the Serializable attribute to make them usable using Remoting.

XsdTidy history

I have first started to build XsdTidy using System.Reflection.Emit. It was a titanic job and very error prone. The difficulty of using Emit pushed me to use CodeDom which was also heavy to use. So finally, Refly was designed and XsdTidy became much easier to impement.

Download:

Download XsdTidy and Refly at http://blog.dotnetwiki.org/downloads/Refly.zip

Screenshot