>>If you add this to a .config file (for your AppDomain) you'll
   get some temporary files in c:\documents and settings\local settings\
      \temp.  Try it.  Run some serialization code and checkout the .CS file(s)
      that are created.  Very damn useful.  This works today with .NET.
    

But I'm here to hear about new versions of stuff.  Here's some new things about XmlSerialization in the Whidbey version of .NET.

• There's a tool called SGEN that will “NGEN” your serialization code. That way you don't need to take the initial hit when the Serialization Assembly is emited.  You can basically ship it with the code.
• Adding support for Generics to the Serializer, both open generics and instatiated generics
• Support for Extensibility around Schema Importing
• SqlType support
• The BinaryFormatter is Version Tolerant
• Here's some new Attributes:
  • [OptionalSerializable] - Does just what you'd think.  Makes a field optional, and consequently helps you deal with Version changes between Object Heirarchies

Here's what's going on with XmlSerialization in Indigo (after Whidbey, in Longhorn):

• The Serializer is now in the Core
• Architecture of the CLR, not just “tacked on“
• A Tale of Two Type Systems
  • Act One: Whidbey
    • Mapping XSD into the CLR is very challenging, including mapping some of the concepts that exist in XSD that just don't in the CLR
    • Mapping from the CLR to XSD is fairly straightforward
    • CLR to CLR is really easy
  • Act Two: Indigo
    • Big Conclusion - Serialization is different than Xml Programming.  Developers don't think about the format on the wire.  They want the CLR to fix it for them.
    • New stack: XmlFormatteer consiting of Serialization Engine -> Extensibility -> Xml Processing - Representations
    • XmlBinaryReader and XmlBinaryWriter being introduced
    • Allow the developer to express the data contract for a given type Explicitly
    • [DataMember] lets you markup any member and include it into the Data Contract.  It doesn't care about accessiblity.  That means you can mark something private or internal and if it's marked with [DataMember] then it gets serialized.
    • Cool...you can have two totally “different“ CLR types, perhaps one has a private something with a property accessor and another version has the same “semantic“ member but it's public.  You can mark them up with DataMember to make the contract with the serializer the same so the objects will serialize the same.
    • WHY IS THIS IMPORTANT: You can serialize one CLR object from one Assembly and deserialize it into another totally different implemenation (a totally different CLR type).  As long as we both agree on the contract, we can use the same underlying data representation.  Yum.
• Existing Types continue to work, but you get loose coupling and version resiliance

Doug said he woke up this morning hoping the sky would be Indigo.  It wasn't.  But one day...

P.S. I forgot to mention that Christian Weyer can lift Rory with ease.  If he were Austrian, he could be a governor.