Any reason to use auto-implemented properties over manual implemented properties?

Question

I understand the advantages of PROPERTIES over FIELDS, but I feel as though using AUTO-implemented properties over MANUAL implemented properties doesn\'t really provide any

Answer 1

One of the things that you will lose control over is the ability to specify the backing field as NonSerialized, but it is easy enough to create a backing field for the property in this case.

Forgot: if you or any product that you use performs reflection on the members (i.e. WCF), then you will see the mangled backing field name instead of a "pretty" backing field that you created.

This could be very important if you had previously provided access to the service or if you deserialize on the receiving end into the same class structure (i.e. the same classes are used on both ends of the WCF pipe). In this case, you would not necessarily be able to deserialize because you could guarantee that the backing field name is the same unless you share the same DLL as opposed to the source code.

A little more clarification: assume that you have a web service that exposes some of your business objects over WCF to a silverlight client that you have created. In order to reuse your business logic, your Silverlight client adds references to the source code for your business objects. If you have auto-implemented properties, you have no control over the backing field name. Since WCF serializes the members and not the properties, you cannot be sure that the object transferred to silverlight from the WCF service will deserialize correctly because the backing field names will almost certainly be mismatched.