views:

31

answers:

2
[Serializable]
class MyClass
{
    [NonSerialized] int Foo { get; set; } // error
    [NonSerialized] int bar; // ok
}

Why is this disallowed?

I know about the workarounds such as

  • implementing ISerializable
  • switching to XmlSerializer/XmlIgnore
  • switching to a manually-implemented property

The question is specifically why is [NonSerialized] disallowed on properies, yet allowed on fields.

A: 

I think this is a case of fine-grained control requiring more effort on your part. In other words, an automatic property will by default have a serializable backing field. If you want anything other than the default, then you can't use an automatic property.

I had thought that using [field:NonSerialized] against the property might work, but it does not. The C# spec does not explicitly call out the serializability of the backing field, but it does include this (10.7.3):

The following example:
 public class Point {
    public int X { get; set; } // automatically implemented
    public int Y { get; set; } // automatically implemented
}
is equivalent to the following declaration:
public class Point {
    private int x;
    private int y;
    public int X { get { return x; } set { x = value; } }
    public int Y { get { return y; } set { y = value; } }
}

Thus, the backing field is serializable (the default).

HTH,
Kent

Kent Boogaart
+2  A: 

Properties are actually methods, they are not serialized by the binary serialization process. It's the fields that are serialized. So it only makes sense to specify NonSerialized on a field.

Thomas Levesque
Properties are not mere methods. Semantically they're a combination of methods and an implicit backing field. And all serializers in existence do see the backing field. So it makes sense to control the serialization of the implicit backing field via its property.
Stefan Monov
Indeed, they are actually a pair of method. But the backing field is implicit only for auto-properties, and might not exist at all for normal properties. Anyway, when the `NonSerialized` attribute was introduced, auto-properties didn't exist, so they couldn't have taken that consideration into account
Thomas Levesque
Ok, and if they were to make NonSerialized valid for properties *now*, they would have to differentiate between auto-properties and normal properties in the AttributeTargets enum. Which I believe can't be done without breaking compatibility. Accepted.
Stefan Monov