I’ve recently been looking at code reports from FXCop and wanting to get a bit more info about the code I’m writing in Visual Studio 2008 Beta 2 … Seems that there is a hack/workaround in order to get the same style of code analysis in VS2008 as the VSTeam Editions have as standard (apart from the versions like Test etc …). I haven’t tried this yet but will be soon.
I don’t find myself working with too much XML at the moment, I’m sure that’s going to change soon enough! Anyway, I just wanted to include something on the blog about XSD.exe. This is a great little utility that is part of the Windows SDK and if you can’t afford to shell out for something like XMLSpy it can be a life saver, or at least a finger saver!
I’m migrating a development project from FoxPro to C# at the moment and needed to get some .XSD and class libraries built from a couple of XML files that I was using to build lookup cursors for various tasks in the old FoxPro application. Since FoxPro only really has the basics of XML support I hadn’t needed anything much more than the XML files themselves however now that its all heading towards C# and the .NET framework it makes much more sense to work with the XML data as intended with proper validation and so on. Anyway, there is a better tool out there for XSD creation called Infer.exe but since the GoDotNet site has vanished its proved even harder to find this tool on the behemoth that is the Microsoft web site.
Using XSD.EXE is dead simple … to create the .XSDs from the .XMLs in the command prompt replace <path> with your local paths to the files.
this creats filename.xsd in the same directory as the originl XML file.
<path>XSD.EXE /C <path>filename.xsd
this creates filename.cs – yup a nice little set of classes that represent the contents of the XML file ready for stuffing into your C# code for stuff like Serialization and so on. The one thing I have noticed is that you have to be very careful with the XML files that you use to build XSDs and the classes from. I’ve run into a few problems in the past with the classes not being defined correctly and needing some tweaking in order to get things right. Its mainly been problems like classes being produced with just fields when in fact they needed to be represented with arrays for multi-value nodes in the XML objects.
When using XSD.EXE it’s absolutely crucial that both the XML and the XSD files your working with are valid. It sounds obvious but if there are any issues with these files the C# classes that are built from them with XSD.EXE will be riddled with problems.
Problems with XSD made from incorrectly configured XML files will lead to more headaches that you can care for. For instance the XML files that were part of the old FoxPro app were acceptable to FoxPro but were in fact incorrectly formatted in a number of ways. Once I had corrected these problems I went on to make XSDs in XMLSpy and then used XSD.EXE to build the classes from there.
I manually configured a few constraints in the XSD files as well such as using the <xs:unique> constraint is maintain correct data integrity and I’ll need to incorporate similar code in C# to test any user configuration of new XML records once these files are user configurable in SampleSort. Following is a little code snippet that illustrates the use of unique value integrity inside XML XSD specifcation files.[source:XML]
Well this is truly awesome. I’m working on a major new development project using these technologies , talk about bleeding edge development. This is a really great opportunity to get stuck into some very new tech ahead of the game so to speak.
Really exciting to be involved in something this new and advanced!