Protobuf-net: Zagnieżdżone obiekty IEnumerable

Question

Używam Protobuf-net do serializowania niestandardowej listy zagnieżdżonej. Rozumiem, że nie można bezpośrednio zagnieżdżać list rodzimych, dlatego użyłem obiektu kontenera dla wewnętrznej listy. Jednak chciałbym również, aby mój pojemnik obiektów IEnumerable ale to oznacza Protobuf-net wyrzuca go z błędu:

Nested or jagged lists and arrays are not supported

Oto przykład z mojej listy struktury, która powoduje błąd:

[ProtoContract] 
public class MyOuterList<T> 
{ 
    [ProtoMember(1)] 
    readonly List<MyInnerList<T>> nestedData = new List<ObjectList<T>>(); 
} 

[ProtoContract] 
public class MyInnerList<T> : IEnumerable<T> 
{ 
    [ProtoMember(1)] 
    private readonly List<T> data = new List<T>(); 
} 

Poprawka polega na usunięciu IEnumerable z MyInnerList, ale oczywiście uniemożliwia to bezpośrednią iterację. Czy można użyć podstępnego atrybutu, takiego jak [ProtobufCustomObjectSoPleaseIgnoreIEnumerable]?

Najlepszą alternatywą, jaką do tej pory wymyśliłem, jest użycie właściwości, którą można wyliczyć, jak pokazano poniżej, ale obawiam się, że nieruchomość wciąż może być ponownie wyświetlona na liście. Wolałbym używać w pewien sposób GetEnumerator/yield, ale nie widzę jak.

[ProtoContract] 
public class MyInnerList<T> 
{ 
    [ProtoMember(1)] 
    private readonly List<T> data = new List<T>(); 

    public IEnumerable<T> Data 
    { 
     get { return this.data; } 
    } 
} 

Answer 1

Is there a sneaky attribute like [ProtobufCustomObjectSoPleaseIgnoreIEnumerable] that could be used?

yup:

[ProtoContract(IgnoreListHandling=true)] 
public class MyInnerList<T> : IEnumerable<T> 
{ 
    [ProtoMember(1)] 
    private readonly List<T> data = new List<T>(); 
} 

podstępne jest podstępny. IgnoreListHandling posiada dokumentację intellisense:

If specified, do NOT treat this type as a list, even if it looks like one.

Ponadto, ze względu na wiele wniosków like this one, mam zamiar patrząc na realizację wsparcia dla postrzępionych tablic/list wkrótce. Plan polega na tym, aby środowisko wykonawcze sfałszowało opakowanie elementem (pole 1) w wyobraźni serializera, aby można było użyć List<List<T>> i będzie działało dokładnie tak, jak w powyższym modelu (będzie nawet kompatybilne z siecią, ponieważ rozsądnie wybrał pole 1).