Enable debugging and tracing of applications

Debugging is essential and useful for every software development process and software application. Diagnosing a software application and locating and fixing bugs and problems is even more complex when in a production environment where the application project is directly deployed in release mode. In addition to debugging, you need to use instrumentation practices to ensure the expected performance of your application. Instrumentation is basically monitoring and measuring performance, diagnosing errors, and writing trace information both in development and production environments.

In this article, you will learn how to enable instrumentation for your application - both debugging and tracing.

Debug and Trace classes

The Debug and Trace classes are part of the System.Diagnostics namespace in .NET framework.

For more information see:

Following is a sample code that demonstrates how to indicate that your application has initiated and is monitored using the Debug and Trace classes:

The code above demonstrates the debug information by the Output window in Visual Studio in development environment. However, you cannot view tracing information when your project is in development mode.

To view tracing information using one of these methods in production environment:

  • Web browser for ASP.NET or Windows GUI for desktop applications
  • Event viewer
  • Trace viewer (using the Trace.axd handler in ASP.NET)

Use trace listeners

If you use the trace viewer to view trace information, keep in mind that this information is stored in the browser engine temporarily. You need to save the error details, so that later you can see the error history for proper diagnosis. To achieve that, you use trace listeners.

There are various types of listeners that you can use – text file listener, event viewer, and others. In Sitefinity CMS, you can create custom trace listeners. For a detailed tutorial, see Create and enable a custom trace listener.

In general, however, there is too much noise and you hardly filter to use the information that you actually need. If you want to filter the ASP.NET events and eliminate the events and messages that are not of interest to you, you must add a trace source. You write the messages that are important for your log on the trace source and the source redirects the messages to the trace listeners. The following code demonstrates how to send messages to the trace source:

NOTE: You need to import the System.Diagnostics namespace.

The trace source controls by switches the messages, emitted by ASP.NET, and sends them to various sources, such as files, the event viewer, XML files, and so on.

Use Activity ID to group error in a request

You can use the ActivityId property to group by correlation the errors, thrown during the execution of one and the same request. Since correlation ActivityId is set per request, all errors thrown during one request are with the same ActivityId.

Following are a few examples when you can use grouping of errors in a request: 

  • Executing the scheduled and background tasks
  • Synchronizing operations
  • During the request execution when expected errors are identified and logged.
    In this case, there will be more than one error with the same ActivityId.


Sitefinity CMS uses the Microsoft Enterprise Library to enable instrumentation for applications. In addition, you can enable the Error Logging Modules and Handlers (ELMAH) plug-in to benefit from the complex functionality and features of the Enterprise Library and use the ELMAH user interface.

For more information, see:

Want to learn more?

Sign up for our free beginner training. Boost your credentials through advanced courses and certification.
Register for Sitefinity training and certification.

Was this article helpful?

Next article

Audit trail module