I'd like to generate the classes the xsd.exe way and not the linqtoxsd way.
Thanks, --Ran.
+6
A:
Look at the System.Xml.Serialization.XmlCodeExporter class.
UPDATE (in case John Saunders didnt bother reading further)
"Xsd.exe uses XmlCodeExporter to generate classes from XML Schema Definition (XSD) documents."
leppie
2009-07-01 09:54:09
"This API supports the .NET Framework infrastructure and is not intended to be used directly from your code"
John Saunders
2009-07-01 09:55:37
I been using it since 1.1, is there a problem with it?
leppie
2009-07-01 09:58:32
"is not intended to be used" doesn't mean "cannot be used" ;)
Thomas Levesque
2009-07-01 10:01:55
+1 for that info. I always thought launching xsd.exe in a process was the only solution. :-)
Cerebrus
2009-07-01 10:08:25
@leppie,Thomas: it depends on whether this code is important to you. "infrastructure" code is subject to change without whining. After all, they've only told you not to use it since .net 1.1.
John Saunders
2009-07-01 11:01:30
@leppie: XSD.EXE was written by the same company who wrote that bit about XmlCodeExporter being infrastructure. I bet the XSD.EXE people may even work in the same building as the XmlCodeExporter people. They only need to pick up the phone or send an email in order to screw you up - and not screw themselves up.
John Saunders
2009-07-01 11:03:20
@John: Sure go ahead, I'll wait till .NET 6 for it to be removed, in say 10 years or so.
leppie
2009-07-01 12:54:27
@leppie: they don't need to remove it to screw you up - just change it in a way that breaks your code. They get the right to do that, considering they've told you since .NET 1.1 not to use this.
John Saunders
2009-07-01 15:23:32
@leppie: besides, doesn't this pretty much duplicate the functionality of XSD? There's not a lot of ability to customize the code generation.
John Saunders
2009-07-01 15:33:46
Thanks for the answer, Here is a good example on how to use it to generate the code:http://www.clariusconsulting.net/blogs/kzu/archive/2003/10/24/96.aspx
Ran
2009-07-02 08:59:48
+1
A:
Which part of the process do you not know how to do?
You can load one or more instances of the XmlSchema class into an XmlSchemaSet. This will allow you to programmaticly examine all parts of the schema and other schemas it may reference. You can use this information to generate code, either as text that will later need to be compiled, or else using the CodeDOM. See Dynamic Source Code Generation and Compilation.
If you are generating code in the context of Visual Studio, then I'd suggest you do so via T4 Templates. See Generating Artifacts By Using Text Templates.
John Saunders
2009-07-01 09:55:03
Due to the complexity of XML Schema, parsing it myself and generating the classes from it would be a nightmare, to say the least.
Ran
2009-07-01 10:04:27
I didn't suggest you parse it yourself. You load a single schema by using XmlSchema.Load, then add the result to an XmlSchemaSet. Add all the schemas you need to that set, then you can "compile" it to validate it and fix cross-references; finally, you can walk the structure and generate your code.
John Saunders
2009-07-01 11:00:08
I'm sorry, I meant to say walking (not parsing) the structure.I don't know how much you're familiar with the SOM or the XML Schema spec. but it's a big and rather complicated task to generate code from an XML Schema (even when considering that you should support only a subset of the XML Schema spec. that could actually be translateable to code straight forward)this is why I prefer to re-use code for that matter.
Ran
2009-07-01 13:34:33
I'm very familiar with the SOM, which is why my choice would have been to generate code based on T4 templates driven from the SOM.
John Saunders
2009-07-01 15:22:15
+2
A:
You can call xsd.exe from your code using Process Class. I did it once and its fast and straightforward. You won't need to bored much :).
Ricardo
2009-07-01 09:57:40