{"id":53354,"date":"2024-08-28T10:05:00","date_gmt":"2024-08-28T17:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=53354"},"modified":"2024-12-13T13:59:04","modified_gmt":"2024-12-13T21:59:04","slug":"binaryformatter-removed-from-dotnet-9","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/binaryformatter-removed-from-dotnet-9\/","title":{"rendered":"BinaryFormatter removed from .NET 9"},"content":{"rendered":"

Starting with .NET 9, we no longer include an implementation of\nBinaryFormatter<\/code> in the runtime (.NET Framework remains unchanged). The APIs\nare still present, but their implementation always throws an exception,\nregardless of project type. Hence, setting the existing backwards compatibility\nflag is no longer sufficient to use BinaryFormatter<\/code>.<\/p>\n

In this blog post, I’ll explain why this change was made and what options you\nhave to move forward.<\/p>\n

TL;DR: What should I do?<\/h2>\n

You have two options to address the removal of BinaryFormatter<\/code>‘s\nimplementation:<\/p>\n

    \n
  1. Migrate away from BinaryFormatter<\/strong>. We strongly recommend that you\ninvestigate options to stop using BinaryFormatter<\/code> due to the associated\nsecurity risks. The BinaryFormatter migration guide<\/a> lists\nseveral options.<\/li>\n
  2. Keep using BinaryFormatter<\/strong>. If you need to continue using\nBinaryFormatter<\/code> in .NET 9, you need to depend on the unsupported\nSystem.Runtime.Serialization.Formatters<\/a> NuGet package,\nwhich restores the unsafe legacy functionality and replaces the throwing implementation.<\/li>\n<\/ol>\n

    <\/i>Note<\/strong><\/p>Please note that .NET Framework is unaffected by this change and continues to include an implementation of BinaryFormatter<\/code>. However, we still strongly recommend to stop using BinaryFormatter<\/code> from .NET Framework too, for the same reasons.<\/div><\/p>\n

    What’s the risk in using BinaryFormatter?<\/h2>\n

    Any deserializer, binary or text, that allows its input to carry information\nabout the objects to be created is a security problem waiting to happen. There\nis a common weakness enumeration (CWE) that describes the issue: CWE-502\n“Deserialization of Untrusted Data”<\/a>. BinaryFormatter<\/code>, included in the\nthe initial release of .NET Framework in 2002, is such a deserializer. We also\ncover this in the BinaryFormatter security guide<\/a>.<\/p>\n

    Why we removed BinaryFormatter<\/h2>\n

    We strongly believe that .NET should make it easy for customers to do the right\nthing and hard, if not impossible, to do the wrong thing. We generally refer to\nthis as the “pit of success”.<\/p>\n

    Shipping a technology that is widely regarded as unsafe is counter to this goal.\nAt the same time, we also have a responsibility to ensure customers can support\nand move their existing code forward. We can’t just remove widely used\ncomponents from a .NET release, even when communicated long in advance. We also\nneed a migration plan and stop gap options.<\/p>\n

    This removal was not a sudden change. Due to the known risks of using\nBinaryFormatter<\/code>, we excluded it from .NET Core 1.0. But without a clear\nmigration path to using something safer, customer demand led to\nBinaryFormatter<\/code> being included in .NET Core 2.0.<\/p>\n

    Since then, we have been on the path to removing BinaryFormatter<\/code>, slowly\nturning it off by default in multiple project types but letting consumers opt-in\nvia flags if still needed for backward compatibility:<\/p>\n