My latest article (a quickie) is a custom control that provides animated expand/collapse of 'tool items' ala the Windows XP and Longhorn taskbars.

You can find it here

I was responding to a post, Deprecating the Soap Formatter, in regard to how the Soap formatter is actually useful 
on occasion because it is (almost) humanly readable. In the process I mentioned something I wrote called 
DualFormatter which I use for special situations (debugging message streams or complex object serializations.)
 
Anyway, I hate to post a code listing (but I hate hosting stuff even more) but here it is.
 
-------------------------  ----------
DualFormatter. 
Allows serialization to occur on 
multiple streams concurrently.
-------------------------  ----------

using System;
using System.IO ;
using System.Runtime.Serialization ;
using System.Runtime.Serialization.Formatters ;
using System.Runtime.Serialization.Formatters.Binary ;
using System.Runtime.Serialization.Formatters.Soap ;

namespace SerializationUtils {
 /// 

 /// An implementation of  that allows 
 /// serialization to be redirected to multiple streams
 /// 

 /// 
 /// DualFormatter designates one 
 /// as the primary serializer and routes all calls to 
 /// and  to this 
 /// with the  specified.
 /// 
 /// DualFormatter also provides for secondary streams to be serialized (but not deserialized) using 
 /// an alternate stream (by default a ) which can be used for debugging purposes,
 /// or to compare size deltas of different  
 /// implementations.
 /// 
 /// 
 /// By default, DualFormatter uses a folder (specified during construction) to hold the files created
 /// when an alternate stream is serialized. DualFormatter uses a simple algorithm to produces a
 /// (semi) meaningful name that is also unique. Note: it is only highly probable that the name is unique, but
 /// not guaranteed
 /// 
 /// 
 /// By default DualFormatter creates a 
 /// as the primary serializer, and a 
 /// as the secondary stream since this would be the normal case for debugging. Alternate constructors allow
 /// other variations, including user specified 
 /// implemnetations for both the primary and secondary serializers.
 /// 
 /// 
 /// Because DualFormatter is an implementation of 
 /// either the primary or secondary serializers (or both) can be a DualFormatter
 /// 
 /// 
 public class DualFormatter : IFormatter {
  /// 

  /// The primary  implementation
  /// which performs the (de)serialization to the primary 
  /// 

  private IFormatter primaryFormatter ;

  /// 

  /// The secondary  implementation
  /// which is used for serialization to an alternate 
  /// 

  private IFormatter secondaryFormatter ;

  /// 

  /// The folder where alternate  instances will be written
  /// 

  private String serializationFolder ;

  /// 

  /// An class field used to generate unique sequence numbers for all instances of DualFormatter
  /// 

  private static int seqNum = 0 ;

  /// 

  /// Default constructor which creates a 
  /// for primary serialization, and a 
  /// for serialization to an 
  /// 

  /// The folder where secondary  are created
  /// 
  /// If the specified folder does not exist, it is created. This operation can throw various exceptions.
  /// For more information 
  /// 
  /// If serializationFolder is 
  public DualFormatter(String serializationFolder) {
   if (serializationFolder == null) {
    t  hrow new ArgumentNullException("Du  alFormatter: Serialization folder cannot be null","serializationFolde  r") ;
   }

   this.serializationFolder = serializationFolder ;

   if (!Directory.Exists(serializationFolde  r)) {
    D  irectory.CreateDirectory(serializa  tionFolder) ;
   }

   primary  Formatter = new BinaryFormatter() ;
   seconda  ryFormatter = new SoapFormatter() ;
  }

  /// 

  /// Construct a DualFormatter using the specified 
  /// as the primary serializer
  /// 

  /// The primary serializer
  /// The folder where secondary  are created
  /// 
  /// If the specified folder does not exist, it is created. This operation can throw various exceptions.
  /// For more information 
  /// 
  /// The secondary serializer is an instance of
  /// 
  /// 
  /// 
  public DualFormatter(BinaryForma  tter primaryFormatter,String serializationFolder) {
   if (serializationFolder == null) {
    t  hrow new ArgumentNullException("Du  alFormatter: Serialization folder cannot be null","serializationFolde  r") ;
   }

   if (primaryFormatter == null) {
    t  hrow new ArgumentException("DualFo  rmatter: Primary IFormatter cannot be null","primaryFormatter")   ;
   }

   this.serializationFolder = serializationFolder ;

   if (!Directory.Exists(serializationFolde  r)) {
    D  irectory.CreateDirectory(serializa  tionFolder) ;
   }

   this.primaryFormatter = primaryFormatter ;
   this.secondaryFormatter = new SoapFormatter(primaryForm  atter.SurrogateSelector,primary  Formatter.Context) ;
  }

