• property with a { get .... ; } and a backing field
• a property with a { get .. ; private set .. ; }

Note that your bullet points aren't quite correct. If you're using an auto property (i.e. not having an explicitly defined backing field), then the second bullet point's getter and setter should not have a body.

Once you explicitly define the body of the getters and setters, you're no longer using an auto property and you are required to either have a backing field (or wire it to do whatever you need it to do).

As the name implies, auto properties automatically use a backing field. get; and set; will be translated into the default get => _myGeneratedBackingField; and set => _myGeneratedBackingField = value; statements respectively.

I'm unsure whether private set; get translated to private set => _myGeneratedBackingField = value; or if the assignments to your property instead get rewired to the backing field. I would assume the former but either is possible. But it functionally does not make a difference in either case.

At runtime, it makes no difference whether you explicitly use a backing field or not. The only difference is during design time (i.e. while coding), where's it's either a matter of preference (how you want to use it) or fringe cases such as reflection which depend on the existence of a particular field in your class.

Auto properties are just syntactic sugar. Nice to work with, but wholly irrelevant post-compilation.

• property with a { get .... ; } and a backing field
• a property with a { get .. ; private set .. ; }

Note that your bullet points aren't quite correct. If you're using an auto property (i.e. not having an explicitly defined backing field), then the second bullet point's getter and setter should not have a body.

Once you explicitly define the body of the getters and setters, you're no longer using an auto property and you are required to either have a backing field or wire it to do whatever you need it to do.

Good practice dictates that properties should represent a stored (get) and storeable (set) state, so any getter or setter with an explicit body should refer to some kind of state, e.g. a backing field, property, external resource, ...

As the name implies, auto properties automatically use a backing field. get; and set; will be translated into the default get => _myGeneratedBackingField; and set => _myGeneratedBackingField = value; statements respectively.

I'm unsure whether private set; get translated to private set => _myGeneratedBackingField = value; or if the assignments to your property instead get rewired to the backing field. I would assume the former but either is possible. But it functionally does not make a difference in either case.

At runtime, it makes no difference whether you explicitly use a backing field or not. The only difference is during design time (i.e. while coding), where's it's either a matter of preference (how you want to use it) or fringe cases such as reflection which depend on the existence of a particular field in your class.

Auto properties are just syntactic sugar. Nice to work with, but wholly irrelevant post-compilation.