对于哪些情况，protobuf-net不合适？
我们一直在使用BinarySerialization和我们的C＃app，但是需要序列化的类的大小和复杂性导致了sloooooow（de）序列化和大文件。
我们怀疑我们应该编写自己的自定义序列化程序; 但是protobuf-net声称比标准的.Net二进制序列化具有显着的速度和大小优势，并且可能比大量的定制序列化器更容易添加到我们的应用程序中。
在花费大量时间和精力试图让它为我们工作之前，我很想知道是否有任何交易破坏者。 我们正在使用通过接口定义的属性，抽象子类的通用列表，自定义位标志枚举等等。什么会阻止protobuf-net为我们工作？
protobuf-net做了它可以遵守的核心protobuf规范，然后一些（例如，它包括inheritance），但是：
- v1不是很擅长基于接口的属性（即
ICustomer等）; 我正在努力在v2中改进这个 - v1喜欢那里有一个无参数构造函数（这个要求在v2中解除）
- 你需要告诉它如何将模型映射到字段; 在v1中，这需要在类型上进行修饰（或者有一个选项可以从名称中推断出一些东西等）; 在v2中，这可以在外部完成
- 在v1中，标志枚举是一种痛苦; 在v2中，有一个选项可以将枚举作为原始整数传递，使其更适合于falgs
- 摘要和inheritance都很好，但您必须能够提前确定所有具体类型（将它们映射到整数键）
- 仿制药应该没问题
- 没有中间类型的锯齿状数组/嵌套列表也不行 – 你可以通过在中间引入一个中间类型来填充它
- 并非所有核心类型都具有内置支持（例如，新的日期/时间偏移类型）; 在“v2”中，如果需要，您可以为此引入自己的垫片
- 它是树序列化器，而不是图形序列化器; 我有一些想法，但还没有实现
如果您想要序列化的内容有一些有限的例子，我很乐意看看它是否可行（我是作者）。
当您必须与现有软件/现有标准进行交互时，这是不合适的。 例如，您无法使用它与SMTP服务器通信。
请在关于protobuf-net的博客上阅读此内容
有什么收获？ 在大多数情况下，就是这样。 WCF将使用protobuf-net用于任何合适的网络 对象（数据合同等）。 请注意，这是一个比较粗糙的刷子 但是，每个操作控制（你可以随时将界面拆分为 当然，不同的终点）。 此外，protobuf-net确实有一些微妙的差异（特别是关于空的 对象），所以运行你的unit testing等 请注意，它仅适用于全脂WCF; 从那以后，它无法帮助Silverlight等 它缺乏扩展function - 但这不是新的。 最后，WCF中的解析器很痛苦，而AFAIK想要完整的assembly细节 包括版本号; 所以当你获得新版本时还需要维护一件事。 如果有人知道怎么解决这个问题？