Pointless Fiddling: XML Deserialization vs DataSets

I was tinkering with one of my pet .Net 1.1 applications this evening ("They're my friends. I make them. I make my friends! ") - I figured I'd try to get the hang of XML Serialization by trying to deserialize a SQL Reporting Services report. The reports are very useful for amateur dabblers like me, as they have an Export to XML option that can be invoked through the web interface, or directly from a URL. If there's useful information in a report, it needn't be an island...


The deserialization process was a bit more fiddly than I expected, but still laughably simple compared to brute-forcing it yourself.


Dare kindly pointed the XmlSerializer out to me when I suggested on an internal DL that I'd really like a simple API that you could, say, throw a schema at, and get back “real” objects. Naturally, it existed, I just hadn't stumbled across it. In the end, the example I ended up working from was the Longhorn Communications History RSS sample. Using the techniques in rssparser.cs, I had a working object hierarchy within an hour, which would deserialize directly from the Reporting Services XML.


I had problems early on, basically because I'm someone that tends to learn by doing and not reading the documentation, but solved them by going backwards, and serializing the object I thought I was wanting to XML, then comparing that XML with my desired input. As it turned out, I was missing the default XML namespace argument from the serializer (the whole document appeared to belong to the same namespace, so I assumed (wrongly) that not specifying it would do the job...), but as far as I can tell, it's just a string.


I'll say at this point that I'm not a fan of the XML error messages that are reported when something goes wrong. “Error in document (number, number)” isn't exactly a clear problem statement. Sure, I got the right general idea and worked through to a working model, but I was sorely tempted to abandon it.


Then, I remembered that I wasn't really using objects as such within the application (so chalk deserialization up to a learning experience), but mostly DataSets and DataViews for sorting. On a whim, I tried pointing the DataSet.ReadXml method at the Reporting Services output, and got a set of tables back, which were immediately usable within the application (only a little column name hacking required - I didn't bother to abstract the data model for my teeny app - next time, I will, I promise...). I was impressed.


I was also fiddling with owner-drawn menus based on Dino Esposito's excellent article, and ended up porting his VB control to C#, to get a better understanding of how it worked - I modified it to use an ImageList as the image source, rather than files distributed along with the application, which I might cover another time...