protobuf-net 跨程序集边界[反]序列化
我在一个程序集中有一个基类，在另一个程序集中有大量从基类继承的生成类。当尝试解析 subclassType（SerializerT.cs 的第 248 行）时，使用 protobuf-net (r282) 序列化基类型列表会失败，因为子类不在基类的程序集中。将类移到一起并不是首选选项，而且我可以传递 List 是相当重要的。
这是我标记的基类。包含的类型根据需要用 ProtoMember(x) 标记。
[ProtoContract]
[ProtoInclude(1,"SomeItemType")]
[ProtoInclude(2,"AnotherItemType")]
[ProtoInclude(190,"YetAnotherItemType")]
public abstract class BaseItem
{
}
附带说明一下，这是评估使用 protobuf-net 替换 BinaryFormatter 在桌面应用程序和 SOAP Web 服务之间移动数据的一部分。
我能做这种事吗？有更好的办法吗？我只是错过了一些明显的东西吗？一个单独的长期问题是我是否应该做一些稍微不同的事情来为最终迁移到 3.5 做准备？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许使用
ProtoInclude的最简单方法是使用typeof，因为这会自动为您处理许多细微差别：或者您可以只使用程序集限定名称，因此：
在涉及多个
AppDomain的相当特殊的情况下，我发现您还可以使用AppDomain.TypeResolve事件发挥一些作用，但如果可能的话应该避免这样做。我还对管道中的元数据层进行了彻底的重新设计，从而在运行时提供了更大的灵活性（而不是必须在编译时声明所有内容，这会导致上面的一些痛苦）。Perhaps the easiest way to use
ProtoIncludeis withtypeof, since this will handle a lot of the nuances for you automatically:Alternatively you can just use assembly-qualified names, so:
In a rather peculiar case involving multiple
AppDomains, I've found you can also work some magic with theAppDomain.TypeResolveevent, 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).