.NET XmlSerializer and nested classes in C#

Question

I have encountered some surprising behavior using XmlSerializer in C#. Consider the following piece of code.

public class A : IEnumerable
{
    public class B
    {
        [XmlAttribute]
        public string PropA { get; set; }
        [XmlElement]
        public string PropB { get; set; }
    }

    public IEnumerator GetEnumerator ()
    {
        yield break;
    }
}

class Program
{
    static void Main (string[] args)
    {
        XmlSerializer serializer = new XmlSerializer(typeof(A.B));

        XmlTextWriter writer = new XmlTextWriter(@"E:\temp\test.xml", Encoding.Default);
        serializer.Serialize(writer, new A.B() { PropA = "one", PropB = "two" });
    }
}

In this example I try to serialize an instance of nested class A.B, which itself doesn't make use of the container class A in any way. But when I attempt to construct the XmlSerializer for it, the following exception is thrown:

InvalidOperationException was unhandled:

To be XML serializable, types which inherit from IEnumerable must have an implementation of Add(System.Object) at all levels of their inheritance hierarchy. Test.A does not implement Add(System.Object).

XmlSerializer is trying to apply serialization constraints against type A when I'm actually trying to serialize type A.B. My understanding however is that aside from privileged access to data in instances of the outer type, a nested type is not special and behaves as if it were in a namespace.

Is this understanding incorrect, and do the semantics of nested types or XmlSerializer justify this behavior, or does this feel like a bug in XmlSerializer?

In specific regard to XmlSerializer semantics, is there any documented requirement that enforces XmlSerializer constraints on all outer types when applied against a nested type?

Answer 1

http://msdn.microsoft.com/en-us/library/vstudio/ms229027%28v=vs.100%29.aspx

Because a nested type is treated as a member of the declaring type, the nested type has access to all other members in the declaring type.

So if the serializer wants to work with A.B, it needs the definition of A as well. Where the IEnumerable validation kicks in.

Doesn't matter that B doesn't actually refer to anything in A :)