From e16f0009a4f43e48396496ee2019da680b907c9b Mon Sep 17 00:00:00 2001 From: Adam Sitnik Date: Wed, 9 Jul 2025 13:12:02 +0200 Subject: [PATCH 1/2] Mention how non-public fields of inherited classes are serialized --- .../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 25a4e5374997a..83f4dbd7b24e1 100644 --- a/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md +++ b/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md @@ -20,7 +20,7 @@ The was fi ## Member names -In most common scenario, the type is annotated with `[Serializable]` and the serializer uses reflection to serialize **all fields** (both public and non-public) except those that are annotated with `[NonSerialized]`. By default, the serialized member names will match the type's field names. This historically led to incompatibilities when even private fields are renamed on `[Serializable]` types. During migrations away from BinaryFormatter, it becomes necessary to understand how serialized field names were handled and overridden. +In most common scenario, the type is annotated with `[Serializable]` and the serializer uses reflection to serialize **all fields** (both public and non-public) except those that are annotated with `[NonSerialized]`. By default, the serialized member names of public fields will match the type's field names. For non-public fields defined in inherited classes, the member names consist of inherited type name, a `+` sign and the field name (`$InheritedClassName+$nonPublicFieldName`). Serializing field names has historically led to incompatibilities when even private fields are renamed on `[Serializable]` types. During migrations away from BinaryFormatter, it becomes necessary to understand how serialized field names were handled and overridden. ### C# auto properties From 508902adf01d8ceaa3cd2ee3fa98ab7ceeb420fd Mon Sep 17 00:00:00 2001 From: Jeff Handley Date: Fri, 25 Jul 2025 11:36:59 -0700 Subject: [PATCH 2/2] Fix grammar per review feedback Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- .../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 83f4dbd7b24e1..f9c3605802501 100644 --- a/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md +++ b/docs/standard/serialization/binaryformatter-migration-guide/functionality-reference.md @@ -20,7 +20,7 @@ The was fi ## Member names -In most common scenario, the type is annotated with `[Serializable]` and the serializer uses reflection to serialize **all fields** (both public and non-public) except those that are annotated with `[NonSerialized]`. By default, the serialized member names of public fields will match the type's field names. For non-public fields defined in inherited classes, the member names consist of inherited type name, a `+` sign and the field name (`$InheritedClassName+$nonPublicFieldName`). Serializing field names has historically led to incompatibilities when even private fields are renamed on `[Serializable]` types. During migrations away from BinaryFormatter, it becomes necessary to understand how serialized field names were handled and overridden. +In the most common scenario, the type is annotated with `[Serializable]` and the serializer uses reflection to serialize **all fields** (both public and non-public) except those that are annotated with `[NonSerialized]`. By default, the serialized member names of public fields will match the type's field names. For non-public fields defined in inherited classes, the member names consist of inherited type name, a `+` sign, and the field name (`$InheritedClassName+$nonPublicFieldName`). Serializing field names has historically led to incompatibilities when even private fields are renamed on `[Serializable]` types. During migrations away from BinaryFormatter, it became necessary to understand how serialized field names were handled and overridden. ### C# auto properties