The Fail method does not prevent the application from running, they simply output the error message. The Write and WriteLine methods write a message. They differ only in that the latter output is executed and then output one line. Finally, the Flush method refreshes the cache. The flush method is useful for devices that track information output (for example, streams). You can use automatic refresh-each message is automatically refreshed after the listener. You can configure it in the configuration file:
<configuration>
<stream.diagnostics>
<trace AutoFlush = "false"/>
</stream.diagnostics>
</configuration>
As you can see, if you create your own listener, you need to implement at least the write (string) and WriteLine (string) methods (these methods are abstract methods).
Microsoft offers three kinds of tracking listeners: Defaulttracelistener,eventlogtracelistener and Textwritetracelister. The first listener has the default method (if the application runs in the command line environment, the output information to the console.) If the application is in debug mode, output to the window. The second listener outputs information to the specified event log (based on NT technology-WINNT,2K,XP or. net). The third listener outputs the text into the stream.
The list of active listeners can be set up in programming or in a configuration file. The default includes DefaultTraceListener.
Programmatically change the list of active listeners to manage the listener collection (by adding and removing methods). To manage listeners in a configuration file, you use the following syntax:
<configuration>
<system.diagnostics>
<trace autoflust= "false" Indentsize = 4>
<listeners>
<add name= "MyListener" type= "System.Dianostics.TextWriterTraceListener, System"
initializedata = "C:\MyListener.log"/>
<remove type = "System.diagnostics.defaulttracelistener,system"/>
</listeners>
</trace>
</system.dianostics>
</configuration>
The Initializedat parameter is a string parameter passed to the constructor (specifies the EventLogTraceListener Listener event log).
Listeners are familiar with creating applications use listener output tracking information. The code is simple:
Trace Listeners Demo
//
Purpose:to demonstrate how to use listeners
Using System;
Using System.Diagnostics;
Namespace Assertion
{
Class Application
{
[STAThread]
static void Main (string[] args)
{
Trace.WriteLine ("Calling WriteLine method", "Trace Listeners demo");
Trace.flush ();
}
}
}
This code is not enough, we have to create a configuration file to set up the listener:
<configuration>
<system.diagnostics>
<trace autoflush= "false" indentsize= "4" >
<listeners>
<remove type= "System.Diagnostics.DefaultTraceListener"/>
<add name= "MyListener" type= "System.Diagnostics.TextWriterTraceListener"
Initializedata= "MyListener.log"/>
<add name= "Mylistenereventlog" type= "System.Diagnostics.EventLogTraceListener"
Initializedata= "Application"/>
</listeners>
</trace>
</system.diagnostics>
</configuration>
This profile deletes the default listener add two custom listeners: the first output information to a text file, and the second output to the event log. For the first listener Initializedata property to specify the output data file, the second listener logs the event to the event log.
Run the program. Check the first listener and you can see the MyListener.log file, which contains the following information: Tracing listeners demo:calling WriteLine method
The first listener writes information to a text file. Look at the second one. Open the Microsoft Console to browse the application event log in the event view (this is what we specified in the configuration file). Here you can see the event information for our application. More likely, at the top of this list. If you double-click, you can see the contents. We found the following information:
Is that the output information is easier to read:
Sometimes the application is complex, and the tracking information can be formatted for easy understanding. Make the output more beautiful, you can use indentation to see the following simple code:
public void callee ()
{
Trace.wrteline ("callee started");
...//some internal logic
Trace.WriteLine ("Initializing Buffer");
...//some extra Internal login
Trace.WriteLine ("Exiting Callee");
}
public void Caller ()
{
Trace.Write ("Caller called");
...//some external logic
Callee ();
...//some extral Logic
Trace.WriteLine ("Initializing Buffer");
Trace.Write ("Exiting Caller");
}
The output information is as follows:
Caller called
Callee stared
Initializing buffer
Exiting Callee
Initializing buffer
Exiting Caller
If the method does not display information before and after execution, we will be puzzled by the initialization cache information for these copies. Except the information is not clearly displayed. To avoid being ambiguous, we use the indentation functionality supported by the Trace class. Modified code, using indents:
public void callee ()
{
Trace.indent ();
Trace.WriteLine ("callee started");
...//some internal logic
Trace.WriteLine ("Initializing Buffer");
....//some Extra internal logic
Trace.WriteLine ("Exiting Callee");
Trace.unindent ();
}
public void Caller ()
{
Trace.Write ("Caller called");
....//some External Logic
Callee ();
....//some Extra Login
Trace.WriteLine ("initiallizing buffer");
Trace.Write ("Exiting Caller");
}
The output information is as follows:
Caller called
Callee started
Initializing buffer
Exiting Callee
Initializing buffer
Exiting Caller
As you can see, the callee method outputs indents, and it's easy to separate information from different methods. The indent and Unident methods can be invoked to achieve the purpose of separating information.
To modify the trace configuration in the configuration file:
<configuration>
<system.diagnostics>
<trace indentsize = "3"/>
</system.diagnostics>
</configuration>
