Visual Studio debugging skills

This is my 26th blog series on VS2010 and. Net4. Today's blog includes some useful debugging skills for. My friend ScottCate (he wrote a lot of good blogs about VS's tips and Tips) recently emphasized these good skills to me, most developers who use VS do not seem to know these skills (

This is my 26th blog series on VS2010 and. Net4. Today's blog includes some useful debugging skills for. My friend Scott Cate (who wrote a lot of good blogs about VS's tips and Tips) recently emphasized these great skills to me, most developers who use VS do not seem to know these skills (

This is my 26th blog series on VS2010 and. Net4.

Today's blog includes some useful debugging skills for. My friend Scott Cate (who wrote a lot of good blogs about VS's tips and Tips) recently emphasized these great skills to me, most developers who use VS do not seem to know these skills (even though most of them have been in the product development team for a while ). If you have not used these skills, I hope this blog will help you find them. They are easy to learn and can help you save a lot of time.

Run to cursor (Ctrl + F10)

I often see that people debug the application in this way: they set a breakpoint before the code that the application needs to debug, and then repeatedly press F10/F11 to gradually pass the code, until they reach the exact location they really want to study. Sometimes they need to carefully observe each line of code that is crossed, so using F10/F11 is reasonable. But more commonly, they just want to quickly enter the line of code they really care about-this is not the best choice to use F10/F11.

Instead, you may want to use the features supported by the debugger to "run to the cursor ". Simply place your cursor in the Code and press Ctrl + F10 at the same time. In this way, the program will run to the row where the cursor is located, and then execute the stop, which is controlled by the debugger-This saves you the time to repeatedly hit F10/F11 to get there. This works even if the line of code you want to run is not in the method or class currently being debugged, but in an independent method or class.

Conditional breakpoint

We often see another common technique in usability learning: developers set breakpoints, run programs, and try to input some data. When a breakpoint is reached, manually check whether certain conditions are true, if so, further research is decided. If the conditions do not match what they want, press F5 to continue executing the program, try other inputs, and then manually repeat the same process.

The conditional breakpoint function of VS provides an easier way to handle the above situations. Conditional breakpoint allows you to stop execution only when a specified condition is set. It is controlled by the debugger. This helps you avoid manual check/recovery of your program, saving you from manual work throughout the debugging process and being less tedious.

Set a conditional breakpoint

It is very easy to set a conditional breakpoint. In the code, press F9 to set a breakpoint for a line:

Right-click the breakpoint-the red circle on the left of the editor, and select "condition…" from the context menu ..." :

The following dialog box appears, allowing you to specify a condition that can be reached only when the condition is set. For example, we can use the following expression to specify that the program is aborted only when the number of paginatedDinners list elements is less than 10, which is controlled by the debugger.

Now, when I re-run the program to study it, the debugger will stop the program execution only when the return value of this search is less than 10. If the returned value is no less than 10, the breakpoint is not triggered.

Hit count function

Sometimes you only want to stop the execution when the nth condition is set. For example, the execution is aborted only when the return value for the first query is less than 10. Enable this function as follows: Right-click the breakpoint and select "hit count ..." Menu command.

The following dialog box will pop up to allow you to specify the conditions for program interruption: when the condition is met for the nth time, or when the condition is met for a multiple of N, or when the number of times the condition is met is greater than or equal to N.

Machine/thread/process Filter

You can right-click the breakpoint and select "filter ..." Menu command to specify that a breakpoint can be triggered only on a specific machine or a specific process or thread.

Tracking point-custom behavior when a breakpoint is hit

A debugging function that many people do not know is to use tracking points. A tracking point is a breakpoint. When it is hit, a custom Macro will be triggered for execution. This feature is especially useful when you want to study your application and do not want to stop it.

I will use a simple console program to demonstrate how to use tracking points. The following is the Recursive Implementation of the Fibonacci series:

In the above application, for specific input, we use Console. WriteLine () to output the final Fibonacci sequence. If we want to study the recursive process of Fibonacci In the debugging process -- without stopping the debugging execution? Tracking points can help us easily achieve this.