  /// 

  /// Construct a DualFormatter using the specified 
  /// as the primary serializer
  /// 

  /// The primary serializer
  /// The folder where secondary  are created
  /// 
  /// If the specified folder does not exist, it is created. This operation can throw various exceptions.
  /// For more information 
  /// 
  /// The secondary serializer is an instance of
  /// 
  /// 
  /// 
  public DualFormatter(SoapFormatt  er primaryFormatter,String serializationFolder) {
   if (serializationFolder == null) {
    t  hrow new ArgumentNullException("Du  alFormatter: Serialization folder cannot be null","serializationFolde  r") ;
   }

   if (primaryFormatter == null) {
    t  hrow new ArgumentException("DualFo  rmatter: Primary IFormatter cannot be null","primaryFormatter")   ;
   }

   this.serializationFolder = serializationFolder ;

   if (!Directory.Exists(serializationFolde  r)) {
    D  irectory.CreateDirectory(serializa  tionFolder) ;
   }

   this.primaryFormatter = primaryFormatter ;
   this.secondaryFormatter = new BinaryFormatter(primaryFo  rmatter.SurrogateSelector,primary  Formatter.Context) ;
  }

  /// 

  /// Construct a DualFormatter specifying both the primary and secondary serializers
  /// 

  /// The primary serializer
  /// The secondary serializer
  /// The folder where secondary  are created
  /// 
  /// If the specified folder does not exist, it is created. This operation can throw various exceptions.
  /// For more information 
  /// 
  /// The secondary serializer is an instance of
  /// 
  /// 
  /// 
  public DualFormatter(IFormatter primaryFormatter,IFormatt  er secondaryFormatter,String   serializationFolder) {
   if (serializationFolder == null) {
    t  hrow new ArgumentNullException("Du  alFormatter: Serialization folder cannot be null","serializationFolde  r") ;
   }

   if (primaryFormatter == null) {
    t  hrow new ArgumentException("DualFo  rmatter: Primary IFormatter cannot be null","primaryFormatter")   ;
   }

   this.serializationFolder = serializationFolder ;

   if (!Directory.Exists(serializationFolde  r)) {
    D  irectory.CreateDirectory(serializa  tionFolder) ;
   }

   this.primaryFormatter = primaryFormatter ;
   this.secondaryFormatter = secondaryFormatter ;
  }

  /// 

  /// Advance (and return) the class level sequence number in a thread-safe manner
  /// 

  private int SequenceNumber {
   get {
    l  ock(this) {
    &  nbsp;return ++seqNum ;
    }  
   }
  }

  #region IFormatter Members
  /// 

  /// Serialize the object graph to the specified stream using the primary
  /// 
  /// 

  /// The stream where the object graph is serialized
  /// The object graph to be serialized
  /// 
  /// If the secondary serializer is non- then an attempt is made
  /// to serialize the object graph to an alternate .
  /// 
  /// Any errors serailizing to the alternate  are trapped
  /// and will not be thrown back to the main code.
  /// 
  /// 
  /// The alternate stream is created via the  method
  /// 
  /// 
  /// 
  public void Serialize(Stream serializationStream, object graph) {
   primary  Formatter.Serialize(serializationSt  ream,graph) ;

   if (secondaryFormatter != null) {
    S  tream stream = null ;
    t  ry {
    &  nbsp;stream = GetSecondaryStream(graph,  secondaryFormatter.GetType()) ;
    &  nbsp;secondaryFormatter.Serialize(stream,graph) ;
    }   catch(SerializationExcept  ion se) {
    &  nbsp;System.Diagnostics.Debug.WriteLine("Unexpected SerializationException writing secondary stream: " + se) ;
    }   catch(Exception e) {
    &  nbsp;System.Diagnostics.Debug.WriteLine("Exception writing secondary stream: " + e) ;
    }   finally {
    &  nbsp;if (stream != null) {
    &  nbsp; try { stream.Close() ; } catch {}
    &  nbsp;}
    }  
   }
  }

  /// 

  /// Get/Set the  used by
  /// the serializers
  /// 

  public SerializationBinder Binder {
   get {
    r  eturn primaryFormatter.Binder ;
   }

   set {
    p  rimaryFormatter.Binder = value ;

    i  f(secondaryFormatter != null) {
    &  nbsp;secondaryFormatter.Binder = value ;
    }  
   }
  }

  /// 

  /// Get/Set the  used by
  /// the serializers
  /// 

  public StreamingContext Context {
   get {
    r  eturn primaryFormatter.Context ;
   }
   set {
    p  rimaryFormatter.Context = value ;

    i  f(secondaryFormatter != null) {
    &  nbsp;secondaryFormatter.Context = value ;
    }  
   }
  }

