Why IntermediateSerializer control attributes are not part of the Content Pipeline

Originally posted to Shawn Hargreaves Blog on MSDN, Wednesday, August 27, 2008

IntermediateSerializer is intended for use during the content build process, so it is implemented in the Microsoft.Xna.Framework.Content.Pipeline assembly. This is not available on Xbox or Zune, and not part of the framework redistributable, which makes IntermediateSerializer a poor choice for runtime game code.

The attentive reader may have noticed, however, that the related ContentSerializerAttribute and ContentSerializerIgnoreAttribute classes are defined by the main Microsoft.Xna.Framework assembly.

Why?

Partly this is because many games share the same data types between their content build and runtime code. They may wish to use attributes to control how these types are serialized, but do not want to force the entire game to reference the Content Pipeline assembly because of that.

Also, it is because I like to believe I am telepathic and can predict the future.

Consider the IntermediateSerializer extensibility model:

1. Built-in types are handled for you by the framework
2. Most custom types "just work" using reflection
3. For more complex types, you can tweak the behavior using attributes
4. For really complex types, you can provide a custom ContentTypeSerializer

Compare this to how binary XNB files are read and written:

1. Built-in types are handled for you by the framework
2. ???
3. ???
4. For all custom types, you must provide a custom ContentTypeWriter and ContentTypeReader

Hmm...

In fact, our original Content Pipeline design included some automatic XNB serialization functionality in steps 2 and 3. We cut this at the last minute due to lack of time (remember: shipping is a feature too!) and since then other higher priority features have preempted any chance to revisit it. I still live in hope, though...

If we ever did implement some kind of reflection based XNB serialization mechanism, we would want these same attributes to control it. XNB loading happens at runtime, therefore the attributes must be available at runtime too. Should we ever implement such a thing, having the attributes ready and waiting for it will give me the chance to say "see? my telepathic powers are alive and well! I predicted this feature several years in advance" :-)

Disclaimer: none of the above should be interpreted as any kind of promise or roadmap for future framework features! I'd love to someday implement something along these lines, but have no idea if/when that will align with our wider priorities and schedule.