Xml xsd.exe
The serializer uses this when both serializing and deserializing. If it’s true, then there is a value, otherwise, there isn’t. In order for the XmlSerializer to know that this optional property has a value, there is an additional property, CategorySpecified, to tell the serializer that there is indeed a value.
#XML XSD.EXE CODE#
So how does the Xsd.exe tool do this? Consider the category attribute the tool generates this code (kinda, I had to make it better): And how do we represent value types that don’t have a value set? Not elegantly, for certain. Remember that I said the schema defined the timestamp element and the category attribute as optional? In the generated class files, these values are represented by value types. This is what I really want to talk about. However, note that in both files, there is a pattern for value types. (I typically use the tool, keep the source files, and throw away the schema.) These attributes are useless for my scenario, but may be used for some of the other scenarios that Xsd.exe supports. The classes are partial and liberally sprinkled with oodles of design-time attributes. With tools like ReSharper, it’s pretty easy to add properties and constructors to make the type more usable.Ĭontrast that with the 2.0 version: properties are there now, but they still don’t take advantage of the XmlElementAttribute overload that will take a tag name. lots of complex types), then modifying what the tool gives you will save you some time. In this contrived case, I’d probably save some browsing around in a command shell by writing the whole thing myself, however, once the schema gets large enough (i.e. You should feel compelled to take what the tool generated, and add to it so it doesn’t suck so much. You’ll see in the V1.1 file that what you get is quite appalling: public fields (aaaaaagggh), incorrect casing, etc. So if I pass that mother through the tool, I’ll get C# code on the other end.Ĭlick here for the code generated by Xsd.exe V1.1.Ĭlick here for the code generated by Xsd.exe V2.0. Like I said earlier, I use Xsd.exe to generate class files from a schema. This is another entry taking advantage of the fact that I don’t need a timestampĪlthough the details of the schema aren’t important, there are two things I’d like to point out: Both category attributes (which are typed to long, an XML Schema-way of saying Int32) and timestamp elements are optional. Suppose I have an XML schema that defines a log file. It generates some truly heinous code for you, embarrassing code if the code were a person, it’d wear jogging pants to a wedding, laugh at the worst jokes and have terrible teeth. I use it to generate class files from a schema that typically is beyond my control. Likewise, Xsd.exe is pretty handy a Swiss Army-knife like XML tool, it can take an assembly and produce a schema of the types it can take an XML file and generate a schema based on that file give it a schema to generate C# or VB classes or a strongly-typed DataSet give it a kitchen sink, it’ll do something. There are times when you have no choice to use XML, but with the XmlSerializer, you can hide most of the XML and use normal classes. NET came out, was all: “XML! XML! XML! Use XML everywhere.” I detest working with XML, but there are tools that make it bearable like the XmlSerializer.
There is a lot of support, which is handy, because of Microsoft’s marketing message, when. NET, and it’s true, is that it has built-in support for XML.
One of the big things Microsoft has said about. You’ll see that they’ve fixed some issues, but there is still a lot left that they can do. NET 2.0 was just released, I began trying out a few things to see if they fixed things. There are a number of things that aren’t satisfactory about both of them, but this post only talks about a few of them. At work, I’ve been using Xsd.exe and XmlSerializer in V1.1 a lot lately.