4

I'm trying to integrate the awesome protobuf-net into an existing codebase, but am encountering a crash when it tries to handle a custom type. A small demonstration is below: it will throw an InvalidOperationException in ProtoBuf.Serializers.ListDecorator. But if you comment out the indexer (or remove the IEnumerable implementation) then it runs cleanly.

using System.Collections.Generic;
using ProtoBuf;
using System.Collections;

[ProtoContract]
public class MyClass : IEnumerable<int>    
{
    [ProtoMember(1, IsPacked = true)]
    public int[] data { get; set; }

    // Comment out this indexed property to prevent the crash
    public int this[int i] { get { return data[i]; } set { data[i] = value; } }

    public IEnumerator<int> GetEnumerator() { foreach (var x in data) yield return x; }
    IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); }

    static void Main(string[] args) { Serializer.PrepareSerializer<MyClass>(); }
}

Am I doing something wrong? How can I tell the protobuf-net Serializer to just ignore that Indexer property?

Thanks!

EDIT (Oct 10): Marc has kindly provided a fix in protobuf-net r447 via [ProtoContract(IgnoreListHandling = true)].

Gabriel
  • 1,443
  • 15
  • 24

1 Answers1

4

Your type looks suspiciously like a collection, and protobuf-net is indeed trying to handle it as such. One "fix" would be to add an Add(int) method, as that is what it is going to want to use when deserializing. I am, however, investigating why the presence/absence of the indexer makes a difference here (that is not immediately obvious to me).

Note that because this looks so much like a collection, the [ProtoMember(...)] might not be used here. I'm not 100% certain until I find out what role the indexer is playing here.

Ahah; k; found why the indexer is getting involved - essentially, after detecting IEnumerable, it is trying to identify the Type of the collection; it uses various cues:

  • the <T> in ICollection<T>
  • the SomeType in Add(SomeType)
  • the SomeType in a public SomeTime this[int index] {...} indexer

of these, the only one that applies is the last. However, IMO it should probably also use the <T> in IEnumerable<T> (I might tweak this) - this would at least make this scenario less bizarre (as would improving the error message, which I'll do).

To summarize, protobuf-net has lots of very particular handling for things that smell like collections; personally, I'd drop the IEnumerable<T> support, and let callers go via .data instead; the message will (at some point) display:

Unable to resolve a suitable Add method for {FullName}

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks. The real-world type is actually an ArraySegment kind of thing, showing a limited view of the underlying array. So the implementation of IEnumerable doesn't simply expose the Array. Those "cues" are in TypeModel.ResolveListAdd(), right? I might try to hack that a bit... – Gabriel Oct 04 '11 at 21:39
  • @Gabriel it is `GetListItemType` that is at fault here – Marc Gravell Oct 04 '11 at 21:41
  • Ah, yeah, I see that now. Thanks! – Gabriel Oct 04 '11 at 21:43
  • 1
    @Gabriel to clarify, my preferred option here is to figure out some mechanism to say "this really is a single object; ignore all list handling", rather than fuss with that method – Marc Gravell Oct 04 '11 at 21:46
  • Perhaps something like a `bool NotAList` property in the `ProtoContractAttribute` ? – Gabriel Oct 04 '11 at 21:50
  • @Gabriel something like, indeed; noting, however, that the attributes are only a thin veneer in v2 to steer the `MetaType`, which is where it ultimately needs to be possible. I'll add somet' ;p – Marc Gravell Oct 04 '11 at 21:54