The "right" thing to do, is for the XSD tool to be changed so that it spit
out 1 .cs file per .xsd file - that is each .xsd that is imported or
including needs its own source file.
The tool doesn't do that though, so the work-around I have come up with is
to use only and exactly 1 xsd that actually has elements in it.
All the other xsd have complex types and the final xsd has a common header
block and then a choice in it so the same xml file can store any of our
defined files types.
By using only 1 xsd with elements, the XSD tool will spit out only 1 source
file (thus everything is in the same namespace and there's no collisions).
The additional advantage here is that the extension on the file no longer
matters, we can tell what the data is from the choice block inside it.
Additionally you would need to make your xsd application data a complex type
that extends the base type. Then the generated application XML class will
derived from the generated base class.
> I have some 'base' schema definitions that are going to be in several
> projects in the future. The processing of resulting classes created
[quoted text clipped - 65 lines]
> Roy Chastain
> SOHO Technology Solutions, LLC
Roy Chastain - 21 Sep 2007 18:36 GMT
Thank you for your response, but I must stay that I do not understand all of it. Could you give me a small sample of what you are
describing?
Thanks
>The "right" thing to do, is for the XSD tool to be changed so that it spit
>out 1 .cs file per .xsd file - that is each .xsd that is imported or
[quoted text clipped - 85 lines]
>> Roy Chastain
>> SOHO Technology Solutions, LLC
-------------------------------------------
Roy Chastain
KMSYS Worldwide, Inc.
http://www.kmsys.com