[InvalidOperationException: Unexpected sub-type: System.String] about public-broadcasting HOT 6 CLOSED

I suspect the problem here is RouteValueDictionary is an IDictionary<string, object>, which probably greatly confuses deserialization.

I haven't time to investigate further though, hopefully this weekend I'll get the free time.

from public-broadcasting.

Not a huge rush - I modified my code to convert the RouteValueDictionary to a Dictionary<string, object> shim and then when I deserialize, convert the shim back to a RouteValueDictionary.

from public-broadcasting.

@jgeurts Dictionary<string, object>? Are you sure you didn't use Dictionary<string, string> for your shim?

It looks like the issue is object as the dictionary's TValue type (really just System.Object as a discovered "to be serialized" type, at all), protobuf doesn't know what to do with that (it has no properties or fields to annotate). I could make it not fail, but since no properties would be deserialized you'd just get a dictionary like { { "some value", new object() }, { "some other value", new object() }, ... } out.

But if you've got working code with a Dictionary<string, object> shim, that kind of kills that theory. Would love to see some more code if that's the case.

from public-broadcasting.

@kevin-montrose I apologize - I was trying to get the serialization working with Public Broadcasting and then TypeSerializer from service stack. I apparently settled on TypeSerializer, which handles the Dictionary<string,object> type. Added a test with #6, if that helps. Please let me know if I can help with anything else.

from public-broadcasting.

@jgeurts Yeah, protocol buffers can't really deal with heterogeneous collections. I think the best thing to do here is to generate a better error message.

I think the way ServiceStack deals with this is by attaching type information to every stored value whose compile time type System.Object, which doesn't work with Public Broadcasting's "leading type description" approach.

I suppose I could detect when a collection is typed System.Object but actually contains only a single type (probably as a defaults-off option). That wouldn't do anything for #6 though.

from public-broadcasting.

Ok, thanks for taking a bit of time on this. I do think that heterogeneous collections are a bit of an edge case and in my instance, I'm completely fine using a Dictionary<string,string> as an alternative.

As a side note, I looked at the serialized result from ServiceStack's TypeSerializer and it didn't include the __type property with type information for each value. When deserializing, it just recreates the objects as strings.

from public-broadcasting.