There’s a pretty disturbing nuance I’ve found recently. Suppose we have a class with XmlRoot attribute:
[XmlRoot( “SomeXmlNode” )]
public class SomeClass { ... }
If this class has to be marked as Obsolete, this new attribute has to be placed ABOVE XmlRoot. Otherwise this combination will result in XmlIgnore analog and will break XML serialization, exceptions will be thrown like “Unknown element”.
I’d better describe this. Following code falls under erroneous condition:
[XmlRoot( “SomeXmlNode” )]
[Obsolete]
public class SomeClass { ... }
But this code will work:
[Obsolete]
[XmlRoot( “SomeXmlNode” )]
public class SomeClass { ... }
I’ll look into IL later to understand the real difference. But this situation is weird anyway, attribute order should now make difference on class level. Supposedly there is a problem in default XML serialization. Looks like presumption of some architect or coder: “well, if we’ve got an obsolete item here, this node is not needed anymore, so lets ignore it.”
Also I’ve found following note in XmlSerializer documentation:
Objects marked with the Obsolete Attribute no longer serialized.
In the .NET Framework 3.5 the XmlSerializer class no longer serializes objects that are marked as [Obsolete].
This means that in case of custom serialization we have total mess. And double bug, by the way.