Now I'm using XmlSpy for generating C# program code from a XSD file.
My problem is when I do some changs the XSD file then I need to regenerate
new code every time, which is vary imflexible.
eg.
<xs:element name="AttributeName">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="FirstName"/>
<xs:enumeration value="LastName"/>
<xs:enumeration value="ID"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
When I added new enumeration values, I need to regenerate new codes.
Should I use a different namespace for restriction values or any suggestion
Thanks.
XmlSpy - code generation for XSD
Hot Topic
- VERY slow binary serialization of strings coming from SQL
- Dataset Events
- VB 2005 Express - example database project
- When to call dispose when using SqlConnection and SqlCommand?
- SqlDataSource/DataField Bug in 2.0 ?
- Error with DLL in network application
- how to set the dataset's namespace
- Problems with TableAdapter
- How to use CredentialCache & DownloadFileAsync for Local Network
- How i get new ID after inserting data in table through command.ExecuteNonQuery
XmlSpy - code generation for XSD
WreckinCrew
There are 2 ways to do accomplish this.
1) Code First Approach
2) Contract First Approach
In the Code First approach, you build the C# message classes, decorate them with Xml Serialization attributes and let the XSD.exe tool create the schema that matches your code.
In the Contract First approach, you do something similar to what you are doing, write the contract first (aka the schema) and then write the code to match it. A slight variant to this is to use a tool like XmlSpy or XSD.exe to generate the C# code.
In either case, if you make changes to one set of code, you need to make the corresponding changes to the other set of code. You can either let a tool do it for you (like you are doing), or go in and make those changes yourself.
Contract First is my prefered method, because you are explicitly reminded that everytime you have to make a change, you have to worry about versioning and backward compatibility. There is a very big debate over the use of Enmunerations, since they seem to change often. If you just are adding new entries, this isn't too bad, since you are backward compatible. But if you delete an entry or change the meaning of an entry, then you really need to create another major version of the schema. The common method of major versioning of schemas is by placing the major version number in the schema name and the location. Minor version numbers are commonly place in an attribute off the root element.
Don Demsak
MVP - XML
www.donxml.com