xsd生成实体类相关问题

1.在xsd文件中可能存在相互嵌套的情况，这是xsd就无能无力了。

http://geekswithblogs.net/mnf/archive/2008/07/22/generate-c-class-from-xsd-file.aspx

<< Visual studio 2008 "Build action" properties: Shadow and CodeAnalysisDictionary | Home |"Login failed for user" may mean "database name is invalid" >>

Generate C# class from XSD file.

I have an existing C# file, generated a long time ago from XSD definition.

The XSD files were changed, and proxy class should be regenerated.

I've tried to use XML Schema Definition Tool (Xsd.exe) to generate C# class, but it  returned the error: "The datatype is missing".
I've actually have two XSD files -outer and imported

Thanks to the post: XSD.exe is kicking my butt, man...redux , it pointed me to specify all necessary files on the commandline.

Note that name of generated file is combined from the files listed

I've created the batch file to be able to rerun it 

CallXSD.BAT

@call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86

xsd.exe outer.xsd imported.xsd /classes /l:cs /n:MyNamespace

rem rename  outer_imported.cs as outer.cs

pause

By some reason the generated file created in some non-default encoding, which inserts 3 characters

 in the beginning.It is a minor annoyance, but when I delete them, VS shows me a warning, that wrong encoding could prevent keeping history.

The next issue was that the new XSD(.Net Framework 2.0 and 3.5) generates C# classes differently with what 1.0/1.1 XSD.exe did.

In a few places 1.1 version generated custom collection of objects, but new XSD.EXE generates array of objects, so I have to change the calls to generated classes.
Another problem with XSD generated classes is that it disables  step into debugging even on methods that you  extended in partial classes by specifyingDebuggerStepThroughAttribute for classes. Workarounds are described inXSD.exe and DebuggerStepThrough post.  Issue reported to MS Feedback.

I should try An XSD to .NET language code class generator that adds real punch to Microsoft's XSD Tool.
or Sample Code Generator 1.4.2.1

Another issue was that authors of XSD file added   xsd:choice  elements and it creates extra ItemsChoiceType array and enum.I described how I addressed it inmy post XmlChoiceCollection class to access XSD generated properties for choice XML elements

That's pity, that minor changes in XSD file causes different class properties to be generated and essential code  changes to access the new properties.

http://www.hanselman.com/blog/XSDexeIsKickingMyButtManredux.aspx

Decomposing XSD and WSDL into abstract definitions of types and messages is a good thing, but it appears that Microsoft’s tools don’t adequately support embracing this approach? Or, I'm completely sans clue.  For example, XSD.exe doesn’t 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 ;)

Here’s a very trivial example straight from Dare's great MSDN Article.

Import.xsd:

http://www.w3.org/2001/XMLSchema
targetNamespace="http://www.import.org" elementFormDefault="qualified"> 
        
           
                 
                 
           
     

The Outer xsd:

http://www.w3.org/2001/XMLSchema" 
targetNamespace=" http://www.example.org" 
xmlns:tns=" http://www.example.org"
xmlns:imp=" http://www.import.org">
http://www.import.org" schemaLocation=" file:///c:/import.xsd"/>

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!

http://msdn.microsoft.com/en-us/library/ms950721

Q: Why doesn't XSD.exe support the schemaLocation attribute on imports and includes?

A: The W3C XML Schema recommendation describes this attribute as a hint, which can be ignored by processors that can use alternate means to locate schemas. XSD.exe only uses schemas that are specified through the command line to convert schema A.xsd, which imports schema B.xsd.

xsd.exe /c A.xsd B.xsd 

Also, the wsdl.exe application, considered a sister application to xsd.exe, can be downloaded from the Web. If you do this and use the wsdl.exe, you would follow schemaLocation hints in imports and includes.

google得到虾下面的工具xsd2code，安装完成，但是vs中并没有出现这个插件，不知问什么，暂时还没哟解决。