views:

119

answers:

1

I have a base class in one assembly and a large number of generated classes in another that inherit from the base class. Using protobuf-net (r282) to serialize a list of the base type fails when attempting to resolve the subclassType (line 248 of SerializerT.cs) because the subclass is not in the assembly of the base class. Moving the classes together is not a preferred option and it is rather important that I can pass around List.

Here is my tagged base class. The included types are marked with ProtoMember(x) as required.

[ProtoContract] 
[ProtoInclude(1,"SomeItemType")]
[ProtoInclude(2,"AnotherItemType")]
[ProtoInclude(190,"YetAnotherItemType")]
public abstract class BaseItem
{
}

As a side note, this is part of evaluating using protobuf-net to replace BinaryFormatter for moving data between a desktop app and a SOAP webservice.

Can I do this sort of thing at all? Is there a better way? Am I just missing something obvious? A separate longer term question is should I be doing anything slightly different to prepare for an eventual move to 3.5?

A: 

Perhaps the easiest way to use ProtoInclude is with typeof, since this will handle a lot of the nuances for you automatically:

[ProtoInclude(1, typeof(SomeItemType))]

Alternatively you can just use assembly-qualified names, so:

[ProtoInclude(1,"SomeItemType, SomeRandomAssembly")]

In a rather peculiar case involving multiple AppDomains, I've found you can also work some magic with the AppDomain.TypeResolve event, but that should be avoided if possible. I also have a complete re-working of the metadata layer in the pipeline, allowing much more flexibility at runtime (rather than having to declare everthing at compile, which is causing some of the pain above).

Marc Gravell
Thanks Marc, just what I was looking for. Using the full assembly-qualified name did the trick. Since my SomeItemType is not available at the base class, typeof(SomeItemType) isn't workable in this case. Thanks again.
tsupe