Is it possible to access backing fields behind auto-implemented properties?

I don't know about you, but I've written code in projects in other companies, and now I want to know how I did something! So it's usually quicker to do a web search for the answer, and it brought me here.

However, my reasons are different. I'm unit testing, and don't care what purists have to say, but as part of a setup for a unit test, I'm trying to invoke a certain state for a given object. But that state should be controlled internally. I don't want some other developer accidentally messing with the state, which could have far reaching effects upon the system. So it must be privately set! Yet how do you unit test something like that without invoking behaviours that (hopefully) will never happen? In such scenarios, I believe that using reflection with unit testing is useful.

The alternative is to expose things we don't want exposed, so we can unit test them! Yes, I've seen this in real life environments, and just thinking about it still makes me shake my head.

So, I'm hoping that the code below might be useful.

There are two methods here just for separation of concerns, really, and also to aid in readability. Reflection is head-spinning stuff for most developers, who in my experience either shy away from it, or avoid it like the plague!

private string _getBackingFieldName(string propertyName)
{
    return string.Format("<{0}>k__BackingField", propertyName);
}

private FieldInfo _getBackingField(object obj, string propertyName)
{
    return obj.GetType().GetField(_getBackingFieldName(propertyName), BindingFlags.Instance | BindingFlags.NonPublic);
}

I don't know what code conventions you work to, but personally, I like helper methods to be private and begin with a lower case letter. I don't find that obvious enough when reading, so I like the preceding underscore too.

There is discussion of backing fields, and their automatic naming. For the purpose of unit tests, you'll know pretty quickly if it has changed or not! It won't be catastrophic to your real code either, just the tests. So we can make simple assumptions about the naming of names—as I have above. You may disagree, and that's fine.

The more difficult helper _getBackingField returns one of those reflection types, FieldInfo. I've made an assumption here too, that the backing field you're after is from an object that's an instance, as opposed to being static. You can break that out into arguments to be passed in if you wish, but the waters will sure be muddier to the average developer who might want the functionality but not the understanding.

The handy thing about FieldInfos is that they can set fields on objects that match the FieldInfo. This is better explained with an example:

var field = _getBackingField(myObjectToChange, "State");
field.SetValue(myObjectToChange, ObjectState.Active);

In this case, the field is of an enumeration type called ObjectState. Names have been changed to protect the innocent! So, in the second line, you can see that by accessing the FieldInfo returned previously, I can call upon the SetValue method, which you might think should already relate to your object, but does not! This is the nature of reflection—FieldInfo separates a field from where it came from, so you must tell it what instance to work with (myObjectToChange) and thus, the value you want it to have, in this case, ObjectState.Active.

So to make a long story short, object-oriented programming will prevent us from doing such nasty things as accessing private fields, and worse, changing them when the developer of the code did not intend. Which is good! That's one of the reasons C# is so valuable, and liked by developers.

However, Microsoft gave us Reflection, and through it, we wield a mighty weapon. It may be ugly, and very slow, but at the same time, it exposes the innermost depths of the inner workings of MSIL (MicroSoft Intermediate Language)—IL for short—and enables us to pretty much break every rule in the book, this being a good example.

UPDATE: https://github.com/jbevain/mono.reflection comes with a backing-field resolver method which works with auto-properties generated by C#, VB.NET, and F#. The NuGet package is at https://www.nuget.org/packages/Mono.Reflection/

ORIGINAL: I ended up with this fairly flexible method for only C# auto-properties. As the other answers make clear, this is not portable and won't work if the compiler implementation uses a backing field naming scheme other than <PropertyName>k__BackingField. As far as I've seen, all implementations of C# compilers currently use this naming scheme. VB.NET and F# compilers use another naming scheme that won't work with this code.

private static FieldInfo GetBackingField(PropertyInfo pi) {
    if (!pi.CanRead || !pi.GetGetMethod(nonPublic:true).IsDefined(typeof(CompilerGeneratedAttribute), inherit:true))
        return null;
    var backingField = pi.DeclaringType.GetField($"<{pi.Name}>k__BackingField", BindingFlags.Instance | BindingFlags.NonPublic);
    if (backingField == null)
        return null;
    if (!backingField.IsDefined(typeof(CompilerGeneratedAttribute), inherit:true))
        return null;
    return backingField;
}

In Visual Studio 2010 at least, you can get the list of private fields in a class using reflection if you explicitly state that you want the non-public instance fields:

FieldInfo[] myInfo = ClassWithPostalCode.GetType().GetFields(BindingFlags.Instance | BindingFlags.NonPublic);

You can then loop through the FieldInfo array. In this case you will see that the name of the backing field will probably be

<PostalCode>k__BackingField

I've noticed that all automatic properties seem to follow the pattern of property name in angle brackets followed by "k__BackingField", but keep in mind that this is not official and can change in future versions of .Net. I'm not entirely certain it isn't different in past versions, for that matter.

Once you know the field name, you can get its value this way:

object oValue = obj.GetType().InvokeMember(fi.Name
    , BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Instance
    , null, obj, null);

See the following excerpt from this document:

Automatically implemented (auto-implemented) properties automate this pattern. More specifically, non-abstract property declarations are allowed to have semicolon accessor bodies. Both accessors must be present and both must have semicolon bodies, but they can have different accessibility modifiers. When a property is specified like this, a backing field will automatically be generated for the property, and the accessors will be implemented to read from and write to that backing field. The name of the backing field is compiler generated and inaccessible to the user.

Thus, there is no way to access fields. Utilize your first approach. Auto-implemented properties are specifically for the case where you don't need to access backing field.

This comes straight from the MSDN:

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 that can only be accessed through the property's get and set accessors.

So no you can't.