.NET 中与 BinaryFormatter 的向后兼容性

发布于 2024-09-16 02:40:07 字数 2254 浏览 3 评论 0原文

我们在 C# 游戏中使用 BinaryFormatter 来保存用户游戏进度、游戏级别等。我们遇到了向后兼容性的问题。

目标：

关卡设计师创建活动（关卡和规则），我们更改代码，活动应该仍然可以正常工作。在发布之前的开发过程中，这种情况每天都可能发生。
用户保存游戏，我们发布游戏补丁，用户应该仍然能够加载游戏
无论两个版本有多远，隐形数据转换过程都应该有效。例如，用户可以跳过前 5 个小更新并直接获取第 6 个更新。尽管如此，他保存的游戏应该仍然可以正常加载。

该解决方案需要对用户和关卡设计师完全不可见，并且尽量减少想要更改某些内容的编码人员的负担（例如，因为他们想到了更好的名称而重命名字段）。

我们序列化的一些对象图植根于一个类，有些则植根于其他类。不需要向前兼容性。

潜在的重大更改（以及当我们序列化旧版本并反序列化为新版本时会发生什么）：

添加字段（获取默认初始化）
更改字段类型（失败）
重命名字段（相当于删除它并添加一个新字段）
将属性更改为字段和返回（相当于重命名）
更改自动实现的属性以使用支持字段（相当于重命名）
添加超类（相当于将其字段添加到当前类）
单位）
以不同方式解释字段（例如以前以度为单位，现在以弧度为实现 ISerialized 的类型我们可以更改 ISerialized 方法的实现（例如，开始在某些非常大的类型的 ISerialized 实现中使用压缩）
重命名类，重命名枚举值

我读过：

版本容错序列化
IDeserializationCallback
[OptionalField(VersionAdded)]
[OnDeserializing]、[OnDeserialized]、[OnSerializing]、[OnSerialized]。
[NotSerialized]

我当前的解决方案：

