The .NET Framework includes a wide variety of options for diagnosing different aspects of a running application. You can use diagnostics for many functions including auditing, logging, profiling, and debugging. You can use them to identify performance problems, resource usage, and security issues. Like many other management tasks, diagnostic work requires full cooperation between developers and the system management staff. This section will cover the diagnostics management and give you tips on what the development side of the house should do to keep their end of the bargain.
The debug and trace features allow an application to emit simple diagnostic information without interfering with the user interface. Developers can include statements within the application code to write information and failures to virtually any source, including the Windows Event Log.
Although the debug and trace features are exactly the same internally, they have different intended uses:
Debug is used during the development and testing stages of an application. Debug statements are usually stripped out by the compiler in release builds of assemblies.
Trace is used during the full life cycle of development, including
production. Compilers typically leave
statements in release builds.
If you’re not a code monkey, you can safely skip the remainder of this section and move on to the next. I’ll simply provide more detail for those interested in .NET Framework debugging ...