UPDATED 10-Mar-2021: The Scaleout.Client library docs have serialization guidance here: https://static.scaleoutsoftware.com...les/serialization/serialization_overview.html
Yes, Microsoft introduced this big breaking change in .NET 5. Our .NET libraries have used the BinaryFormatter as the default serializer for many years--it's flexible and convenient to use when you're just getting started because you don't have to write any custom serialization code to use ScaleOut APIs. But most developers are pleasantly surprised to find that doing a little extra work to plug in something like prototbuf-net gives them a big performance boost.
So it's a good practice to move away from the BinaryFormatter if possible. While the security risk isn't particularly applicable ScaleOut's client library usage, the BinaryFormatter is very slow compared to modern, specialized serializers. You can use the
CacheBuilder.SetSerialization method to use a custom serializer in your app--the documentation has examples for how to use
Json.NET and
protobuf-net.
More About the Error
The security concerns behind this error are relevant when an application needs to deserialize untrusted data (in other words, if you allow users to serialize objects themselves and upload them to your system). For example, this would be a problem if you have a thick desktop client application written in C# (WinForms, WPF, UWP, etc) that performs serialization on the user's machine and sends then sends the object up to your server for deserialization--a malicious user could send an undesirable object containing an exploit.
However, the serialization performed by ScaleOut's APIs occurs entirely within the confines of the web server. In this case, no untrusted objects are deserialized. So if you don't want to swap out the BinaryFormatter just yet then you can use the
<EnableUnsafeBinaryFormatterSerialization> element for the time being with minimal risk--the scary warnings are primarily aimed at people who process serialized objects from end-users.
