There are two pseudovariables available in debugger when running C# or VB.NET project: $exception and $user. The former one relates to the last exception while the latter one displays information about the account which runs the application. I haven’t found much use for $user pseudovariable, but the $exception proved to be very useful in cases where I need to cast exception to a specific type.
For example, when working with remote WCF services, the service can indicate error through FaultException(TDetail), where TDetail is an object containing error details. The problem is that when debugger breaks on exception and you click View Detail…, not all properties will always be accessible. I came across this problem when working with Bing Ads services, but also when handling SoapExceptions while using Google AdWords services. In case of Bing Ads, the exception thrown will be FaultException<ApiFaultDetail>, where Detail property contains information buried in either BatchErrors or OperationErrors collection. Unfortunately, neither of those will show you more than the type name (see figure-1).
To get access to those properties you have to cast the exception to FaultException<ApiFaultDetail> type. You can easily do that without stopping debugger and modifying the code. Just cast $exception pseudovariable to given type in the watch window:
$exception as FaultException<ApiFaultDetail>
and you can access all the information. In my case the problem was invalid CampaignId.
How many times did you step into a method just to realise you didn’t want to? Sometimes it is a simple, short method and you can step through it. Other times it is one of those monstrosities spanning for dozens of lines, or a recursive function. Instead of stopping debugger and starting again to avoid the mistake you can actually step out from the method. Just click icon on the toolbar, or use Shift + F11 shortcut and the debugger will take you out.
When debugging your code and you want to step into one of the “outer” methods, either FormatResult or PrintMessage in the above example, then right click in the code window and select Step Into Specific option. The Visual Studio will show you list of all methods you can step into. Just click the one you want to debug and debugger will break there.
Imagine, you are in the debugging mode and the next statement is a loop. You do not want to step into this loop and waste time on iterating over items but you also do not want to step out of the method. What you can do is to place cursor in the line you would like the debugger to break and select Run To Cursor option from context menu (shortcut: Ctrl + F10). It is an easy way to jump through the code, breaking in chosen places to peek on variable values.
You can even use Run To Cursor for starting an application and breaking in selected line.
In the last Visual Studio Debugger Tips’n’Tricks I showed Run To Cursor option which allows for running debugger and breaking in selected line. Today I am going to present another option called Set Next Statement.
Set Next Statement (shortcut: Ctrl + Shift + F10) is very useful feature and allows to move execution pointer to selected statement. This can be used to not execute statement(s), like skipping line 27 in above example. It can also be used to run statement(s) again, by simply selecting Set Next Statement on the line already executed. When combined with editing variable values, this is a very powerful tool.
If you a mouse person, you can easily Set Next Statement by moving yellow arrow () on the left.
Today’s Tips’n’Trick is one which I value a lot. Lets say you are in the debugging session and you look at the Call Stack window to check what methods were invoked so far. You can see assembly names, method names, line numbers – even parameter types and names. But you cannot see parameter values! If you want to check what was the value of the input parameter you have to double click the line and check it’s value in Autos or Locals window. To compare values between methods you will have to jump back and forth.
But wait! There is a better way to do it. Right click in the Call Stack window and select Show Parameter Values option. Once selected, the parameter values will be displayed in the Call Stack window along with parameter names and types. This feature is extremely useful when debugging recursive functions.
If the parameter is a complex type, you can control what will be displayed by annotating the type with DebuggerDisplayAttribute.
This time I want to present you Tracepoints in Visual Studio debugger. Tracepoints are special kind of break points which allows you to specify an action to execute when hit. The most common case for trace point is to print some tracing message. Let’s look at the example. Below is the code that generates all possible combinations of numbers in given range1 and performs some processing on those:
This example is from the article “Association Rule Learning” by James McCaffrey published in MSDN Magazine↩