C# 3.0 Tutorials: Auto-Implemented Properties (a.k.a Automatic Properties)

Note: This is the first part of my C# 3.0 tutorial series.

Auto-implemented properties is the C# 3.0 new feature that make property-declaration more concise. It helps you to save some of your time for typing a lot of codes. Please take a look the following code to know how it looks like.

class Car
public string Speed { get; set; }

Why Auto-Implemented Properties?

Looking back the way that we have been doing for creating a property in so many projects, do you notice that you have been writing so many line codes just for creating a simple property? Look at the code below.

public class Employee {
private int _id;
private string _firstName;
private string _lastName;

public int ID{
return _id;

public string FirstName {
get {
return _firstName;
set {
_firstName = value;

public string LastName {
get {
return _lastName;
set {
_lastName = value;

Code 1.0: Employee class that doesn’t use auto-implemented properties

This is what we used to create the property in C#. In order to create one simple property, we have to type extra four or five lines of code. So, if you have one hundred properties in different entity classes, you have to type toooo much code just for creating properties.

I think VS IDE team at Microsoft also awared of this situration. That’s why when they released Visual Studio 2005 with .NET framework 2.0, we got the better way to deal with creating properties. You can simply type “prop” and press “tab” key twice. then, VS IDE will generate the property for you. Or you can use “Encapsulate Field” from “Refactor” menu to create the property. Unfortunately, those features are available only in C# project type in VS 2005. If you are using VB.NET project, you won’t be able to use that feature.

And when Microsoft shipped .NET framework 3.0, the new feature called “Auto-Implemented Properties (a.k.a Automatic Properties)” is introduced in Framework 3. It helps you to save some of your typing time for declaring private variable, setting the value to that private variable and returning the value.

Take a look at the class that I have converted from normal class (Code 1.0) to the class with auto-implemented properties. It’s much shorter, right?

class Employee
public int ID{ get; private set; } // read-only
public string FirstName { get; set; }
public int LastName { get; set; }

Code 1.1: Employee class that uses auto-implemented properties


Auto-Implemented Properties is one of the most popular features of C# 3.0 and a lot of developers are really happy with that new feature. but you should know that auto-implemented properties are nothing new except it helps you to boost your productivity.


1. Can “Auto-implemented Properties” improve the performace?

No. It is just helping you to type shorter code but it doesn’t improve the performance since the compiler will generate the same as the way what it generates for normal class that doens’t have auto-implemented properties.

2. How can I make read-only or write-only auto-implemented properties?

You can make the accessor as private. For example: If you want to make read-only property then You can put “private” in setter. You can read more about that in C# 3.0 specification.

It mentioned like below in C# 3.0 specification ~

When a property is specified as an automatically implemented property, a hidden backing field is automatically available for the property, and the accessors are implemented to read from and write to that backing field.

Because the backing field is inaccessible, it can be read and written only through the property accessors. This means that automatically implemented read-only or write-only properties do not make sense, and are disallowed. It is however possible to set the access level of each accessor differently. Thus, the effect of a read-only property with a private backing field can be mimicked like this:

public class ReadOnlyPoint {
public int X { get; private set; }
public int Y { get; private set; }
public ReadOnlyPoint(int x, int y) { X = x; Y = y; }

Okay. This is all about Auto-Implemented Properties (a.k.a Automatic Properties). If you have any suggestion or comment, please drop a comment in this post. Thank you!

15 Replies to “C# 3.0 Tutorials: Auto-Implemented Properties (a.k.a Automatic Properties)”

  1. I found an error:
    “Unfortunately, those features are available only in C# 2.0.”

    Those features are from VS, not from the language itself.

    Anyway, nice article :-D

  2. I know that automatic properties doesn’t include in C# 3.0 specification.. but it seems to me that it’s new feature… can you tell me how you got that error “Unfortunately, those features are available only in C# 2.0.”? maybe. I would need to do something..

  3. Hi Michael,
    Maybe I have not expressed correctly…
    The error was in your article:
    “Or you can use “Encapsulate Field” from “Refactor” menu to create the property. Unfortunately, those features are available only in C# 2.0.”
    Those features are not in the language, but in the IDE.

  4. oh.. yes.. i see thanks. but what I was trying to say is that both ““Encapsulate Field” from “Refactor”” and “prop” with two tabs” can used with C# in VS 20005. If you are using VB.NET, those feature are not available in VS 2005.

  5. Michael

    Automatic properties are useful, but there are drawbacks to getting into the mindset of using this. Consider that you have an automatic property – what benefit are you actually getting? How is this an improvement on just exposing a field?

    You would normally want to use a property to do more than just control access to the field – so you might put some code into the property setter to notify you that the property has changed. This means that you are going to have to forgo the automatic property and actually handle it yourself.

  6. Pete
    it can be useful when you have a read only property that is not likely to change during the objet lifetime / that is not likely to throw event notifications.

    Then typing :

    public int YearBorn { get; private set; }

    can be nice.

    I agree that this is not the common scheme.

  7. Another benefit I found was in debugging. In the traditional way of defining property when you F10 that statement, the debugger goes into the property. This is rather annoying when you know it’s a one-liner.

    With auto-property the debugger skips the internal and goes to inspect the next statement. Pretty darn convenient.

  8. The main reason to expose something as a property instead of a field is so that is you discover later on that you need to add logic around that field, you can do so without making a binary breaking change. This has always been the official guidance, but many people still used fields because they felt like properties were too verbose. Automatic properties were added to make it easier to do the right thing.

  9. What are your thoughts on initializing properties in the constructor? I have been searching for info on what the CLR initialzes different types to (eg. for type ‘string’ is it null or string.empty) and have not been able to find much information on it. If you know of any sites or where on MSDN that it’s explained it would be helpful.
    I have found a few sites that say to just let the CLR initialize values (unless a special value is needed of course) but I would really like to know what value things will be initialized to if I don’t specify one.

  10. Almost up to now I believed that Microsoft did something clever, that, anyway, it could have done much earlier but unfortunately I was wrong. Setting up an auto-implemented property like:

    class A
    public int myInt {get; set;}

    is completely rediculus and useless. Absolutely the same functionality is achieved by setting a variable like:

    public int myInt;

    Can anyone tell the difference?!?
    …maybe there are some achivements if we are going to inherit the class

    What is really new is setting one of either GET or SET to private, but that’s not completely logic of a property.

    I thought they had made, and something that would be meaningfull is:

    public int myInt
    { get;
    set { myInt=value;
    //some other stuff caused by changing the value


    public int myInt
    { get
    { //some calculation
    return result;

    So in this way you would be able to write only the part of the code that is different from “default codes” for get and set….
    ….I am really pissed off!

Leave a Reply