在 protobuf-net 中序列化一个 IEnumerable

Question

I have a library of fairly heavy-weight DTOs that is currently being used by some WCF services. We are attempting to bring it into protobuf-net world, with as little modification as possible. One particular set of items is giving me trouble in serialization. I'm going to simply them here because it gets a little complicated, but the gist of the problem is:

public class Key
{
   public string Id {get; set;}
}

public class KeyCollection : IEnumerable<Key>
{
   private readonly List<Key> list;

#region IEnumerable
   // etc...
#endregion
}

public class Item
{
   public long Id { get; set; }
}

public abstract class ContainerBase
{ }

public abstract class ContainerBase<T> : ContainerBase
   where T : Item
{ }

public abstract class ContainerType1Base : ContainerBase<Item>
{
   public KeyCollection Keys { get; set; }
}

public class ContainerType1 : ContainerType1Base
{ }

I've left out the decorators because I don't they're the problem, mostly because if I add void Add(Key item) { } to KeyCollection the whole thing seems to work. Otherwise, I run into problems attempting to serialize an instance of ContainerType1 .

Actually, changing the signature of KeyCollection is kind of prohibitive, so I'm attempting to follow this answer to try to do it programatically. Specifically, setting itemType and defaultType to null on the "Keys" ValueMember of ContainerType1 , ContainerType1Base and ContainerBase<Item> . I also set IgnoreListHandling to true on KeyCollection ... which totally doesn't work. I get a generic "failed to deserialize" exception on the client, which I can post here if it would help. On the server side, I serialize it out using Serializer.Serialize() , and I spit out Serializer.GetProto<>() as well as JSON of the object, and they all seem to be work okay.

How can I turn off the list handling? Related to that, is there a way to turn on extra debugging while serializing to try to get some more information of the problem?

Answer 1

Fundamentally, the code shown looks fine. Unfortunately, there's currently a "feature" in gRPC that means that it discards the original exception when a marshaller (serializer) fails for some reason, so gRPC does not currently expose the actual problem. I have submitted a fix for this - it may or may not be accepted.

In the interim, I suggest that you simply remove gRPC from the equation, and simulate just the marshaller workload; to do this, on the server: generate the data you are trying to send, and do:

var ms = new MemoryStream();
Serializer.Serialize(ms, yourDataHere);
var payload = Convert.ToBase64String(ms.ToArray());

and obtain the value of payload (which is just a string ). Now at the client, reverse this:

var ms = new MemoryStream(Convert.FromBase64String(thatStringValue));
Serialize.Deserialize<YourTypeHere>(ms);

My expectation here is that this should throw an exception that will tell you what the actual problem is.

---

If the gRPC change gets merged, then the fault should be available via:

catch (RpcException fault)
{
    var originalFault = fault.Status.DebugException;
    // ^^^
}