1

In all my learning about xml serialisation the samples showed using a public property with a private back store field.

But then I found this:

https://blog.udemy.com/csharp-serialize-to-xml/

I also learned that with c# 3.0 you don't always need the backing store field as it is done behind the scenes.

So should I simplify my code and follow the link and just use public properties?

dbc
  • 104,963
  • 20
  • 228
  • 340
Andrew Truckle
  • 17,769
  • 16
  • 66
  • 164
  • No problems if you are using `XmlSerializer`. But if you also mark your type as `[Serializable]` and you use `DataContractSerializer`, you will see ugly secret backing field names in the XML as shown in [Is there a way to make DataContractSerializer output cleaner XML?](https://stackoverflow.com/q/1953984). In general `[Serializable]` works poorly with auto properties, you might want to remove the attribute if you don't need it and you're not going to use explicit backing fields. – dbc Sep 03 '17 at 21:05

1 Answers1

1

Explicit private backing fields are completely unnecessary for XmlSerializer, which can only serialize public fields and properties. As long as the backing field is private, XmlSerializer has no way of detecting whether it is explicit or secretly created by the compiler as described in the docs:

When you declare [an auto-implemented property], the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.

If you are only serializing using XmlSerializer (or with DefaultContractResolver.IgnoreSerializableAttribute = true, which is the default), go right ahead and simplify your classes by using auto-implemented properties.

However, do be aware that auto-implemented properties work poorly with [Serializable]. When you mark a type with this attribute, you are indicating that it can be serialized by serializing its internal state -- its public and private fields1 -- rather than its external state -- its public properties. While this attribute is completely ignored by XmlSerializer, certain other serializers support it, including DataContractSerializer, DataContractJsonSerializer and BinaryFormatter. If you add the attribute to a type with auto-implemented properties, the names of the secret "anonymous" backing fields can start to appear in serialization streams created by those serializers. This sometimes leads to problems such as those in the following questions:

So, if you are using auto-implemented properties, my recommendation would be to remove the [Serializable] attribute from your type. You probably don't need it, data contract serialization works better without it, and in any event its use is being deprecated in .NET Core, as shown here and here. (Though reportedly binary serialization is getting implemented to some extent in .NET Core 2.0, see here for details.)

1 Why fields? In the .Net 1.1 time frame, there were still debates about whether serializing private state might be preferable to serializing public state. This is no longer debated, serialization of public state (or of state as specified by some data contract) is preferred.

dbc
  • 104,963
  • 20
  • 228
  • 340