One of the apps we inherited from the London office in the dotCoop suite was a neat little exe which extended the functionality in xsd.exe. It altered the CodeNamespace it generated from an XML Schema into something a bit more useful, using this article as a basis for what it did. I’m delighted to say that while it hasn’t been made completely redundant, xsd.exe 2.0 now supports a couple of features which had to be written into the Extender.

  • You can now pass multiple schema files to xsd at once
  • xsd now creates properties backed by private fields for schema elements and attributes rather than the public fields it made in v1.

Unfortunately, it still doesn’t capitalise property or class names if they aren’t capitalized in the schema or play nicely with enums, but it’s definitely an improvement. What’s interesting now is how the whole app needs to be re-evaluated because of changes in how System.Xml.Serialization and System.CodeDom have changed. Simply importing the app into a .NET 2.0 project and compiling brings up several warnings of obsolete calls and running it generates a significantly different class file to the one it made in .NET 1.1.

For better or for worse, I’ve been using this as an opportunity to try out Test-Driven Development in advance of the dotCoop rewrite. It’s also been an excuse to try out VSTS2005 and learn something about System.CodeDom and System.Xml.Serialization. The office has a copy of the Newkirk book which is a good start but its main example is developing a Stack object, noticeably more straightforward than an app which takes schemas and develops C# classes. Translating “Check that a schema with this element type translates into an appropriate C# class” into a test is more of a challenge, but worthwhile. It ends up looking something like this.

public void CheckCapitalisation()
   xsd = CreateSchemaWithComplexTypeElement(
      targetSchemaNamespace, rootElementName, complexTypeName);
      xsd, elementType, elementName);

// Run these two calls in the app
CodeNamespace ns = xe.GenerateCodeFromSchemas(schemas);

Capped(complexTypeName), ns.Types[0].Name;

TDD forces you to understand how code works that much better than working without tests. It’s a steep learning curve but does flatten out after a while. VSTS helps it flatten out faster as well with its built in Test Manager and refactoring utilities. Something said back in February remains oh so true as well. Your test code needs to be written as well as, if not better than, your actual app code. If it isn’t immediately apparent what your tests are testing they probably need some attention. Likewise, those tests need to test all your app code. The VSTS Code Coverage tool will help with that.