Objective C # use. Net runtime properly for Diagnosis

When a problem occurs, they often do not occur during the experiment, and the machine has a tool for easy debugging. In many cases, problems that you cannot correct always occur on your machine, where there is no debugging environment and there is no good way to calculate problems. In practice, experienced developers will create a method for the system to capture as much information as possible during runtime .. The. NET Framework already contains some class sets. With these sets, you can perform some common debugging. In addition, these classes can be configured at runtime or during compilation. If you use them, you can easily find problems during actual operation. Use the existingCodeYou can send a Diagnostic message to a file or to a debugging terminal. In addition, you can specify a special debugging 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 unexpected issues during actual operation. Do not write the diagnostic database on your own unless you understand what the framework already provides.

The system. Diagnostics. debug, system. Diagnostics. Trace and system. Diagnostics. EventLog classes provideProgramAll tools to create diagnostic information. The functions of the first two classes are basically the same. Apart from the differences, the trace class is controlled by the preprocessing operator trace, while the debug class is controlled by the debug preprocessing operator. When you develop a project using vs.net, the trace symbol is defined in both the debug and publish versions. You can use the trace class to create diagnostic information for all releases. The EventLog class provides an entry through which your program can write some system logs. The EventLog class does not support runtime configuration, but you can encapsulate it into a unified simple interface.

You can control the diagnostic output at runtime, And the. NET Framework uses an application configuration file to control various runtime settings. This is an XML file in the directory when the main application is running. This file has the same name as the application, but adds a. config suffix. For example, myapplication.exe can have an XML file of myapplication.exe. config to control it. All configuration information is contained in a configuration node:

 

<? XML version = " 1.0 " Encoding = " UTF-8 "   ?>
< Configuration >

</ Configuration >

 

The. 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 disable this output by default outside the application so that the application can achieve the best performance. When a problem is detected, you can enable this output to diagnose and correct the problem encountered in practice. Writelineif () is output only when the expression is true:

 

Bool _ Printdiagnostics =   True ;
Trace. writelineif (_ printdiagnostics,
" Printing diagnostics today " , " Mysubsystem " );

 

The output switch you created is used to control the output level. An output switch can be a variable defined by the application configuration file and can be in one of the five states: off ), error, warning, info, and verbose ). These statuses are a part of the environment, and their values can be from 0 to 4. In this way, you may create a control for all Subsystem information. Define an output switch class and initialize it to create a switch:

 

Static   Private Traceswitch libraryswitch =   New
Traceswitch ( " Myassembly " ,
" The switch for this Assembly " );

 

The first parameter is the name displayed by the switch, and the second parameter is the description. In this way, you can configure their values in the application configuration file at runtime. Set libraryswitch to Info:

 

< System. Diagnostics >
< Switches >
< Add name = " Myassembly " Value = " 3 "   />
</ Switches >
</ System. Diagnostics >

 

If you have edited the switch value in this configuration file, you have modified all the output statements controlled by that switch.

Another task: You need to configure where your output goes. By default, it is a listener linked to the trace class: A defaulttracelistener object. Defaulttracelistener sends information to the debugger, and some diagnostic information is printed and then terminated in its failure method (called when an assertion fails. In the product release environment, you cannot see such information. However, you can configure different listening objects to the product release environment: Add listeners to the application 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 >

 

Textwritertracelistener prints all diagnostic information to a mylistener. log file. The name attribute specifies the name of the listener, and the type specifies the type of the listener object. It must be derived from system. Diagnostics. tracelistener. Only in rare cases do you create your own listener class, that is, you think the listener class of the. NET Framework is not enough. The value of initializedata is a string used to pass to the object constructor. Textwritertracelisteners uses it for file names.

You can make a small extension so that it can be easily used in every deployed assembly in the application. For each assembly, add a class to track the diagnosis created by the Assembly:

 

Internal   Class Myassemblydiagnostics
{
Static   Private Traceswitch myassemblyswitch =
New Traceswitch ( " Myassembly " ,
" The switch for this Assembly " );

Internal   Static   Void MSG (tracelevel l, Object O)
{
Trace. writelineif (myassemblyswitch. Level> =L,
O,"Myassembly");
}

Internal   Static   Void MSG (tracelevel l, String S)
{
Trace. writelineif (myassemblyswitch. Level> =L,
S,"Myassembly");
}

// Add additional output methods to suit.
}

 

The myassemblydiagnostices class creates diagnostic information for this Assembly based on a switch. To create information, call any of the MSG that is reloaded by the general call:

 

Public   Void Method1 ()
{
Myassemblydiagnostics. MSG (tracelevel. info,
" Entering method1. " );

Bool Rval = Domorework ();

If (Rval =   False )
{
Myassemblydiagnostics. MSG (tracelevel. Warning,
"Domorework failed in Method1");
}

Myassemblydiagnostics. MSG (tracelevel. info,
" Exiting method1. " );
}

 

With a global switch, you can also component A Special Assembly switch to control the output of the entire application:

 

Internal   Static   Void MSG (tracelevel l, Object O)
{
Trace. writelineif (libraryswitch. Level> =L|
Globalswitch. Level> =L,
O,"Mylibrary");
}

Internal   Static   Void MSG (tracelevel l, String S)
{
Trace. writelineif (libraryswitch. Level> =L|
Globalswitch. Level> =L,
S,"Mylibrary");
}

 

In this way, you can diagnose information on the application and control the output of individual library files more effectively. Anywhere in an application, you can set application-level diagnostics to error-level to discover errors. When you have an independent problem, you can improve the output level of the database to precisely identify the source of the problem.

The diagnostic library is necessary to diagnose and maintain distributed programs. It is best not to write your own diagnostic Database:. Net FCL already has the core features we need. You should make the best use of your resources and then expand it for your own purposes. This will capture all problems, even in the product environment.