Is there a reason for the nested generic collection classes in svcutil generated code?

Question

I'm generating my data contract with a command line like:

svcutil /ct:System.Collections.Generic.List`1 MySchema.xsd

In my generated code, I end up with something like this (let's call this "style 1"):

partial class A : object, System.Runtime.Serialization.IExtensibleDataObject
{
    private BType collectionB;

    public BType CollectionOfB
    {
        get { return collectionB; }
        set { collectionB = value }
    }

    [System.Runtime.Serialization.CollectionDataContractAttribute(...)]
    public class BType : System.Collections.Generic.List<B>
    {
    }
}

Why does it not generate like this (style 2)?:

partial class A : object, System.Runtime.Serialization.IExtensibleDataObject
{
    private System.Collections.Generic.List<B> collectionB;

    public System.Collections.Generic.List<B> CollectionOfB
    {
        get { return collectionB; }
        set { collectionB = value }
    }
}

From the perspective of consuming the code, the end results of both appear identical. Is the only reason for style 1 to enable serialization (the documentation for CollectionDataContractAttribute indicates that it applies to class or struct)? They are internal classes, and this is 100% generated code, so I can just ignore the implementation details, but it bothers me a little bit (plus I've got those "Nested Types" showing up in my class diagram).

Okay, so it bothers me a lot that is isn't possible to apply an attribute to the property to tell it how to serialize.

Answer 1

So as best as I can tell, this problem is an artifact of svcutil. If I was willing to code up the serialization by hand, judging from http://msdn.microsoft.com/en-us/library/aa347850.aspx it appears that I could indeed use style 1 and avoid the unnecessary internal types.

Since the interface for the consumer is identical, I'm going to go with ease of updating over having a clean object model.