  /// 

  /// Get/Set the  used by
  /// the serializers
  /// 

  public ISurrogateSelector SurrogateSelector {
   get {
    r  eturn primaryFormatter.SurrogateSelector ;
   }
   set {
    p  rimaryFormatter.SurrogateSelector = value ;

    i  f(secondaryFormatter != null) {
    &  nbsp;secondaryFormatter.SurrogateSelector = value ;
    }  
   }
  }

  /// 

  /// Deserialize using the primary serializer
  /// 

  /// The  containing the object graph
  /// to be deserialized
  /// 
  /// The resulting object graph
  /// 
  /// 
  /// The secondary serializer(s) is not involved in the deserialization process
  /// 
  public object Deserialize(System.IO.Stream serializationStream) {
   return primaryFormatter.Deserialize(serialization  Stream) ;
  }

  /// 

  /// Method to create an alternate stream used by the secondary serializer
  /// 

  /// The object graph
  /// The  of the secondary serializer
  /// 
  /// A  where the secondary serialization is written
  /// 
  /// 
  /// The default implementation creates a  in the 
  ///  with a unique name created from the type name of the
  /// object graph, the current year, month, and day, and a unique, monotonically increasing
  /// sequence number
  /// 
  protected virtual Stream GetSecondaryStream(object   graph,Type formatterType) {
   DateTim  e now = DateTime.Now ;
   String graphName = graph.GetType().FullName + String.Format(" - {0}.{1}.{2}.{3}",now.Year,now.Month,now.Day,SequenceNumber) ;

   if (formatterType == typeof(SoapFormatter)) {
    g  raphName += ".soap.xml" ;
   } else if (formatterType == typeof(BinaryFormatter)) {
    g  raphName += ".bin" ;
   } else {

	graphName = "." + formatter.GetType().Name ;

	}

   return new FileStream(Path.Combine(serializationFold  er,graphName),FileMode.Create,FileAccess.Write) ;
  }
  #endregion
 }
}

I stumbled across a discussion on API Complexity (related to Avalon) at simplegeek. As someone who is at least midly curious about the future of Windows, especially related to the user experience I found the overall post and Slashdot thread quite interesting.

A few posts later I ended up here reading an Avalon developers views on the overall subject expressed as a *very long* metaphor regarding cars, transmissions, and driving. To me this post is uber-scary and sends up a lot of red-flags regarding Avalon. Not because of the views expressed, but the complexity with which it is expressed. Metaphors are supposed to make complex things simpler to understand by relating the complexity in a way that everyone can understand. 1st, by using a metaphor you are basically admitting that you can't explain the complexity in a way that even the experts involved in the discussion can understand, and 2nd KISS. If I wanted to read about cars and transmission I'd subscribe to Car & Driver.

Honestly, while reading this post if felt pangs of agony shooting to my brain, begging me to just close the reader. Somehow I managed to get through to the end but I lost most of the point early on when my eyes glazed over.

Of course the author (IanG) does apologize for the long-winded metaphor, but not until after all is said (and said, and said) and done.

Anyway, I am now very wary of Avalon. Strange what a single blog post will do. But I am getting the feeling that outside the Microsoft camp that Avalon is a big *yawn* anyway. Still, I like what I see so far, so heres hoping :)

Tom

Of course having Matt back for the 1st time since his March departure to the 'Evil Empire' was a special treat, and as Gator would say, Matt is 'Geek Royalty' so you probably expect some heavy technical discussions to pursue. Alas, that is rarely the case when we get together as neither Matt nor I have a blazing desire to discuss technologoy or cool code tricks. In light that all our better halves were hanging out with us I think they are pretty relieved when we talk about non-tech stuff like engagement rings, kids, houses, hiking, and building island resorts where none existed before. Still, you would be pretty disappointed if we didn't at least talk about something related to technology or the business of technology wouldn't you?

Anyway, heres the quick synopsis:

• Matt and I are big fans of Raymond Chens blog: The Old New Thing. The guy just speaks our language because we lived the x86 architecture (and how Microsoft uses it) for many, many, many years. Raymonds stuff is like an old worn shoe. Very comfortable


• Gator admitted to having 'avoided the whole Blog thing .' The next Monday he was running Thunderbird 0.8 and getting into the swing of it...


• Matt raved about the Index servers at Microsoft. John and I laughed. We don't have enough developers and/or shared code to make an index server useful


• John and I raved about One Note and Matt gave us a blank stare. Hopefully he'll get turned on to it. Best Microsoft product in years


• Of course we talked about the whole WinFS, Longhorn, Avalon announcements (you know the ones.) Everybody just shrugged no big deal, seems like a good idea to get some of the technologies out earlier, especially Indigo on XP


