A breakpoint can be set on a line of code by placing the cursor on that line and enabling a breakpoint using any of the following methods:

Selecting Location from the Breakpoint item on the right-click context menu for the line of code with the breakpoint set displays the File Breakpoint dialog, shown in Figure 40-2. Here you can see that the breakpoint is set at line 11 of the Customer.cs file. There is also a character number, which provides for the case in which multiple statements appear on a single line.

Figure 40-2. Figure 40-2

Another type of breakpoint that can be set is a function breakpoint. The usual way to set a breakpoint on a function is to select the function signature and either press F9 or use the mouse to create a breakpoint. In the case of multiple overloads, this would require you to locate all the overloads and add the appropriate breakpoints. Setting a function breakpoint enables you to set a breakpoint on one or more functions by specifying the function name.

To set a function breakpoint, select Break at Function from the New Breakpoint item on the Debug menu. This loads the New Breakpoint dialog shown in Figure 40-3, in which you can specify the name of the function on which to break. There is a toggle to enable IntelliSense checking for the function name. The recommendation is to leave this checked, because it becomes almost impossible to set a valid breakpoint without this support.

Figure 40-3. Figure 40-3

Unfortunately, the IntelliSense option doesn't give you true IntelliSense as you type, unlike other debugging windows. However, if you select the name of the function in the code window before creating the breakpoint, the name of the function is automatically inserted into the dialog.

When setting a function breakpoint, you can specify either the exact overload you want to set the breakpoint on or just the function name. In Figure 40-3, the overload with a single Guid parameter has been selected. Notice that unlike a full method signature, which requires a parameter name, to select a particular function overload, you should provide only the parameter type. If you omit the parameter information, and there are multiple overloads, you are prompted to select the overloads on which to place the breakpoint, as illustrated in Figure 40-4.

Figure 40-4. Figure 40-4

Another way to set a breakpoint is via the Call Stack window. When the application is in Break mode, the call stack shows the current list of function calls. After selecting any line in the call stack, a breakpoint can be set in the same way as a file breakpoint, as described earlier (toggle Breakpoint from the Debug menu, use the F9 keyboard shortcut, or use Insert Breakpoint from the context menu). Figure 40-5 shows a short call stack with a new breakpoint set on a control event on Form1.

Figure 40-5. Figure 40-5

The call stack is generated using function addresses. As such, the breakpoint that is set is an address breakpoint. This type of breakpoint is only useful within a single debugging session, because function addresses are likely to change when an application is modified and rebuilt.

A breakpoint condition can be specified by selecting Condition from the Breakpoint item on the right-click context menu for the breakpoint. This brings up the Breakpoint Condition dialog shown in Figure 40-6, which accepts a Boolean expression that determines whether the breakpoint will be hit. If the expression evaluates to false, the application continues past the breakpoint without breaking.

Figure 40-6. Figure 40-6

In the case of Figure 40-6, which is for a breakpoint set within the Order class, the condition specifies that the order total must be greater than 1000. As with most debugging windows, the Condition field provides rich IntelliSense support to aid writing valid conditions. If an invalid condition is specified, the debugger throws an appropriate error message and the application will break the first time the breakpoint is reached.

When a condition, or a hit count, as shown in the next section, is placed on a breakpoint, the breakpoint changes appearance. The solid red dot is replaced with a red dot with a white cross. When you move your mouse across this dot, the tooltip provides useful information about the breakpoint condition, as illustrated in Figure 40-7.

Figure 40-7. Figure 40-7

Sometimes it is more relevant to know when this condition changes status, rather than when it is true. The Has Changed option breaks the application when the status of the condition changes. If this option is selected, the application will not break the first time the breakpoint is hit, because there is no previous status to compare against.

Though it's perhaps not as useful as breakpoint conditions, it is also possible to break after a particular number of iterations through a breakpoint. To do this, select Hit Count from the Breakpoint item on the right-click context menu. Figure 40-8 shows the Breakpoint Hit Count dialog, which can be used to specify when the breakpoint should be hit.

Figure 40-8. Figure 40-8

Every time the application is run, the hit count is reset to zero, and it can be manually reset using the Reset button. The hit count is also unique to each breakpoint. The hit count condition is one of four options:

Figure 40-9 shows the Breakpoints window, which provides additional information about the status of each of the breakpoints. In this case, the breakpoint is set to break every second time. The current hit count is 2.

Figure 40-9. Figure 40-9

A single solution may contain multiple applications that need to be run at the same time. This is a common scenario when building a multi-tier application. When the application is run, the debugger can attach to all these processes, enabling them to be debugged. By default, when a breakpoint is reached all the processes will break. This behavior can be controlled from the Debugging (General) node in the Options window, accessible from the Options item on the Tools menu. Unchecking the Break All Processes When One Process Breaks checkbox enables processes to be debugged individually.

If a breakpoint is set in a class library that is used by more than one process, each process will break when it reaches that breakpoint. Because you might be interested in debugging only one of these processes, you can place a filter on the breakpoint that limits it to the process you are interested in. If you are debugging applications on multiple machines, it is also possible to specify a machine name filter.

