Est-ce que protobuf-net peut sérialiser cette combinaison d'interface et de collection générique?

Question

J'essaie de sérialiser un ItemTransaction et protobuf-net (r282) a un problème.

ItemTransaction : IEnumerable<KeyValuePair<Type, IItemCollection>></code> 

et ItemCollection est comme ceci:

FooCollection : ItemCollection<Foo> 
ItemCollection<T> : BindingList<T>, IItemCollection 
IItemCollection : IList<Item> 

où T est un type d'élément dérivé. ItemCollection a également une propriété de type IItemCollection.

Je sérialisation comme ceci:

IItemCollection itemCol = someService.Blah(...); 
... 
SerializeWithLengthPrefix<IItemCollection>(stream, itemCol, PrefixStyle.Base128); 

Mon objectif final est de sérialisation ItemTransaction, mais je suis accroché avec IItemCollection.

L'élément et ses types dérivés peuvent être [de] sérialisés sans problème, voir [1], mais la désérialisation d'un IItemCollection échoue (travaux de sérialisation). ItemCollection a une propriété ItemExpression et lors de la désérialisation de protobuf ne peut pas créer une classe abstraite. Cela a du sens pour moi, mais je ne suis pas sûr de savoir comment le surmonter.

ItemExpression<T> : ItemExpression, IItemExpression 
ItemExpression : Expression 

ItemExpression est abstraite comme l'est l'expression

Comment puis-je obtenir que cela fonctionne correctement?

Aussi, je crains que ItemTransaction échouera puisque les IItemCollections vont être différentes et inconnues au moment de la compilation (un ItemTransaction aura FooCollection, BarCollection, FlimCollection, FlamCollection, etc.).

Qu'est-ce qui me manque (Marc)?

[1] protobuf-net [de]serializing across assembly boundaries

Answer 1

Je ne suis pas tout à fait clair sur le scénario entier; cependant Merge peut être utilisé pour passer un élément concret (dans le cas où vous voulez créer vous-même une instance concrète vide et laissez protobuf-net remplir les propriétés).

Si la ItemExpression est décorée avec [ProtoInclude(...)] pour l'attendre ItemExpression<T> il devrait permettre désérialisation - types abstraits sont pris en charge aussi longtemps qu'il ne trouve jamais il a besoin pour créer un! Voir également my answer here qui montre cela en cours d'utilisation.

Si vous pouvez fournir un exemple que je peux utiliser pour reproduire le problème, je devrais être en mesure de fournir plus d'informations.

---

Sur la base de quelques exemples, je pense que je l'ai conclu hors forum que ce est pris en charge, mais:

• si vous utilisez seulement Deserialize..., le dérivé IList<T> outmost sera créé par par défaut comme List<T>; vous pouvez contourner ce problème en utilisant Merge à la place, en passant dans une instance de liste concrète de votre choix à remplir
• tous Item, Foo, Bar devrait être marqué comme contrat-types, avec des marqueurs d'héritage appropriés entre Item et Foo, et (bientôt) il y a plus de contrôle Item et Bar
• dans « v2 » pour gérer les types de listes concrètes (et les types d'éléments pour les listes typées)
• il ne semble être un petit problème lié à la liste désérialisation où le type d'élément indiqué est pas le type de racine. Cela semble avoir été corrigé automatiquement dans "v2", mais j'ai besoin de le parcourir (cela touche malheureusement le wrapper "WithLengthPrefix"/liste des méthodes les plus externes, sur lesquelles je travaille encore)
• dans "v2" vous peut faire le tout sans avoir besoin des attributs si vous le souhaitez (bien qu'il doive encore être dit comment à un certain point)

Mais oui; ça devrait marcher. Je vous ai envoyé un échantillon par e-mail, et j'ai l'intention de ranger les méthodes les plus externes mentionnées ci-dessus.