.debug

I can’t say without batting an eye that I hate LINQ completely. There are a few things that I actually like about LINQ and one of them is the little-known feature called LINQ to XSD.

Unlike that travesty that is called LINQ to Entities, LINQ to XSD just works. Don’t let the Alpha 0.2 designation fool you; it’s full-featured, including near-seamless integration with Visual Studio 2008…unlike some tool out there that’s already in version 3.0 but performs like it’s in pre-alpha version.

So why/when would use LINQ to XSD? Sure, you can hand-code .NET objects based on your XML Schema and rely on the [Serializable] attribute and just use XmlSerializer…that works…if your schemas aren’t terribly complicated. However, when you start using a more complex XSD that changes often, automating the process certainly eases the pain.

But what does LINQ to XSD offer over something like…the all-time-favorite class generator, XSD.EXE? Well, first of all, XSD.EXE still generates classes around the “old” .NET objects, XmlDocument; LINQ to XSD builds around that more awesomerz XDocument objects. Second, the way LINQ to XSD integrates with VS2008 is elegant in such a way that it doesn’t make the developer feel stupid: it hides the abstraction of creating the classes BUT it provides a “back door” for all the classes it creates–i.e., it still provides access to the internal classes it abstracts from you (OH, HELLO THERE, LINQ to ENTITIES…)

When you include an XSD in a LINQ to XSD project, you are given the “compile option” to create LINQ to XSD classes…No, you never see the generated .NET source code for the classes (actually, you can…but it’s not intended to be exposed), but that’s fine…in fact, you will prefer it this way, anyway; and…you can still browse the object classes generated…sweet, isn’t it? Change the XSD? Go ahead, the object classes gets regenerated, too…In contrast with XSD.EXE where…bah…I’m not even going there.

So there you have it: one of the few features of LINQ that works. Imagine that.