谨慎
我们强烈建议防止 BinaryFormatter 使用，因为 存在相关的安全风险。 现有用户应从BinaryFormatter中迁出。
从 .NET 9 开始，我们不再在运行时中包含实现 BinaryFormatter 。 API 仍然存在，但无论项目类型如何，其实现始终会引发一个 PlatformNotSupportedException。 因此，设置现有的向后兼容性标志不再足以使用 BinaryFormatter。
有两个选项可以解决这一问题：
从 BinaryFormatter 迁移。 强烈建议调查因相关BinaryFormatter而停止使用 的选项。 下面列出了 几个选项 。
继续使用BinaryFormatter 如果需要在 .NET 9 中继续使用 BinaryFormatter，则需要依赖于 不受支持的 System.Runtime.Serialization.Formatters NuGet 包，以替换引发性实现。
使用 BinaryFormatter的风险是什么？
任何二进制或文本反序列化器，如果允许其输入携带有关要创建的对象的信息，那么就会有安全隐患问题。 有一个常见的弱点枚举（CWE）描述问题：CWE-502“反序列化不受信任的数据”。 BinaryFormatter（包含在 2002 年 .NET Framework 的初始版本中）是一种反序列化程序。 我们还在 BinaryFormater 安全指南中对此进行介绍。
由于已知使用 BinaryFormatter风险，该功能已从 .NET Core 1.0 中排除。 但是，如果没有明确的迁移路径来使用更安全的东西，客户需求导致 BinaryFormatter 包含在 .NET Core 2.0 中。 此后，.NET 团队一直致力于去除 BinaryFormatter，默认情况下在多个项目类型中逐渐将其关闭，仍需向后兼容的用户可以通过标志选用此功能。
有关该决定的更多详细信息，请参阅 .NET 9BinaryFormatter 公告中将要删除的 。
如果遇到与迁移指南中未解决的删除相关的 BinaryFormatter问题，请在 github.com/dotnet/runtime 提交问题，并指示此问题与删除 BinaryFormatter相关。
迁移主题
从BinaryFormatter 迁移一般意味着 选择不同的序列化程序。 但是，仅当同时控制编码数据的生成者和使用者时，这通常是可行的。 如果不控制生成者，还可以移动到我们的 新 API 来读取 BinaryFormatter 有效负载 ，而无需实例化任何编码类型。
下面探讨了这两个选项。
选择序列化程序
从 BinaryFormatter 中迁移的第一步是选择一个序列化程序来代替它。 根据具体需求，.NET 团队建议迁移到四个不同的序列化程序。
- 迁移到 System.Text.Json （JSON）
- 迁移到 DataContractSerializer （XML）
- 迁移到 MessagePack（二进制）
- 迁移到 protobuf-net（二进制）
读取 BinaryFormatter (NRBF) 有效负载
许多应用程序加载和反序列化已保存到存储中的数据负载，并且并非总能提前转换所有已持久化的数据负载。 其他情景可能涉及接收由 BinaryFormatter 生成的数据的系统或服务，这些系统需要独立迁移。
在这些场景及其他场景中，有必要保留对读取所提供负载的支持，并随着时间的推移过渡到新格式。 为了满足这些需求，现在可以在不执行常规用途和易受攻击的反序列化的情况下，安全地读取使用 创建的 BinaryFormatter。
迁移 Windows 窗体和 WPF 应用程序
Windows 窗体和 WPF 应用程序可能需要其他更改。 有关进一步迁移指南，请参阅 Windows 窗体应用、 WPF 应用和 WinForms/WPF 剪贴板和拖放指南 。
迁移托管资源 （ResX）
最常见的资源类型（如字符串和图标）在没有 BinaryFormatter 的情况下也能正常工作。 对于自定义类型，需要引入 BinaryFormatter 和启用兼容性开关，请参阅 在运行时加载资源。
使用兼容性包
对于在升级到 .NET 9 时无法实现从BinaryFormatter迁移的情况，可以使用一个不受支持的兼容包。 System.Runtime.Serialization.格式化器 NuGet 包包含BinaryFormatter的功能实现，包括其漏洞和风险。
虽然不支持，但不建议使用兼容性包，但本指南包含有关安装包和启用该功能的详细信息。
谨慎
我们强烈建议防止 BinaryFormatter 使用，因为 存在相关的安全风险。 现有用户应从BinaryFormatter中迁出。
