Why IntermediateSerializer control attributes are not part of the Content Pipeline

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.


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


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.

Comments (6)

  1. sam_roshan@hotmail.com says:

    Hi Shawn!!

    Thanks for your wonderful example and explanation about IntermediateSerializer and XML.

    I am using XNA 3.0 with Visual Studio 2008.

    I am working on a Map Editor, which will use various Tilesets. I have also created a program that makes a TileSet from various tiles and saves its attributes into a <XNAContent> XML file.

    I wanted to use the XML in my Map Editor project for Content. I have a created the related Tileset class too. When I wanted to write the ContentReader/Writer functionality, I could not find it within the Content namespace! Not even IntermediateSerializer. Has this been removed from 3.0? Could you pls help me out?

    Thanks for your help!!


  2. ShawnHargreaves says:

    Hi Sam,

    The serializer types are defined in the Microsoft.Xna.Framework.Content.Pipeline assembly, not the main Microsoft.Xna.Framework, so you will have to add a reference to this if you don’t have one already.

    MSDN lists what assembly and namespace you can find each type in, eg:


  3. Hallelujah!! I got it now! 🙂

    Thank you very much again. Actually I had not added a reference to the Content.Pipeline. Very new to C#.

    Now I can continue the TileSet Maker and attach new tilesets to my Isometric Map Editor!

    Is it possible to "load" a Contents file like a Tileset image at runtime without having to first add every tileset to the C# Solution’s content folder?

    I mean, in my Map Editor, I want to give users the option to Browse and select a tileset and start using the tile images at runtime. It was very simple with DirectX. The Editor would be for Windows only.

    Here is my Isometric Map Editor, I had earlier created in VB+DirectX. Making a new version of same in XNA. 🙂


    Thanks so much!!!

  4. BulkakeNinja says:

    Regarding the content pipeline and generating XNB files with the IntermediateSerializer, is it recommended to have #if DEBUG blocks of code to create the contentpipeline files, and then #if RELEASE to simply use the compiled xnb files for release time?

    How else would a real-world development make best use of the benefits of IntermediateSerializer in a cross-platform development?

  5. ShawnHargreaves says:

    > is it recommended to have #if DEBUG blocks of code to create the contentpipeline files, and then #if RELEASE to simply use the compiled xnb files for release time?

    I wouldn’t do it that way. The normal approach is to split out your build-time content processing code into a different assembly from your run-time game code. That way you only have to ship the game code to your customers, while the build-time code only ever runs on your development PC. This setup is very important if you want to develop for Xbox or Zune, since the Content Pipeline build code always runs on Windows, even if the final game is for some other platform. This makes it very important to keep your build-time code separate from your run-time code, because the two do not even run on the same platform!

    Check out any of the Content Pipeline samples on creators.xna.com to see some examples of how such things are split up into multiple assemblies.

  6. BulkakeNinja says:

    Thanks, I will check-out the creators club samples, just hope I have enough time to split my code before the end of submissions for DBP, I guess this is what we call experience 🙂

Skip to main content