The DebuggerNonUserCode attribute has the same effect as using both the DebuggerHidden and DebuggerStepThrough attributes at the same time. In the default Visual Studio configuration, code marked with this attribute will appear as external code in the call stack as shown below. As with the DebuggerStepThrough attribute, breakpoints cannot be set in blocks of code marked with this attribute. Stepping through code will step into any code called by that block of code in the same way it does for the DebuggerHidden attribute.

Code that is marked with the DebuggerNonUserCode attribute will be visible in the call stack if you disable the Just My Code option under Tools->Options->Debugger->Enable Just My Code (Managed Only).

DebuggerStepperBoundary is probably the most obscure of all of the Debugger attributes, as it only comes into effect under quite specific conditions. It is used to avoid a misleading debugging experience that can occur when a context switch is made on a thread within the boundaries of the DebuggerNonUserCode attribute. It is entirely possible in this scenario that the next user-supplied code module stepped into may not actually relate to the code that was in the process of being debugged. To avoid this undesirable situation, the DebuggerStepperBoundary, when encountered under this scenario, will escape from stepping through code to running code.

As with all of the debugger attributes, both the DebuggerNonUserCode and DebuggerStepperBoundary attributes are ignored by the CLR and as such have no affect during normal execution. So you do not need to worry about any implications of leaving any of these attributes in place in production code.

Similar to the DebuggerHidden attribute, breakpoints cannot be set within a block of code marked with the DebuggerStepThrough attribute. However, within the call stack the attributed code will be marked as external code. For example, consider the following code snippet where the DebuggerStepThrough attribute has been set on HiddenMethod:

private void ClickHandler(object sender, EventArgs e)
{
   HiddenMethod();
}

[DebuggerStepThrough()]
public void HiddenMethod()
{
   Console.WriteLine("Can't set a breakpoint here");
   NotSoHiddenMethod();
}

public void NotSoHiddenMethod()
{
   Console.WriteLine("Can set a breakpoint here!");
}

If you run this code with a breakpoint set in NotSoHiddenMethod, the call stack will appear as shown below:

Visual Studio 2008 supports the Just My Code option, configurable from the Debugging node in the Options dialog (select Tools > Options). Unchecking this option makes all code contained within your application appear in the call stack, as shown below. This includes designer and other generated code that you might not want to debug. Once this option is unchecked, breakpoints can also be set in blocks of code marked with this attribute.

DebuggerStepThrough is very useful when working with code that calls a lot of properties, for example, if you are calling a method that passes in a large number of properties as parameters. If you add the DebuggerStepThrough attribute to all the properties, and then you won’t step into all of the properties when debugging the method call.

This is something you probably only want to apply to VERY well tested code. Code marked with the DebuggerHidden attribute will be stepped over during debugging, and the method call will not even appear in the Call Stack window. However, if some code marked with this attribute makes a call to another method, the debugger steps into that method.

It’s also worth noting that any breakpoints that have been set in code marked with the DebuggerHidden attribute will be ignored. For example, in the following code snippet, a breakpoint can be set in both ClickHandler and NotSoHiddenMethod:

private void ClickHandler(object sender, EventArgs e)
{
   HiddenMethod();
}

[DebuggerHidden()]
public void HiddenMethod()
{
   Console.WriteLine("Can't set a breakpoint here");
   NotSoHiddenMethod();
}

public void NotSoHiddenMethod()
{
   Console.WriteLine("Can set a breakpoint here!");
}

If you step through this code, the debugger goes from the call to HiddenMethod in the ClickHandler method straight to the NotSoHiddenMethod. The call stack at this point is shown below, and you can see that HiddenMethod does not appear in the stack.

As with all of the System.Diagnostic attributes, the CLR will ignore this, so you will still see the method call in the stack trace of any an exceptions thrown at runtime.

No doubt you’ve seen that hovering your mouse over a variable while you are in Break mode will cause a tooltip to be displayed, which shows the type of object you are hovering over. You can see this below, where the datatip for a Customer object is shown.

Unfortunately this information is not particularly useful, as most of the time you have a fairly good idea about the type of object you are dealing with. It would be better for this single line to contain more useful information about the object, as is the case with simple types such as strings or integers where the actual value is displayed.

This is where the DebuggerDisplay attribute comes in handy. It can be used to change this single line representation of the object from the default full class name. The attribute takes a single parameter, which is a String. The format of this string can include the { and } braces, which can contain a field, property, or method that returns a value.

For example, you could apply the DebuggerDisplay attribute to the Customer class as follows:

[DebuggerDisplay("Customer {CustomerName} has {Orders.Count} orders")]
public class Customer

If you apply the attribute in this way, it will result in the following datatip:

If you are a C# developer, then in addition to specifying properties and methods in the DebuggerDisplay format string, you can also include a general expression within the braces. For example, the following attribute shows how you could use an expression with a ternary operator:

[DebuggerDisplay("Customer {CustomerName} has orders? {(Orders.Count > 0) ? \"Yes\" : \"No\"}")]

