S h o r t S t o r i e s

// Tales from software development

Problems with xsd.exe

with one comment

I’ve been using Microsoft’s XsdInfer.exe and XsdObjectGen.exe utilities since they were released seven or eight years ago without any problems but about a year ago I needed to generate C# class source code for a complex set of schemas and found that the task was beyond XsdObjectGen.

The xsd.exe utility that ships with Visual Studio and the Windows Platform SDK supercedes XsdInfer.exe and XsdObjectGen.exe but while I’ve used xsd.exe to generate custom datasets over the past six years I’ve never used it to generate XmlSerializable data classes. So, it was a relief to find that xsd.exe successfully the C# classes  I needed and that these performed without any problems.

Over the past few weeks I’ve been updating our build processes and this seemed to be a good opportunity to phase out XsdInfer.exe and XsdObjectGen.exe in favour of an up to date distibution of xsd.exe.

In hindsight I shouln’t have wasted the time and effort because I just encountered one bug after another. Do a search for xsd.exe at Microsoft’s Knowledgebase web page:

http://support.microsoft.com/search/default.aspx?query=xsd.exe

and you’ll get a list of 21 bugs and problems.

Even when I wasn’t encountering bugs, the data classes it generated appear to be a step backwards. For example, repeating elements are represented as arrays without an IEnumerable implementation so that the foreach() syntax I’ve happily been using for years can no longer be used.

Amongst the behaviour that I’d classify as odd if not an outright bug is that when using inferring an XSD from an XML file, an attribute on an element causes it to be treated as a repeating element. If the intention is for the element to be a single item then this requires that the element is referenced as the first element type in an element type array rather than just the element type, e.g.

ConfigurationFile configFile = myClass.ConfigurationFile;

 
must be replaced with

ConfigurationFile configFile = myClass.ConfigurationFile[0];

 
which implies that there might be multiple ConfigurationFile elements.

This can be fixed by editing the XSD created by xsd.exe but this is not a viable solution in our automated build processes.

A related problem that definitely is a bug is that in some circumstances the serialization attributes in the class code generated by xsd.exe do not correctly describe the types being serialized. This shows up as a serialization failure at runtime with the following error messages:

Unable to generate a temporary class (result=1).
error CS0030: Cannot convert type 'xxxxxxxx[]' to 'xxxxxxxx'
error CS0029: Cannot implicitly convert type 'xxxxxxxx' to 'xxxxxxxx[]'

 
Examination of the class code shows that the the relevant XmlArrayAttribute has been specified with typeof(xxxxxxxx) when it should be typeof(xxxxxxxx[]). There’s a good blog post on this problem here.

Advertisements

Written by Sea Monkey

September 12, 2011 at 8:00 pm

Posted in Development

Tagged with ,

One Response

Subscribe to comments with RSS.

  1. Thank you for this,
    It is quite useful to know as I am evaluation an xsd to classes tool right now.

    Fabian

    November 2, 2012 at 4:26 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: