My current project is a UML modeling tool, and I’m working on the C# 3.0 bits. One of the things it lets you do is to Reverse Engineer your code and obtain the model. And that includes reversing the assemblies too.

C# 3.0 introduced Auto Properties (or Automatically Implemented Properties if you like the wordy versions 😀 ), and the tool lets you model them. To maintain the symmetry, reverse engineering should detect and mark the Auto Properties appropriately. This’s easy in case of a source file since the rule for identifying an Auto Property is pretty simple. It’s a property contained in a concrete type (non-abstract class/struct) which has both it’s accessors without their implementing bodies. Simple, eh?

But it gets a wee bit more complicated to do that once you compile it. Because, the compiler generates a body for the Auto Property accessors. So, the last bit about the accessors not having an implementing body fails. Essentially, it seems like there’s no way to distingush an Auto Property from a regular one once it’s been compiled. And in fact, you shouldn’t have to because that’s the whole idea! Auto Properties help reduce some clutter in code and possibly save you a few keystrokes and let the compiler do the gruntwork. So, if you’re trying to distinguish an Auto Property, think again. You probably don’t have to.

Anyways, I still wanted to see if there’s a way to do it and the first thing I did was to Google for it. Since that didn’t turn up anything useful, I decided to figure it out myself and fired up Reflector. Long story (relative to a blog post, that is) short, I figured it out and decided to write this post to fill up a gaping hole in the public knowledge base 😀

The C# compiler decorates all the stuff it generates with the CompilerGeneratedAttribute. Even vbc.exe & vjc.exe should do the same, but I haven’t checked. Since the accessors of an Auto Property are generated, they’re decorated too 🙂  Therefore, the rule for identifying an Auto Property after it’s been compiled is: It’s a property which has both the accessors, both of which have been decorated with the CompilerGeneratedAttribute. Simple isn’t it?

Here’s what my C# code looks like:

using System.Reflection;
using System.Runtime.CompilerServices;
 
public class PropertyWrapper
{
	private PropertyInfo _property;
 
	public PropertyWrapper(PropertyInfo property)
	{
		_property = property;
	}
 
	public bool IsAutoProperty
	{
            get
            {
            	return isGenerated(_property.GetGetMethod(true))
                    && isGenerated(_property.GetSetMethod(true));
            }
	}
 
    private bool isGenerated(MethodInfo method)
    {
        return method != null
            && method.GetCustomAttributes(typeof(CompilerGeneratedAttribute), false).Length == 1;
    }
}

Ironically, after doing all these, I realized there’s not much sense in distinguishing them anyway. I mean, they are your regular properties for most of the purposes. Moreover, in my case, the the information derived from the assembly is used only to let the user extend the existing types. i.e. create generalizations and such.. So, even the existing implementation doesn’t bother showing the assembly types in much detail. They’re mostly limited to the high level details like classes, interfaces and such..

Ultimately, it wasn’t really useful, but was interesting nonetheless 😀