Which would result in the following datatip:

One final thing to note, in addition to Classes, the DebuggerDisplay attribute can be applied to any Struct, Delegate, Enumeration, Field, Property, or even an entire Assembly.

The first attribute we will cover is the DebuggerBrowsable attribute. This attribute takes a DebuggerBrowsableState enumeration value as a parameter that determines how the member is displayed in the variable tree. In the following code snippet, the field Orders in the Customer class is set to Collapsed:

using System.Diagnostics;

public class Customer
{
   [DebuggerBrowsable(DebuggerBrowsableState.Collapsed)]
   public List<Order> Orders;
}

Collapsed is the default DebuggerBrowsableState that you would normally see in Visual Studio. If you apply this to a member then it will be displayed, but not expanded by default, as shown below.

The following shows the same snippet with DebuggerBrowsable set to the RootHidden value. In this case the actual Orders item does not appear as a top-level entry in the data window, just the contents of the collection.

Finally, the Never value will hide the member completely from the data window. This can be quite useful if you want to hide your private properties. You can see the effect of this below, where the Orders member does not appear at all.

In .NET Framework 2.0, the DebuggerBrowsable attribute is only interpreted by the C# debugger and has no effect when it is applied to Visual Basic code. This limitation has been removed in newer versions of the .NET Framework.

The best way to understand this is to see it in action. The screenshot below shows a new Customer object being created in a C# project within the Immediate window.

When you declare a new object in the Immediate window at design-time, Visual Studio will create an instance of that object. However even though it has created this object, Visual Studio will remain in design-mode (For those that are interested, it actually uses the Object Test Bench in the background). If you invoke a method or property that contains an active breakpoint, Visual Studio will change to debug mode and break at the breakpoint. Once you resume execution from the break Visual Studio will return to design-mode.

There are a few gotcha’s and caveats that you need to be aware of when performing design-time expression evaluation.

Firstly, within a Visual Basic project you can’t use an explicit variable declaration (for example, Dim myCust as Customer). Instead variables are declared implicitly using the assignment operator (for example, myCust = new Customer()).

Secondly, if you are using C#, IntelliSense is not available in the Immediate window during design-time expression evaluation. Visual Basic programmers are a little more spoilt, as they are given a limited form of IntelliSense here.

Thirdly, any statements you enter into the Immediate Window will be evaluated against whatever project is selected in the Solution Explorer. If no project is selected,Visual Studio will evaluate it against the startup project. If the code doesn’t exist is that project, you will get an error.

Finally, you can’t use design-time expression evaluation in any project that requires an execution environment. This includes Web projects, VSTO projects, Smart Device projects, and SQL projects. However as I mentioned earlier, the scope of this is per-project. Therefore, if you have a solution that contains a web project and a separate class library project for your business logic, you can use this method to test any of the business logic code.

For the first of what will become an ongoing weekly series of debugging tips I’d like to start off with one of my favourite windows in the whole of Visual Studio – the Immediate Window. This useful window can be used during both debugging and at design-time. The window is displayed using the keyboard shortcut Ctrl+Alt+I, or by selecting it from the Debug->Windows menu. You can also type immed in the Command window and it will display and switch focus to the immediate window.

Quite often when you’re debugging an application, you’ll want to evaluate a simple expression either to test a bit of functionality or to remind yourself of how something works. This is one situation where the Immediate window comes in very handy. This window enables you to run expressions as you type them, as shown below.

To make life easier, the Immediate window supports IntelliSense, and you can use the arrow keys to track back through the history of previous commands executed.

The Immediate window also allows you to execute any Visual Studio command. To submit a command you must enter a greater than symbol > at the start of the line. There is an extremely large set of commands available; in fact almost any action that can be performed within Visual Studio is accessible as a command. Fortunately IntelliSense makes navigating this list of available commands a little more manageable.

Nick blogged last year about aliases, which are available under both the Command and Immediate windows. One of the more well-known aliases is “?”, which is a shortcut for the Debug.Print command that prints out the value of a variable. As long as you have the Immediate window open, this is generally quicker and more convenient than bringing up a watch window, or hovering over a variable and waiting for the data tip to display.

If you start to become really dependant on the Immediate window for your debugging, you should consider enabling the option to Redirect all Output window text to the Immediate window. This option can be enabled under  Tools->Options->Debugging. Although the option says it redirects all Output window text, it will actually only redirect the debug messages (e.g. Debug.Print).

For those who can’t make it to sunny Perth for the session, as of next week I will be starting an ongoing, weekly series of blog posts covering all of the debugging tips and tricks that I can lay my hands on. I wrote 5 chapters on debugging in our upcoming Professional Visual Studio 2008 book, so there is plenty of material for me to draw from.

A recent post by Scott Guthrie included information on how to request access to the source code. For some reason Scott has edited the blog post to remove this information, but if you look in the comments for this post you will find all the details you need to request access.