问题描述
编辑
深入挖掘后，我了解到我的问题是由不正确截断的 protobuf 流 (once again) 引起的。因此，我重新制定了这个问题，以关注相关问题中尚未回答的方面（请参阅“精炼问题”）。
背景
所以，我继承了大量使用 protobuf-net 的应用程序（这不是坏事:-)）。客户有大量的序列化数据，因此我必须与这些应用程序当前使用的 protobuf-net 版本保持向后兼容（至少，我必须能够反序列化他们拥有的数据）。问题来了：到目前为止，应用程序的所有部分都基于 protobuf-net 1.0.0.282，我非常想要/需要升级。而且，如您所想，我最初尝试更换新版本（从 v2 开始）失败了（我收到各种异常，例如“源数据中的字段无效：0”）。
原始问题
远离进入个别异常的细节，我的目标是升级到 protobuf-net 的非原始版本同时保持向后兼容性甚至可行吗？如果是，什么是一个好的起点？是否有关于如何开始这样一项事业的资源？我只在 github 存储库中找到了 this document，但我并没有在提到的 CompatibilityLevel 上取得多少成果。
问题
注意：这部分问题已经在评论中回答了——是的，协议是兼容的 远离进入个别异常的细节，我的目标是升级到 protobuf-net 的非原始版本同时保持向后兼容性甚至可行吗？如果是，什么是一个好的起点？是否有关于如何开始这样一项事业的资源？我只在 github 存储库中找到了 this document，但我并没有在提到的 CompatibilityLevel 上取得多少成果。
提炼问题
原来我真正的问题是编码的原始作者决定将 protobuf 数据序列化为最后补零的文件。不要问我为什么，但我对此无能为力——这些数据存在于客户机器上。 Protobuf-net 1.0.0.282 对这些文件非常满意，并正确地反序列化它们，而较新的版本（正确地）对它们进行了反序列化。现在，我能做些什么让新版本的 protobuf 接受零填充文件？如何在不破坏客户数据存档的情况下进行更新？
解决方法
据我所知，从 1.x 到 2.x（这是很长时间以前的非常）前后没有基本的配置变化，所以这应该 - 据我所知 - 是一个非常省力的升级。如果发生意外情况，示例类型和有效负载会很有用，尽管这对于 GitHub 来说可能比 Stack Overflow 更好。
实际的数据协议在任何时候都没有改变，所以没有根本原因这不应该起作用，老实说，我很惊讶你遇到了任何障碍。我很乐意提供进一步帮助，但是：我真的需要看到我面前的问题。