protobuf-net | Clone of the protobuf-net SVN repository | Serialization library

This gives us, among other things:

This is fine, for protobuf-net to protobuf-net scenarios, but when we work with the same data in Java, it doesn't know or care about this, and elects to serialize in ascending field order, i.e. field 1, then field 400. It is explicit in the specification that fields may be out of order, but Java can choose to do whatever it wants.

So: now we take that data back to protobuf-net, and we see field 1 first; at that point, we have no clue what the final type will be, and nowhere (yet) to stick the data. With no better options, the library tries to use the base type BasePaintHolder as a placeholder until it can make better decisions, but it turns out that this type is abstract, so: even that fails.

So: that's the why, and some back-story. What can we do?

Well, the first thing we could try might be to remove the abstract, making it technically constructable. To prevent external code accidentally creating instances, you might also make the constructors protected, internal, or private protected (which means the intersection of protected and internal). We could also try using the SkipConstructor=true modifier on [ProtoContract].

If that doesn't work: it might be necessary to basically work with 2 different object models; one that is simple - essentially more like the Java version, perhaps by running your schema through https://protogen.marcgravell.com/ - and one that has the inheritance; use the simple version for deserialization (and optionally serialization, although that shouldn't matter), and then re-map the data in your own code to the actual model. The other option is for me to figure out a way of doing all this magically and automatically; which: isn't a small job.

Since you are initializing the contract for Account in runtime, modify your initialization code as to set MetaType.UseConstructor = false as follows:

1. the schema parser/code generator
2. the runtime library

Now, what we also need to know is that there are multiple implementations of protobuf in .NET-land; relevant to this question, there is the Google implementation, and protobuf-net (there are others, but they don't relate to this question).

What I think you've done is: you've used the Google tools for step 1 ("protoc") but protobuf-net for step 2. The tools for 1 and 2 need to match: Google and Google is fine; protobuf-net and protobuf-net is fine - but not crossovers.

So, either:

a. use the Google runtime library instead of protobuf-net ("Google.Protobuf", as a nuget package), or b: use protobuf-net's schema tools and code gen (see https://protobuf-net.github.io/protobuf-net/contract_first.html, including the links at the bottom for other options)

If I'm right in my hunch, please let me know - I'll try to make protobuf-net recognize this scenario and at least offer suitable guidance

However!

No, it can't work with unknown subtypes unless you mean: by ignoring the subtype aspect completely and just treating it as though it were the known type.