. NET program debugging and tracing some methods

Objective

As a. NET development engineer, whether in writing a desktop program, a service program, or a Web program, in the development phase, we must be very familiar with the dynamic debugging skills of VS, of course the Web program may also need to debug the front-end script or style, which is not covered in this article. This article focuses on the basics of dynamic debugging VS, and describes how to track the debug logs or skills of a published program.

Development phase

This stage is mainly based on dynamic debugging, debugging the sharp weapon of course, vs.

Dynamic Debugging steps:

1, own the program code and PDB files;

2, in you want to observe the logical code line number under the breakpoint;

3, vs-> Debugging, start debugging (you may need conditions to trigger the execution of the program to your logical code line number);

4, for the running program, you can also vs-> debugging, attach to the process to complete startup debugging, if the program is running a service process (non-desktop process), in the Attach to Process dialog box to check the "Show all user Processes";

Conditional filtering of breakpoints

In dynamic debugging, if in the multi-threaded environment, a breakpoint after a break, if the use of "step by step" to the next statement, the breakpoint will be broken immediately, resulting in the tracking context is inconvenient; in another case, in the loop body, but only want to track the points that meet certain conditions. These times, you should use conditional breakpoints, under a code line number down, and then right-left red breakpoint solid circle, pop-up menu can set conditions for breakpoints, set the breakpoint after the condition, called conditional breakpoint, vs display as the red imaginary circle.

Production stage

In this stage, we can use remote dynamic debugging to debug the log files of the application, debug information output and exceptions, etc.

Log file

Maybe you think of log4net the first time, yes, it can write some debugging information and exception information to the file or DB, it is convenient to query. In addition, we should also understand exceptionless, its strength lies in the more perfect exception context content collection, exception classification display and summary, in Exceptionless View exception information, almost can statically analyze the cause of the exception to directly modify the code.

Collecting Debug information

For performance reasons, in the log file, we generally only record important and unusual content, less important to produce and frequent content, in the console, we can use CONSOLE.WRITEXXX to display these content in real time. In fact, as long as the System.Diagnostics.Debugger log method is called, the content of this method output, without debugging, you can also use some tools to capture these output, the following is provided by the two collection tools.

1. Collect with Debugviewer tool

This tool is a collection program that I've written using. NET, and the UI is a good friend, open source hosted on GitHub.

2. Collect with DebugView tool

Collect content from console.writexxx

While writing a console program, console.writexxx can easily be traced, but in non-console programs such as service processes, Windows desktop apps, and Web apps, these console.writexxx actually produce no output. Our goal now is that, in non-console type applications, the collection tool can collect these output information as long as the console.writexxx is called.

1. Replace the Out property of the Console static class when the program is initialized, Console.setout (debugout)

2, to achieve their own debugout, write the contents of the output to the Debugger.Log method

     Public class DebugOut:System.IO.TextWriter    {        publicoverridevoid Write (charintint  Count)        {            varnewstring(buffer, index, count);            System.Diagnostics.Debugger.Log (0null, message);        }    }

Debugout

Using this method, I can do a program, when the console service, the output to control, when running as a service process, debugging information can be received by the collection tool, and our code is still called Console.writexxx.

Remote dynamic debugging

Hope not to go to this step can solve the problem, remote debugging requirements are relatively high:

1, the remote program must bring PDB files, preferably with the native code is exactly the same;

2, vs the "remote Debugging tool" copied to the remote machine, according to the x86 or x64 system to run the corresponding debug server;

3, vs-> debugging, attach to the process, transfer to "remote (no Authentication)", "qualifier" is the IP or domain name of the remote machine;

End

These are the most commonly used debugging and tracking methods for individuals, and you can share your other good ideas.

. NET program debugging and tracing some methods