What are Automatic Properties in C# and what is their purpose?

Automatic Properties are used when no additional logic is required in the property accessors.
The declaration would look something like this:

public int SomeProperty { get; set; }

They are just syntactic sugar so you won't need to write the following more lengthy code:

 private int _someField;
 public int SomeProperty 
 {
    get { return _someField;}
    set { _someField = value;}
 }

Edit: Expanding a little, these are used to make it easier to have private variables in the class, but allow them to be visible to outside the class (without being able to modify them)

Oh, and another advantage with automatic properties is you can use them in interfaces! (Which don't allow member variables of any kind)

With normal properties, you can do something like:

private string example;
public string Example 
{
    get { return example; }
    set { example = value; }
}

Automatic properties allows you to create something really concise:

public string Example { get; set; }

So if you wanted to create a field where it was only settable inside the class, you could do:

public string Example { get; private set; }

This would be equivalent to:

private string example;
public string Example 
{
    get { return example; }
    private set { example = value; }
}

Or in Java:

private String example;

public String getExample() {
    return example;
}

private void setExample(String value) {
    example = value;
}

Edit: @Paya also alerted me to:

• http://msdn.microsoft.com/en-us/library/bb384054.aspx
• http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx

If you are asking why you would use Properties or Automatic Properties, this is the design philosophy behind it.

One important design principle is that you never expose fields as public, but rather always access everything via properties. This is because you can never tell when a field is accessed and more importantly when it is set. Now, a lot of the time, there is never any processing needed while setting or getting the value (for example, range checking). This is why Automatic Properties were created. They are a simple, one-line way of creating a property. The backing store for it is created by the compiler.

While this is what I do even for my internal programs, it is probably more important for ones designed for public use (for sale, open source, etc). If you use an Automatic Property and later decide that you need to do something else in the set or get, you can easily change your code without breaking the public interface.

Update

As a point of clarification to a comment below, if all of the code is your own, then no, it may not make much of a difference between a property and a field to you. But, if you are designing a library that will be consumed by others then switching back and forth between public fields and properties will cause exceptions unless the code using the library is recompiled first.

As a test, I created a library project and declared a property called TestData. I created a whole new project just to consume this library. All worked as expected. I then changed the property to a public field (the name stayed the same) and copied over the new library DLL without recompiling the consuming project. The outcome was an exception thrown as the code was expecting to find the methods property methods get_TestData and set_TestData, but fields are not accessed via methods.

Unhandled Exception: System.MissingMethodException: Method not found: 'Void TestLibrary.TesterClass.set_TestData(System.String)'.
   at TestLibraryConsumer.Program.Main(String[] args)