From b1298933a3012a7b4c41bc8c396e6bd36a8c9758 Mon Sep 17 00:00:00 2001 From: Jeff Handley Date: Tue, 6 Aug 2024 19:43:15 -0700 Subject: [PATCH] Reword SerializationBinder note per suggestion Co-authored-by: Immo Landwerth --- .../binaryformatter-migration-guide/functionality-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md b/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md index d05f7e050f843..5f15713644445 100644 --- a/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md +++ b/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md @@ -86,4 +86,4 @@ It's recommended to use [SerializationBinder](/dotnet/api/system.runtime.seriali Using this type requires inheriting from it and overriding the [Type BindToType(string assemblyName, string typeName)](/dotnet/api/system.runtime.serialization.serializationbinder.bindtotype#system-runtime-serialization-serializationbinder-bindtotype(system-string-system-string)) method. -If your code uses a custom type that derives from `SerializationBinder`, it's likely that the list of serializable types is a **closed set**. If not, finding the list of all types that can get serialized and deserialized requires studying all the usages of `BinaryFormatter` in source code. **Knowing that list is crucial to determining how to move forward with the migration.** +Ideally the list of serializable types is closed set because it means you know which types can be instantiated which will help reduce security vulnerabilities.