While it's true that *in general*, serialization doesn't necessarily have to concern itself with the types of the objects in question and only record representations of their state... not all serialization implementations do that. Most of the built-in .NET serialization methods *do* record information about types participating in serialization. There are advantages to that choice (allowing for more robust validation) as well as disadvantages (larger serialized object size), but it's not *wrong* per se and you just have to live with it.

XNA's content pipeline, for your types, traverses the serializable property (and field) graph and creates readers for them. You can see this behavior if you examine the initialization for `ReflectiveReader<T>` (the `Initialize` method, not the constructor). It does this via reflection, *not* based on the actual data in the XML (again, this is verifiable by looking at the reflected code). So it doesn't matter if there is a reference to the texture in your data or not, if there's a `Texture2D` property in the type's property graph, it will try to create a reader for it as part of the initialization of the content pipeline.

You are not supposed to use direct references to `Texture2D` objects in your custom content. You may find [this thread][1] (or [this one][2], to a lesser degree). The alleged solution to the issue is to use external references to `Texture2DContent` instead.


  [1]: http://xboxforums.create.msdn.com/forums/t/96662.aspx
  [2]: http://xboxforums.create.msdn.com/forums/t/44917.aspx