XSD.exe and imports – a solution

If you’re reading this right now, it’s likely because you just discovered that XSD.exe doesn’t honor import declarations within XSD files.

It sure caught me and several others by surprise.

The fix, it turns out, is to manually specify each XSD that the primary XSD requires. Something like  xsd.exe primary.xsd imported.xsd another.xsd

In my case, my primary XSD file imported several XSD files… those those imported XSD files imported their own XSD files.. And putting that nasty command line together manually is just too far below my pay grade. 

6/7/2016 UPDATE: Per one of the comments below, I have updated the code to support XSD files that reference external schemas via a URI instead of a local file. For each URI encountered, I download the file locally and continue as normal.

So if you haven’t already, install LINQPad. Then just copy/paste this script into a new LINQPad file and change the path on line 3 to point your XSD file. Press F5 and TADA!

It digs through the XSD files recursively AND spitS out exactly what you need to copy/paste into your command line to make XSD do your bidding.

And, by golly, it works well!

Given a sample file from one of the comments below (http://www.mf.gov.pl/documents/764034/5134536/Schemat_JPK_FA%281%29_v1-0.xsd), this utility outputs the following. Note the yellow text at the bottom. That’s the magic line you need to copy/paste into your .NET developer console to generate the scripts.

An apology

It’s probably the ugliest code I’ve written in a month. And it was written really quickly. And I can only confirm that it works for my needs. And I tried to do this in Powershell since everyone already has Powershell, but I couldn’t get it to work because Powershell is the devil.


Viva la LINQPad!!!