Dot NET Debugging-1

Debug is one of the most painful parts of the entire software development process. We don't want to say how difficult it is to find a small bug-you probably already know that. The number of bugs in the software grows with the complexity of the software and the bugs that are often not corrected in time. These bugs and the degree of responsibility of the software affect each other, making the project more complex. So we constantly monitor and modify bugs.

The best thing to do is to fix the bug when the unit test is done, and when the software is in trouble, the software won't tell us where the error is, why there is an error, and our task is to track the process to solve them.

In this article, we want to show you how to use the dotnet framework to debug and track the process to make it easier. We will briefly tell you how to use them effectively, and combine examples to illustrate.

Tracking

The first debugging strategy to discuss in this article is tracking. Tracking is a very powerful technique because he allows you to see the entire behavior of the application throughout the runtime, analyzing that he is most effective, although he cannot provide the information needed.

Dotnet provides trace functionality in the System.Diagnostics namespace, which is, in the correct sense, trace Class

Trace is a static class (this means that all members are static and you do not need to initialize him to obtain its functionality)

． Produce an assertion (conditional or not)

． Output trace information according to the conditions provided

． Format Trace Output Information

Let's start with a brief membership approach:

public static void Assert (BOOL)

public static void Assert (bool,string)

public static void Assert (bool,string,string)



The Assert method displays a failure message (displays information when the application fails, allows the user to break execution, ignores the error, or rerun the code that caused the error), and if the condition is false, two overloaded functions allow you to display the specified custom one or two following information. (This information is set through the string parameter, which allows the developer to display additional information about the assertion failure)

Asertion Demo

//

Purpose:to demonstrate Results of different Assert method Calls

Using System;

Using System.Diagnostics

Namespace Assertion

{

Class Application

{

[STAThread]

static void Main (string[] args)

{

Simple assertion. No Additional Message

Trace.Assert (FALSE);

}

}

}

The program will display the following message dialog box




As you can see, it's just a display of exception information. No context information is displayed, so we cannot see the cause of the failure. Below, the application calls the Assert method with one of its properties:

Asertion Demo

//

Purpose:to demonstrate Results of different Assert method Calls

Using System;

Using System.Diagnostics

Namespace Assertion

{

Class Application

{

[STAThread]

static void Main (string[] args)

{

Simple assertion. No Additional Message

Trace.Assert (False, "simple assertion message");

}

}

}

This program displays a dialog box with more information. You can see the information we can provide about the cause of the failure.


Call the Assert method with two information to form a more detailed assertion:

Asertion Demo

//

Purpose:to demonstrate Results of different Assert method Calls

Using System;

Using System.Diagnostics

Namespace Assertion

{

Class Application

{

[STAThread]

static void Main (string[] args)

{

Simple assertion. No Additional Message

Trace.Assert (False, "simple assertion message", "This message just a example." In real application your can provite detailed information here ');

}

}

}

You now see more detailed information:


In fact, this approach is used when checking for important conditions, such as data correctness. Below is his most common example: public void Storeobject (PersistentObject obj)

{

Trace.Assert (obj!= null, "Cannot store null object");

}

This method checks that object objects are stored when they are not null. When a program fails, it is the best time to produce an exception, but this is not a requirement. For example, if this method holds some important program data, the assertion is the perfect choice.

Note: Debugging traces are useful if the final release contains assertion information that is intolerable to the user. The following tips can help you control the tracking switch.



If you compile the project manually (such as command line compilation), the tracking information is displayed by default. If you use tracing in C #, when you compile the code, add the/D:TRACE flag to compile the command line, or you can simply add #define trace to the top of the file.

For example, the following applet:

using System;

Using System.Diagnostics;

Namespace Traceshow

{

Class Calss1

{

<summary>

The main entry point for the application

</summary>

[STAThread]

static void Main (string[] args)

{

TRACE.LISTENERS.ADD (New Textwritertracelister (console.out));

Trace.Write ("Hey,this is a trace message\n", "simple Message");

}

}

}

If you compile at the command line, you will not see any information unless you add/d:trace or add #define trace to the top of the file.

When you compile a program in Visual C # This situation will change, and the default is available in Visual C #, and the conclusion is that you will see trace information. Turn off debugging and browse engineering properties (You can view->property the menu item in the solution browser). In this property Page dialog box, find the conditional compilation constants (this option is locked in the build pane in the Configuration Properties folder), and remove the trace option:


public static void Fail (String)

public static void Fail (string, String)

The Fail method produces an unconditional assertion. Some of its behavior is a bit like an Assert method, but he doesn't need any processing conditions.

Failure conditions with simple conditions cannot be selected then use this method. The example below is the handling of this exception:

Try

{

throw new Exception ("Sample Exception");

}

catch (Exception Ex)

{

Trace.fail ("Exception caught", ex.message);

}



Pubic static void Write (object)

public static void Write (String)

public static void Write (object, String)

public static void Write (string,string)



The Trace class can write trace information without producing any conditions. such as information output to the device that is the recipient of the tracking information. Executes the output using the Write method.

The Write method can create a description of the object or string. In the previous case, object. ToString is called to execute. There are three other ways to perform similar behaviors: WriteLine output lines, writeif-condition information, WriteLineIf output one line of condition information.

The second parameter of the Write method specifies the category (such as a string) before which the information will be written.

The output is registered as a listener. Listeners are objects that can output trace information to some devices. Note that the Assert and fail methods often output error messages to the form or console, regardless of which listener is selected. Such objects must inherit the TraceListener class, and he has the following important methods:

public virtual void Fail (String)

public virtual void Fail (string,string)



public virtual void Flush (String)



public virtual void Write (object)

public abstract void Write (String)

public virtual void Write (object,string)

public virtual void Write (string,string)



public virtual void WriteLine (object)

Public Virtual void WriteLine (String)

public virtual void WriteLine (object,string)

public virtual void WriteLine (string,string)