You must define the DEBUG and TRACE compiler directives to activate debugging and tracing respectively. If you neglect to define either of these directives, Trace or Debug calls will be ignored during compilation. You can define these in Visual Studio .NET by choosing Properties from the Project menu.
It is generally recommended that you define TRACE in your code, since at a minimum, end users and administrators may turn on lightweight diagnostic tracing out in the field when they encounter a problem related to the application. Microsoft tends to deliver both versions of its applications, release and checked (or the debug) build. The checked build versions of commercial applications are larger in size and slower in performance than the release build versions, because they perform verbose and extensive logging to the computer disk to help you find the culprits or bugs in support issues. Both the Debug and Trace classes contain the exact same methods. But unlike Debug, Trace is meant for monitoring the application's well-being in the field. Even if you debugged things in your testing phase, you may find it difficult to find some of the fuzzy problems, particularly in distributed n-tier environments. For example, some types of problems arise only when the application is under an intense load, or the problems may occur randomly or intermittently. Tracing may prove more useful in finding these problems.
Although Debug and Trace have identical members, you should use Debug during development and Trace for diagnosing an application after deployment. The output methods of the Trace and Debug classes are Write(), WriteIf(), WriteLine(), and WriteLineIf().