As well as the Trace class, the Framework gives you the Debug class. The two classes are identical in their methods and properties, so why do both need to exist? The answer lies in the flexibility that they give you to control your application's tracing behavior. Because a different conditional compilation flag controls the Debug class, you can use the Debug class for tracing during development and unit testing, and you can use the Trace class for tracing during system testing and production. This is all done automatically when you create the normal debug and release builds, without your ever having to change your tracing code. Any tracing code using the Debug class simply disappears from any release build.
This inclusion or exclusion of tracing code is controlled with a conditional compilation flag called DEBUG . When this flag is set to true , any Debug class method is compiled as normal; when it is set to false , any Debug class method is removed from your application. Just like the Trace class, this flag can be set in one of three ways:
From the command line : Use /d:DEBUG=True or /d:DEBUG=False when compiling your application from the command line.
In Visual Studio : In the Project properties ’ Configuration properties ’ Build window, select or deselect the "Define DEBUG constant" check box when compiling your application from VS .NET.
In code : Within your code, define the TRACE constant using the syntax #Const DEBUG = True or #Const DEBUG = False .
By default, the DEBUG flag is set to true in all debug builds and false in all release builds. This is sensible because you normally don't want debug code to operate after release ”that's what the Trace class is for.
You can also remove any diagnostic checks that you don't require when debug is deactivated; this can be useful for improving performance. To do this, you should use the #If #End If directive with the TRACE constant, as shown in Listing 6-23. If debug is not active, none of the diagnostic code will be compiled into your program.
#If DEBUG Then 'Some expensive diagnostic code goes here #End If
Some developers like to separate their use of the Debug and Trace classes. In other words, they try not to use the same method in both classes within the same application. If, for instance, they use Debug.Assert , they won't use Trace.Assert . I can see the point behind this ”it avoids having to think about which class to use for any specific method. However, I prefer to divide my usage of the two classes simply based on whether I want a trace message reported in production. If I want a message reported only during development and unit testing, I use the Debug class; otherwise , I use the Trace class.