Compiler information as part of code.

*** #ClassName : gives you the name of the current class


Often I setup loggers and stuff, and always do something like:

class blah

   static Logger Log = new Logger( “blah”);


what I’d like to do is have a context aware statement that got built at compile time (much like the old C++ __line and stuff) –

eg:    static Logger Log = new Logger( #className )


We’ve talked about this, but haven’t been able to come up with a clean way of doing it. We do understand the value.


*** #member : gives you the name of the member you are in


same as above, it’d be nice to be able to do things like put stuff about what procedure I’m in:


public void Blah()


    Log( #currentProcedure +  “: first line”);





*** “meta”  parameter definition


This is a little off the wall, but it’d be easy to do, and really cool – have a tag called “meta” which you can put on a parameter – which will actually compile to send information about the actual parameter

for instance, at the moment I have a thing called EnsureNotMissing( string, object), which just does a “if null throw exception (” parameter ” + name + ” is missing )

that means at the moment I have to say

      EnsureNotMissing( “myParam”, MyParam );


I would like to build

      public void EnsureNotMissing( object MyParam, meta(MyParam) objectData )


            if (myParam ==null)

                  throw new exception( (objectData as ParameterInfo).name + ” is null”);



so I can just say

      EnsureNotMissing( MyParam );   – and the compiler will actually throw in the other stuff, like the name


This would be a nice feature. It’s something we’ve touched on obliquely when we talked about __FILE__ and __LINE__

Comments (12)

  1. J. Daniel Smith says:

    How about wrapping the C# code with XML?

    There was some related discussion on Channel9 a few weeks ago: (there’s a link to a very simple sample on my website in the conversion).

    I think making the actual source code be XML would give you A LOT of potential to do all kinds of cool things.

  2. John Rusk says:

    >We’ve talked about this, but haven’t been able to come up with a clean way of doing it. We do understand the value.

    Please keep trying (to come up with a way) since it would be really handy, especially for data binding.

    Is there anything on the web where Microsoft have documented the various options that have been considered? I.e. so that users can submit feedback or suggestions.


  3. Erik Charlebois says:

    Isn’t this mostly aspect-oriented features such as those seen in AspectJ?

    There was an AspectC# project floating around as well.

  4. Jason G says:

    Ummm, There *Is Currently* a way to get the currently executing method/class.


    The #meta thing would be much tougher, since what he is really asking for is what the source code name for that slot on the stack is, which would depend on debugging symbols and I imagine constrain what the JIT compiler can do to optimize code.

    I would much, much rather have #file back. Possibly #line also, but I’ve had less use for that.

  5. John Rusk says:

    I guess the other thing that would be handy is some kind of summary of all the things that features like these might be used for. It seems like there are several different requirements that fall under the umbrella of "compiler information in the code". E.g.

    – getting (compiler-checked) property names for databinding.

    – getting information about the current method, line nor file.

    – getting information about the parameters that have been passed to a method ("meta" above).

    – what else?


  6. I am sure I am not the first one to think of that, but wouldn’t a clean way of doing that include a class like CurrentInfo, that would be perhaps in the Reflection or Runtime namespaces and would provide the attributed like CurrentFunctionName, CurrentClassName, CurrentClassNameSpace.

    You could also throw in CurrentOS, CurrentCPU, CurrentNetworkName, CurrentIPAddress in there as well.

  7. John Rusk says:

    After posting a few questions, above, I had an idea. Several of these requirements could be taken care of by a fairly "simple" mechanism which would allow identifiers to be treated as strings. It’s hard to explain in this little text box 🙂 so I’ve described it on my web site instead, for anyone who may be interested. See:


  8. Brett Alcorn says:

    How about "typeof()" with no arguments gives you the Type of the enclosing class? Then you could save typeof().Name

    Another post nearby suggested having a "memberof" which works as follows:

    – memberof(MyClass.MyProperty) returns a PropertyInfo

    – memberof(MyClass.MyMethod) returns a MethodInfo [although problems identifying overloaded methods]

    Then memberof() could return the MethodInfo of the enclosing method. Hence memberof().Name

  9. Kjell Holmgren says:

    MethodBase.GetCurrentMethod() is great. I wish there was a PropertyInfo.GetCurrentProperty() as well. I haven’t found a direct link from the meta for the currently executing property accessor method to the property. In order to account for compilers using other prefixes than "get_" or "set_", you will have to iterate through the PropertyInfo collection of the type in question and compare the return values of GetGetMethod() and GetSetMethod() to the value you get from GetCurrentMethod().

    By the way, what about adding MethodBase.GetCallingMethod() while we are about it?

    Anyway, the GetCurrentWhatever() obviously only work when you want to get the meta for the currently executing member. It will not work if you want to get the MemberInfo on any other member than the one executing right now.

    What about introducing a keyword like "infoof" (or something similar, in the spirit of "typeof") that returns the proper MemberInfo derivation (e.g. PropertyInfo for a property, MethodBase for a method, etc.)? I am not the first one to think of this, (see Brett’s post), but I think it can be expanded to work for any reflectable code entity, depending on context. I am mainly thinking of parameters here.

    This way, you will not have to use a string with the property name doing a binding, for instance; you can take advantage of IntelliSense and the compiler to make sure that you do not misspell the name. If you were to rename the member, you would get a compilation error; I really dislike hiding important logic information from the compiler in strings…

    I would like to be able to do something like this:

    Type propertyType = ((PropertyInfo)infoof(myObject.MyProperty)).PropertyType;

    object[] atts = ((MethodInfo)infoof(myObject.MyMethod)).GetCustomAttributes(true);

    textBox1.DataBindings.Add(infoof(textBox1.Text), myObject, infoof(myObject.FirstName));

    Using your example above, you could do something like this:

    public static void ThrowIfNull(object value, MemberInfo memberInfo)


    if(value == null)

    throw new ArgumentNullException(


    "Value may not be null.");


    And call it thus:

    ThrowIfNull(myParam, infoof(myParam));

    An alternate solution to this particular problem would be to introduce a new attributes, say, "NotNullAttribute", where the compiler would insert the necessesary code to check for null on assignment to parameters, fields, and properties.

    Come to think of it: why is Reflection referring to arguments as parameters (as in ParameterInfo) whereas the exception for a null parameter is called "ArgumentNullException"???

  10. MBA says:

    Helpful For MBA Fans.