In fact, filtering can be useful for a multi-threaded application for which you want to limit the breakpoints to a particular thread. Although the breakpoint will only be triggered when a thread matches the filter criteria, all threads will still be paused. Figure 40-10 shows the Breakpoint Filter dialog and the possible filter conditions.

Figure 40-10. Figure 40-10

To remove a breakpoint that is no longer required, select it, either in the code editor or in the Breakpoints window, and remove it using the Toggle Breakpoint item from the Debug menu. Alternatively, the Delete Breakpoint item from the right-click context menu or the Delete Breakpoint icon from the Breakpoints window toolbar will remove the breakpoint.

Instead of deleting a breakpoint, simply disabling the breakpoint can be useful when you have a breakpoint condition set or you are tracking a hit count. To disable a breakpoint, select it either in the code editor or in the Breakpoints window, and disable it using the Disable Breakpoint item from the right-click context menu. Alternatively, you can uncheck the checkbox against the breakpoint in the Breakpoints window. Figure 40-11 shows how a disabled breakpoint would appear in the code window.

Figure 40-11. Figure 40-11

The location of a breakpoint can be modified by selecting Location from the Breakpoint item on the right-click context menu. Depending on what type of breakpoint has been set, the dialog shows the location of the breakpoint as either a line and character position in a file or function, or as an address within an assembly. If the location is either a file or function position, the breakpoint can be adjusted so it is in the correct location. Address breakpoints are harder to relocate, because you need to ensure that the new address is a valid location for a breakpoint.

One new feature introduced in Visual Studio 2010 is the ability to assign a label to a breakpoint. This is particularly useful if you want to group a set of related breakpoints together. Once labeled, you can search for and perform a bulk action on all breakpoints with a specific label.

Figure 40-12. Figure 40-12

To assign a label to a breakpoint, right-click the breakpoint and choose Edit Labels. This displays the Edit Breakpoint Labels dialog, shown in Figure 40-12, where you can attach one or more labels to the breakpoint.

After you have labeled your breakpoints you can perform bulk actions on them by opening the Breakpoints window (Debug

Figure 40-13. Figure 40-13

Another new debugging feature in Visual Studio 2010 is the import and export of breakpoints. This feature allows you to back up and restore breakpoints, and share them among developers. This functionality was previously impossible, because the location of breakpoints is stored in the binary solution user options file (.suo), along with a whole raft of other user-specific information.

Export of breakpoints is performed from the Breakpoints window (Debug

Import of breakpoints can also be performed from the Breakpoints window by clicking the appropriate button on the toolbar.

As the dialog in Figure 40-14 suggests, a number of keywords can be used in conjunction with your trace message. However, a couple of keywords are not listed by the dialog: $FILEPOS, which gives the location of the current file, and $TICKS, which can be used as a relative time indicator.

Tracepoints can execute any Visual Studio macro, which includes macros you may have created. Because macros can be used to modify source code, be careful which macros you execute within a tracepoint. Modifying code while debugging an application may result in the source code being out of sync with the running application. Visual Studio macros are discussed in Chapter 52.

Stepping Over is fully executing the line that currently has focus and progressing to the next line in the current code block. If the end of the code block has been reached, Stepping Over returns to the calling code block.

Stepping Into behaves the same as Stepping Over when the line is a simple operator, such as a numeric operation or a cast. When the line is more complex, Stepping Into steps through all user code. For example, in the following code snippet, pressing F10 through the TestMethod only steps through the lines of code within TestMethod. Pressing F11 steps through TestMethod until the MethodA call is made, and then the debugger steps through MethodA before returning to TestMethod:

C#

public void TestMethod()
{
   int x = 5 + 5;
   MethodA();
}

private void MethodA()
{
   Console.WriteLine("Method A being executed");
}

If you step into a long method by accident, it is quite often convenient to be able to step back out of that method without having to either step over every line in that method or setting a breakpoint at the end of the method. Stepping Out moves the cursor out of the current method to where it was being called. Considering the previous snippet, if you entered MethodA, pressing Shift+F11 would immediately return the cursor to the end of TestMethod.

One very welcome feature that was introduced with Service Pack 1 of Visual Studio 2008 is the ability to automatically step over properties and operators. In many cases, public properties are simply wrappers for a private member variable, and as a result there is very little to be gained from stepping into them while debugging. This debugger option is especially useful if you are calling a method that passes a number of properties as parameters, such as the method call listed here:

C#

printShippingLabel(cust.name, shipTo.street, shipTo.city, shipTo.state,
shipTo.zipCode);

With the Step Over Properties and Operators option enabled, the debugger steps directly into the first line of the printShippingLabel method if you hit F11. If you need to, you can manually step into a specific property by right-clicking the code editor window and selecting Step Into Specific. This displays a submenu with each of the available properties listed, as shown in Figure 40-17.

Figure 40-17. Figure 40-17

The Step Over Properties and Operators option is enabled by default. You can enable or disable it during debugging by right-clicking anywhere in the code editor window and selecting it from the context menu, or from the Options dialog window (Tools