Caller Information Attributes

Version 4.5 of the .Net framework introduces 3 new attributes in the System.Runtime.Compiler namespace. These are CallerFilePathAttribute, CallerLineNumberAttribute and CallerMemberNameAttribute. They are used to obtain information about the caller to a method, and are handy for tracing call flow for diagnostics. The CallerMemberNameAttribute is also particularly useful when calling a PropertyChanged method, if your class implements INotifyPropertyChanged.

A quick code example shows the usage ( all code here is available as a GitHub:Gist)

The output from this demo is:

The new attributes are at lines 20, 21 and 22 of the code. As you can see in the example, to use one of the attributes, it must be used to decorate an optional parameter on a method - the parameter will be set to the correct value at runtime.

INotifyPropertyChanged Usage

One major benefit of the CallerMemberNameAttribute is in a class that implements the INotifyPropertyChanged interface. This interface has an event in the form of PropertyChanged(string propertyName), and will be called from each property's setter method when the value changes. This leads to a lot of magic strings in code, for example:

This brittle code can be avoided by using the attribute like this:

What members does it work with?

As well as methods, properties and events, the attributes will work for these member types:

• Constructor, value is ".ctor
• Explicit conversion operator, value is "op_Explicit"
• Implicit conversion operator, value is "op_Implicit"
• Indexer, value is "Item"
• Operator overload, value is e.g. "op_Addition"
• Finaliser, value is "Finalize"

Where does the info come from?

The attributes work by inspecting the IL of the calling code. For instance, the IL for the Main() method of my first example contains these items of info:

As I said before, all code here is available as a GitHub:Gist

Simple Breakpoint Options in VS2012

When you create a breakpoint in Visual Studio 2012, you have certain options available that determine exactly when the debugger breaks and what happens when it does. These options are available via the Breakpoints window (Debug -> Windows -> Breakpoints, or Alt+F9)...

...or by right-clicking the breakpoint:

I'll go through the first few of these menu options and describe its use.

Delete Breakpoint

No surprises here; selecting this menu item has the same effect as hitting F9. It deletes the breakpoint.

Disable Breakpoint

This option disables the breakpoint, so Visual Studio won't break at this breakpoint until it is enabled.

Location...

This shows a window that allows the code location of the breakpoint to be edited:

This is useful if e.g. you have multiple code statements on the same line; it allows you to set a breakpoint on a specific statement, by selecting the character position of a character in the required statement (note, this can also be achieved by selecting the statement and hitting F9) :

The screen gives the option to Allow the source code to be different from the original version. When this option is selected, if the source file of a debugged library has changed from the version referenced, the debugger will still allow the referenced version to be debugged.

Condition...

This shows a window that allows you to change the condition that must be satisfied before the debugger stops the code at the breakpoint:

The condition can be set to Is true, i.e. when the condition is met, or Has changed, i.e. when the specified variable or expression evaluates to a new value.
The example above sets the breakpoint to break when the variable loopCounter is equal to 719 0r 725:

Hit Count...

This shows a window that allow you to specify the number of times the breakpoint needs to be hit before the debugger breaks:

The default for a breakpoint is for it to break every time the statement is reached. Other options allow you to specify a numeric value that is used to calculate whether the debugger should break:

This example causes the debugger to break when the statement has been hit 183 times:

While the debugger is paused at the breakpoint, opening the Hit Count window shows the current hit count, and allows you to reset it so that the count starts again from zero.