1

This is what reflector gives:

public int Int1 { get; set; }
public string StringA { get; set; }

// Fields
[CompilerGenerated]
private int <Int1>k__BackingField;
[CompilerGenerated]
private string <StringA>k__BackingField;

The problem is that C# specification doesn't explicitly specify how backing fields for automatic properties are named. This can be a problem for binary serialization (from book C# 3.0 in a Nutshell). Are there any other problems with auto-properties ? Should MS specify this in C# specs ?

pero
  • 4,169
  • 26
  • 27

2 Answers2

1

I don't think MS should specify a name - I think it's more reasonable to avoid binary serialization, which is always going to be somewhat brittle in my opinion. (Java serialization is similarly brittle.) If it relies on field names (and there may be a way of getting round that by attributing your properties - I'm not sufficiently experienced with binary serialization to know) then it's restricting implementation changes quite nastily already.

My biggest problem with automatic properties is that there's no way of creating genuinely readonly properties (with readonly backing fields). I've ranted about this before though...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
0

I don't like the following about auto-properties:

  1. It is not possible to place break points on auto-properties.

  2. The fields in the class are obvious, you will have to examine the fields as well as the properties to know what are the fields in the class. Where if they are not used, then you can just inspect the fields region.

  3. Removes the ability to decorate the underlying fields with readonly, volatile, etc.

vboctor
  • 895
  • 4
  • 9