title: Is there a reason for the nested generic collection classes in svcutil generated code?
body: <p>I'm generating my data contract with a command line like:</p>
  
  <pre><code>svcutil /ct:System.Collections.Generic.List`1 MySchema.xsd
  </code></pre>
  
  <p>In my generated code, I end up with something like this (let's call this "style 1"):</p>
  
  <pre class="lang-cs prettyprint-override"><code>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&lt;B&gt;
      {
      }
  }
  </code></pre>
  
  <p>Why does it not generate like this (style 2)?:</p>
  
  <pre class="lang-cs prettyprint-override"><code>partial class A : object, System.Runtime.Serialization.IExtensibleDataObject
  {
      private System.Collections.Generic.List&lt;B&gt; collectionB;
  
      public System.Collections.Generic.List&lt;B&gt; CollectionOfB
      {
          get { return collectionB; }
          set { collectionB = value }
      }
  }
  </code></pre>
  
  <p>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).</p>
  
  <p>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.</p>