我们通过使用 OnDeserializing 回调等内容，尽可能多地进行不间断的更改。
我们每两周安排一次重大更改，因此需要保留的兼容性代码较少。
每次进行重大更改之前，我们都会将我们使用的所有 [Serialized] 类复制到名为 OldClassVersions.VersionX 的命名空间/文件夹中（其中 X 是最后一个序数之后的下一个序数）。即使我们不打算很快发布版本，我们也会这样做。
当写入文件时，我们序列化的是这个类的一个实例： class SaveFileData { int version;对象数据；从文件
读取时，我们反序列化 SaveFileData 并将其传递给迭代“更新”例程，该例程执行如下操作

：

for(int i = loadedData.version; i < CurrentVersion; i++)
{
    // Update() takes an instance of OldVersions.VersionX.TheClass
    // and returns an instance of OldVersions.VersionXPlus1.TheClass
    loadedData.data = Update(loadedData.data, i);
}

为了方便起见，Update()函数在其实现中可以使用CopyOverlappingPart()函数，该函数使用反射将尽可能多的数据从旧版本复制到新版本。这样，Update() 函数只能处理实际更改的内容。

一些问题：

反序列化器反序列化为 Foo 类，而不是 OldClassVersions.Version5.Foo 类 - 因为 Foo 类是被序列化的。
几乎不可能测试或调试
需要保留许多类的旧副本，这很容易出错，脆弱且烦人
我不知道当我们想要重命名类时该怎么办

这应该是一个非常常见的问题。人们通常如何解决？

原文

We use BinaryFormatter in a C# game, to save user game progress, game levels, etc. We are running into the problem of backwards compatibility.

The aims:

Level designer creates campaign (levels&rules), we change the code, the campaign should still work fine. This can happen everyday during development before release.
User saves game, we release a game patch, user should still be able to load game
The invisible data-conversion process should work no matter how distant the two versions are. For example an user can skip our first 5 minor updates and get the 6th directly. Still, his saved games should still load fine.

The solution needs to be completely invisible to users and level designers, and minimally burden coders who want to change something (e.g. rename a field because they thought of a better name).

Some object graphs we serialize are rooted in one class, some in others. Forward compatibility is not needed.

Potentially breaking changes (and what happens when we serialize the old version and deserialize into the new):

add field (gets default-initialized)
change field type (failure)
rename field (equivalent to removing it and adding a new one)
change property to field and back (equivalent to a rename)
change autoimplemented property to use backing field (equivalent to a rename)
add superclass (equivalent to adding its fields to the current class)
interpret a field differently (e.g. was in degrees, now in radians)
for types implementing ISerializable we may change our implementation of the ISerializable methods (e.g. start using compression within the ISerializable implementation for some really large type)
Rename a class, rename an enum value

I have read about:

Version Tolerant Serialization
IDeserializationCallback
[OptionalField(VersionAdded)]
[OnDeserializing], [OnDeserialized], [OnSerializing], [OnSerialized].
[NotSerialized]

My current solution:

We make as many changes as possible non-breaking, by using stuff like the OnDeserializing callback.
We schedule breaking changes for once every 2 weeks, so there's less compatibility code to keep around.
Everytime before we make a breaking change, we copy all the [Serializable] classes we use, into a namespace/folder called OldClassVersions.VersionX (where X is the next ordinal number after the last one). We do this even if we aren't going to be making a release soon.
When writing to file, what we serialize is an instance of this class: class SaveFileData { int version; object data; }
When reading from file, we deserialize the SaveFileData and pass it to an iterative "update" routine that does something like this:

for(int i = loadedData.version; i < CurrentVersion; i++)
{
    // Update() takes an instance of OldVersions.VersionX.TheClass
    // and returns an instance of OldVersions.VersionXPlus1.TheClass
    loadedData.data = Update(loadedData.data, i);
}

For convenience, the Update() function, in its implementation, can use a CopyOverlappingPart() function that uses reflection to copy as much data as possible from the old version to the new version. This way, the Update() function can only handle stuff that actually changed.

Some problems with that:

the deserializer deserializes to class Foo rather than to class OldClassVersions.Version5.Foo - because class Foo is what was serialized.
almost impossible to test or debug
requires to keep around old copies of a lot of classes, which is error-prone, fragile and annoying
I don't know what to do when we want to rename a class

This should be a really common problem. How do people usually solve it?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

屌丝范 2024-09-23 02:40:14

这是一个非常古老的问题，但无论如何它需要一个最新的答案；我知道这有点偏离主题，所以请耐心听我说。今天，2019 年：我建议那些碰巧在项目中合理可行的阶段读到这篇文章的人认真考虑使用Protobuf 而不是 BinaryFormatter。它具有二进制格式（确实如此）的大部分优点，但缺点较少。

它可以轻松地在不同语言和技术堆栈之间工作（Java、.NET、C++、Go、Python）
它有一个经过深思熟虑的策略来处理重大更改（添加/删除字段等）意味着软件的“版本x”可以更轻松地处理“版本y”生成的数据反之亦然。是的，这确实是事实：旧版本的应用程序将能够处理使用新版本的 Protobuf .proto 接口定义序列化的数据。（反序列化时，不存在的字段将被忽略。）
相比之下，当运行较新版本的代码并反序列化旧数据时，数据中的“不存在”字段将被设置为其特定于类型的默认值。从这个意义上说，处理旧数据并不是“完全自动”的，但仍然比使用 Java 和 .NET 等平台附带的默认二进制序列化库简单得多。

如果您更喜欢非二进制格式，JSON 通常是合适的选择。对于 RPC 和此类场景，Protobuf 更好，甚至现在被 Microsoft 正式提及/认可： ASP.NET Core 上的 gRPC 简介。（gRPC 是构建在 Protobuf 之上的技术堆栈）