Acessing the backing field in an auto property

Question

Is there any way to access the backing field for a property in order to do validation, change tracking etc.?

Is something like the following possible? If not is there any plans to have it in .NET 4 / C# 4?

public string Name
{
    get;
    set
    {
        if (value != <Keyword>)
        {
            RaiseEvent();
        }
        <Keyword> = value;
    }
}

The main issue I have is that using auto properties doesn't allow for the same flexibility in validation etc. that a property with a explicit backing field does. However an explicit backing field has the disadvantage in some situations of allowing the class it is contained in to access the backing field when it should be accessing and reusing the validation, change tracking etc. of the property just like any other class that may be accessing the property externally.

In the example above access to the backing field would be scoped to the property thus preventing circumvention of the property validation, change tracking etc.

Edit: I've changed < Backing Field > to < Keyword >. I would propose a new keyword similar to value. field would do nicely although I'm sure it's being used in a lot of existing code.

Answer 1

No there isn't. If you want to access the backing field, then don't use auto properties and roll your own.

I agree that it would be great to have a field that was only accessible by the property and not by the rest of the class. I would use that all the time.

Answer 2

As the MSDN states:

"In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field can only be accessed through the property's get and set accessors."

Since you have additional logic in you accessors, the use of auto-implemented properties is not appropriate in your scenario.

While the backing field does exist, it is given a mangled name to stop you referencing it easily - the idea is that you never reference the field directly. For interests sake, you can use Reflector to disassemble your code and discover the field name, but I would recommend you not use the field directly as this name may indeed be volatile, so your code could break at any time.