Set a tracking point

You can enable tracking in this way: Press F9 to set a breakpoint in the code, right-click the breakpoint, and select "hit condition…" from the context menu ..." Menu command:

The following dialog box is displayed, which allows you to specify what operations are performed when a breakpoint is triggered:

As shown above, we specify to print the trace information each time when the breakpoint condition is set. Note that the value of the local variable "X" to be output is specified as part of the output information. Local variables can be referenced through the {variable name} syntax. Embedded commands (such as $ CALLER, $ CALLSTACK, and $ FUNCTION) can be used to output common values in tracing information.

At the bottom of the dialog box above, we also select the "continue execution" button, which means we do not want the debugger to pause the program. On the contrary, the program will continue to execute-but the custom tracking information will be output when each breakpoint condition is met, which is different.

Now when we run the program, we will find that the custom tracking information will automatically appear in the VS output window-so that we can see the recursive process of the program.

You can also choose to set a custom tracking listener for your program-so that the output information of the tracking point will be redirected to it, rather than the VS output window.

Tracking point -- run a custom macro

I gave a speech in London last week. some people in the audience asked this question: is it possible to automatically output all local variables when a tracking point is hit.

This function is not built-in in VS, but you can enable it by writing a custom macro in VS, and then set a tracking point to call this macro when it is hit. To achieve this, open the macro window in VS (Tool> macro menu command ). Under the "MyMacros" node of the Project Manager, select a template or create a new template (for example, add a template named "UsefulThings"), and then paste the following VB macro code to the template, and save it:

   1: Sub DumpLocals()

   2:  

   3: Dim outputWindow As EnvDTE.OutputWindow

   4:  

   5:        outputWindow = DTE.Windows.Item(EnvDTE.Constants.vsWindowKindOutput).Object

   6:  

   7: Dim currentStackFrame As EnvDTE.StackFrame

   8:  

   9:        currentStackFrame = DTE.Debugger.CurrentStackFrame

  10:  

  11:        outputWindow.ActivePane.OutputString("*Dumping Local Variables*" + vbCrLf)

  12:  

  13: For Each exp As EnvDTE.Expression In currentStackFrame.Locals

  14:  

  15:            outputWindow.ActivePane.OutputString(exp.Name + " = " + exp.Value.ToString() + vbCrLf)

  16:  

  17: Next

  18:  

  19: End Sub

The preceding macro code checks the current stack in sequence, obtains all local variables, and displays them in the output window.

Use DumpLocals to customize macros

In the following simple application, we can use the custom "DumpLocals" macro:

In the return Statement of the Add method above, press F9 to set a breakpoint. Right-click the breakpoint and select "hit condition ..." Menu command:

The following dialog box will pop up. In the previous example, we selected the "Print Info" single variable and then manually specified the variable to be output. Here, we selected the "run macro" single variable, point it to the custom macro UsefulThings we created. dumpLocals:

We still select the "continue execution" option to ensure that the program can continue execution when the tracking point is hit.

Run the program

Now, when we press F5 to run the program and call the Add method, we will see the following output in the VS output window. Note: When a tracking point is hit, how does a macro automatically list the names and values of each variable.

Summary

VS debugger features are rich. I strongly recommend that you take some time to learn all its functions. The above tips and tricks are only a small part of the functions that many people do not really realize.

I have written other blogs about VS2010 debugger improvement.

Take a look at Scott Cate's great VS2010 skills and know-how series. You can learn how to make better use of. He has some great free videos and blogs.

Check out Jim Griesmer's great VS debugging skills and know-how series. He has many good skills and tricks to use.

I hope this will help you.

Scott

Original article: http://weblogs.asp.net/scottgu/archive/2010/08/18/debugging-tips-with-visual-studio-2010.aspx

Http://blogs.msdn.com/ B /scottgu/archive/2011/10/08/visual-studio.aspx? Wa = wsignin1.0