• We talked about new vangaurd of technical authors/writers (Chris Sells, ???) and how the old guard (Matt, Jeffery, Don, et. al.) are still highly regard (yes, 'Geek Royalty') but the times they are a changing...


• We found out the Gator's wife Karen has a serious Feta Cheese fetish and makes great Wine selections

During our discussion of authors and the state of the world regarding technical diatribe I said that I thought that Jeffey Richter was the best author (by a hair.) I think the Jeffery does a great job with very large volume subjects (go all the way back to Advanced Windows NT) and keeps it all coherent, easy to ready, and 98% accurate.

Jeffery isn't my favorite writer but he is the consummate professional and never hacks the book. Hopefully Matt wasn't offended (why are we always letting our egos get in the way of everything) but he knows I think his writing is the most interesting. Matt's writing comes from the passion of 'technical digging' (Matt used to refer to this as spelunking.) and he is a professional developer (sorry Jeffery), not a professional writer. That's why I love Matt's stuff, but repsect Jefferies work given his super high-quality on very large subjects.

One thing I found interesting was that Matt thought the John Robbins (also ex-numega) was the best writer. I can't quote Matt but to paraphrase him, he said something to the effect that "I stuggle to write/explain something, and then I read John and he just finds the perfect way." Again this is nowhere near a direct quote but I hope Matt will agree that it is not a gross misrepresentation.

The few things I have read by JR have been good (and Gator swears by his debugging book), but the problem I have with JR's stuff (and JR, this is not personal), he barely writes about anything I find interesting. Damn it JR don't write about converting C# to Visual Basic and/or Visa Versa. Who cares? Get back into doing the 'Juval Lowy thing' and write about practical stuff. I read JR's two-part very-tiny-mini-serieis on localization (yes, localization is very boring) but it is that everyday stuff I need to know before I implement (not six months after I ship the product.) Those articles (boring as the subject is) have a permanent place in my desk because they are practical and applicable on a daily basis.

Anyway, next year you are all invited. Bring your kids so that they can entertain my kids. That way, Shel and I can actually enjoy the company and conversation.

Peace out to Matt, Congrats to you and Carrie! Sorry you missed the Monster Magnet show, but hopefully the trip east had its own rewards.

The October issue of MSDN Magazine contains an article by Juval Lowy called Advanced Serialization: Format your way to success with the .NET Framework Versions 1.1 and 2.0

 The article is not brilliant,  it's not earth shattering, and it's not sexy, but if you are a serious professional developer you need to read everything this guy writes; articles, books, poetry, limericks, sonets, ...whatever!

'Why?' you ask. I will tell you plain and simple. He is is the only author out there who is really telling you what you need to know. He is going beyond the technology (because the technolgoy part is not hard is it?) and telling you how to apply it. Are the topics sexy? Hardly ever. The crux of his writing is about proper application of basic technologies such as events and delegates, serialization, and assembly versioning. These are all things that you can and will apply everyday.

A good example is serialization. If I asked you 'You have serialized objects from version 1.0 of your application and now that you are getting ready to plan the release of version 2.0, what will you need to do to automatically upgrade existing clients to the new object versions when 2.0 is released?'

The 2nd question would be: 'Knowing this, what would you do different in version 1.0 to make the work involved for a version 2.0 upgrade radically simpler?'

If you can't answer these questions at serious length then you are reading the wrong authors. Of course, who can blame you when you could be reading 'Use the Visual Studio 2005 Bootstrapper to kick-start your installation'? Not a bad article but your time is much better spent focused on things you will use day-in and day-out to improve your productivity, quality of work, and ultmately, your quality of life. That is the worthwhile investment.

I think part of the problem is that good developers start to turn a deaf ear to these types of things because we start to want to avoid admitting what we don't really know. We know enough about a given subject so just leave us alone; we don't want to admit that we don't 'own' the subject. 

Serialization is a case in point. Most .NET developers probably think they more than enough about serialization. Of course they read Jeffery Richter's 3-part MSDN articles about the 'technology', and filed a few useful facts away. Then they went on to practice basic serialization techniques until they were/are forced to do otherwise. A viable enough strategy if you don't mind having to work your way out of serious jams down the road, but then again, that's what we experts do isn't it? I guess it's just part of the mystique

Anyway, the most serious fallacy of my diatribe is that even good developers rarely get a shot a 2.0, and when we do, we often don't change the fundamentals (thus avoiding serious issues), or we write it off as the price of success. Same argument I used when people asked me about internationalization: most developers are lucky to get a product release in their 'native' language, much less someone else's.

As far as bad developers go, they don't know any better (yet), or they don't care because they won't be around for version 2.0 and it will be SEP (Someone Elses Problem.)