public string SomeAutoProperty { get; set; }

vs

public string SomeField;

There are strong reasons why to pick property over field. That is not what I want to discuss. C# 3 stats introducing auto property, and this is strictly what I want to discuss

There are arguments that using property allows it to be more extendable for future modification. What's the difference between adding a validation to an auto-property or field? They both need recompilation anyway?

Assymetric accessors

The advantage of using AutoProperty is really having more control. You can't beat the conciseness of this:

public string SomeAutoProperty1 { get; private set; }
public string SomeAutoProperty2 { private get; set; }

Compositional

AutoProperty (and Properties in general) can be enforced by declaring it in an Interface. Something you can't do with fields.

public interface ISomeElement
{
  public string EnforcedProperty { get; set; }
}

So which one to use?

I always default to using auto properties, unless if I have special reason to use fields. What might those reasons be:

Private

if its private I tend to reserve on fields. The two advantages (assymetric access and composable) don't matter in a private situation.

Parameter passing mode

methods like Int32.TryParse(int, out int) requires a special parameter passing mode to push the value out. Another passing mode would obviously be passing by reference. Both of this pass mode only accept fields and not auto-properties.