As announced earlier, starting with .NET 9, we no longer include an implementation of BinaryFormatter in the runtime (.NET Framework remains unchanged). The APIs are still present, but their implementation always throws an exception, regardless of project type. Hence, setting the existing backwards compatibility flag is no longer sufficient to use BinaryFormatter.

• We published the BinaryFormatter migration guide. We'd appreciate if could give it a read and give us feedback by filling issues in the dotnet/docs repo.
• If you experience issues related to BinaryFormatter's removal not addressed in this migration guide, please file an issue in the dotnet/runtime repo and indicate that the issue is related to the removal of BinaryFormatter.

Why was it removed?

Docs

The primary reason is that BinaryFormatter is unsafe. Any deserializer, binary or text, that allows its input to carry information about the objects to be created is a security problem waiting to happen. There is a common weakness enumeration (CWE) that describes the issue: CWE-502 "Deserialization of Untrusted Data". BinaryFormatter is such a deserializer. We also cover this in the BinaryFormatter security guide.

What are my options to move forward?

Docs

You have two options to address the removal of BinaryFormatter's implementation:

1. Migrate away from BinaryFormatter. We strongly recommend you to investigate options to stop using BinaryFormatter due to the associated security risks. The BinaryFormatter migration guide lists several options.

2. Keep using BinaryFormatter. If you need to continue using BinaryFormatter in .NET 9, you need to depend on the unsupported System.Runtime.Serialization.Formatters NuGet package, which restores the unsafe legacy functionality and replaces the throwing implementation.