Decomposing XSD and WSDL into abstract definitions of types and messages is a good thing, but it appears that Microsofts tools dont adequately support embracing this approach? Or, I'm completely sans clue. For example, XSD.exe doesnt seem to be able to cope with xs:import elements when generating wrapper classes. WSDL.exe has the same problem.
Anyone have any thoughts on this? I'd like NOT to wait until Whidbey to be able to describe my messages and contracts and generate a schtickel of code. Updated with Note: Rant retracted...for now! See below ;)
Heres a very trivial example straight from Dare's great MSDN Article.
<?xml version="1.0" encoding="utf-8" ?>
<xs:complexType name="rootType" >
<xs:element name="child1" type="xs:string" maxOccurs="2" />
<xs:element name="child2" type="xs:string"/>
The Outer xsd:
<?xml version="1.0" encoding="UTF-8" ?>
<xs:import namespace="http://www.import.org" schemaLocation="file:///c:/import.xsd"/>
<xs:element name="root" type="imp:rootType" />
This schema appears to be valid in fact, the .NET framework agrees. But when you try and run the outer schema through xsd.exe, you get the following error:
C:\>xsd /c root.xsd
Microsoft (R) Xml Schemas/DataTypes support utility
[Microsoft (R) .NET Framework, Version 1.1.4322.573]
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
Schema validation warning: Type 'http://www.import.org:rootType' is not declared. An error occurred at file:///C:/root.xsd, (10, 3).
Warning: Schema could not be validated. Class generation may fail or may produce incorrect results.
Error: Error generating classes for schema 'root'.
- The datatype 'http://www.import.org:rootType' is missing.
Update: Tomas was kind enough to point out not only that I had originally posted the same schema TWICE, doh! But also, more importantly, that XSD.EXE doesn't resolve schemaLocation on imports or includes, presuambly because the W3C Schema spec describes the schemaLocation attribute as a hint, not a true location.
I'm back in business as I ran XSD.EXE again with all necessary files specified on the commandline, in order to give XSD.EXE a choice of namespaces - as opposed to hoping it would somehow glean my intent!
I'm too used to using XMLSpy, XSLT and other tools for generating CS code. Good stuff, thanks Tomas! Not only was I without a clue, I was also sin una pista, sans indice - Ich war ohne einen Anhaltspunkt. That'll teach me not to post a rant in haste!