Effective C # principle 36: Use. NET Run time diagnostics

When problems occur, they often do not occur at the time of the experiment, and the machine has tools for easy debugging. In many cases, problems that you can't fix are always on the user's machine, where there is no debugging environment, and there is no good way to figure out the problem. In practice, experienced developers create a way for the system to capture as much information as possible at run time. NET Framework already contains a collection of classes, and you can do some common debugging with these collections. And these classes can be configured at run time or at compile time. If you take advantage of them, you can easily find problems in the actual runtime. Using the code that already exists in the frame, you can send a diagnostic message to a file, or to a debug terminal. In addition, you can specify a specific debug output level for your product. You should use these features in your development environment as soon as possible to ensure that you can use the output information to correct some of the problems that are not anticipated in the actual operation. Don't write your own diagnostics library unless you understand what the framework has already provided.

System.Diagnostics.Debug, System.Diagnostics.Trace, and System.Diagnostics.EventLog classes provide all the tools you need to create diagnostic information when you run the program. The first two classes of functionality are basically the same. The difference is that the trace class is controlled by the preprocessor trace, and the Debug class is controlled by the debug preprocessor. When you develop a project with vs.net, the trace symbol is defined in both the Debug and Release editions. You can use the Trace class for all distributions to create diagnostic information. The EventLog class provides a portal through which your program can write some system logs. The EventLog class does not support Run-time configuration, but you can encapsulate it in a unified, simple interface.

You can control the diagnostics output at run time. NET Framework uses an application configuration file to control a variety of run-time settings. This is an XML file that is in the directory when the main application is running. This file has the same name as the application, but adds a. config suffix. Service blocks such as MyApplication.exe may have a MyApplication.exe.config XML file to control it. All of the configuration information is contained in a configuration node:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
</configuration>

. NET Framework uses predefined keywords to control the behavior of some classes in the framework. In addition, you can define your own configuration keywords and values.

You can combine the output switch and the Trace.WriteLineIf () method to control the output of the application. You can turn off this output in the default way outside your application so that your application gets the best performance. When a problem is found, you can open the output to diagnose and correct the problems encountered in practice. WriteLineIf () is output only if the expression is true:

bool _printDiagnostics = true;
Trace.WriteLineIf( _printDiagnostics,
　"Printing Diagnostics Today", "MySubSystem" );

The output switch you create is used to control the level of output, one output switch can be a variable defined by the application configuration file, and can be one of five states: off, error (Error), Warning (Warning), info (info), and verbose (Verbose). These states are part of the environment, and their values can be from 0 to 4. This way you can create a control for all subsystem information. Define an output switch class and then initialize it to create a switch:

static private TraceSwitch librarySwitch = new
　TraceSwitch( "MyAssembly",
　"The switch for this assembly" );

The first parameter is the name of the switch display, and the second parameter is the description. This allows you to configure their values in the application configuration file at run time. Next, set the Libraryswitch to info:

<system.diagnostics>
　<switches>
　　<add name="MyAssembly" value="3" />
　</switches>
</system.diagnostics>

If you edit the value of the switch in this configuration file, all output statements that are controlled by that switch are modified.

Another task: You need to configure where your output goes. The default is a listener linked to the Trace class: a DefaultTraceListener object. DefaultTraceListener sends information to the debugger, and when its failure method (called when the assertion fails) prints some diagnostic information and then terminates the program. In a product publishing environment, you cannot see such information. But you are configuring different listening objects to the product release environment: that is, adding listeners to the application's configuration file. The following adds a textwritertracelistener to the application:

<system.diagnostics>
　<trace autoflush="true" indentsize="0">
　　 <listeners>
　　　<add name="MyListener"
　　　　type="System.Diagnostics.TextWriterTraceListener"
　　　　initializeData="MyListener.log"/>
　　 </listeners>
　</trace>
</system.diagnostics>