Diagnostic Logging and Tracing

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

On this page:
Diagnostic Logging and Tracing with Enterprise Library | The Need for Diagnostic Logging and Tracing - Detecting (Unknown) Errors, Analyzing Problems, Analyze Usage Patterns | Diagnostic Considerations in a Silverlight Application - No Access to Regular File System or Windows Event Log, Not All Diagnostic Information Is Available in Silverlight, Web Service Calls Are Asynchronous

The ability to analyze and diagnose an application while it is running is very important for maintainability. An application that doesn't provide good diagnostic information at run time often makes it very difficult to detect and solve problems. In an enterprise, it's not uncommon to have a huge ecosystem of hundreds of applications that should be monitored and maintained. That is why it is very important for an enterprise to have a consistent and reliable way to monitor the health of applications and to diagnose problems.

In this chapter, we'll discuss how to implement diagnostic logging and tracing in a Microsoft® Silverlight® application using the Logging Application Block from the Enterprise Library 5.0 Silverlight Integration Pack. We’ll also describe the new trace listeners, which have been added to the Enterprise Library 5.0 Silverlight Integration Pack and discuss how diagnostic logging and tracing has been applied in the Stock Trader V2 Reference Implementation. At the end of this chapter, we’ll show some examples.

Diagnostic Logging and Tracing with Enterprise Library

Enterprise Library provides a consistent API for writing log messages. The following example shows how you can create a log entry using one of the many overloads for the LogWriter class:

logWriter.Write("Loading accountholder complete", "AccountHolder", 0, 0, 
    TraceEventType.Information);

The log entry produced by this statement contains information, such as the category or trace event type, that can be used to route the log entry to various trace listeners. Where and how you’d like to route your log entries can be defined in configuration using the configuration console. This screenshot shows an example of how log entries in the categories General, Exceptions and Validation are all written to the Isolated Storage Trace Listener, which creates a log file in isolated storage.

The Need for Diagnostic Logging and Tracing

While diagnostic logging and tracing are non-functional requirements for an application because the business or end-users rarely ask for this functionality, many organizations consider these requirements critical and plan them accordingly during the development cycle.

Mark Says:

I like to get involved early when a new software development project starts. For me to be able to install and maintain applications, it's vital that those applications produce the right diagnostic information in a uniform way. Applications that log too little information, too much information, or log in a non-standard way make my life much more difficult. When I get involved in the development process, I can help to define stories and requirements for diagnostics. This helps to ensure that diagnostic logging and tracing is implemented as a first-class requirement, rather than an afterthought.

There are several reasons why you might like to implement diagnostic logging and tracing.

Detecting (Unknown) Errors

Even the most rigorous testing process cannot prevent an application from having defects when it ships. If you are lucky, your users will eventually tell you that your application has a problem. However, some users who run into problems will just abandon the application, or refuse to use it. You can use diagnostic logging and tracing to detect that your application has problems and solve them before your users start complaining.

In web applications it's very common that the web server logs any problems that happen on the web server itself. However, problems that occur on the client, for example in JavaScript, are usually ignored, resulting in a negative user experience.

While Silverlight applications usually run in the browser, they provide a much richer user experience and excellent support for handling exceptions.

Analyzing Problems

To solve a problem, you'll need to analyze and reproduce it. For straightforward bugs, this can be relatively easy. But there are also some problems that only occur in production with a particular user. When you have applied logging and tracing diligently in your application, you can get much more information about a particular problem, which will help you identify it.

Analyze Usage Patterns

Nowadays, many applications ask their users if it is ok to send anonymous information about the usage of the application.

If you log which screens are being opened, how much time is spent in a particular screen, which buttons are being pressed and which error messages are displayed, you can gain insight into how your application is being used.

This information will likely impact privacy, so you should ask the user permission first and make sure you only record anonymous information.

Diagnostic Considerations in a Silverlight Application

Diagnostic logging and tracing in a Silverlight application is somewhat different than it is, for example, for a regular Microsoft Windows® application or for a web application. The process of producing diagnostic information is largely the same, but the Silverlight security sandbox limits what additional information you can gather and where you can send the information.

No Access to Regular File System or Windows Event Log

A Silverlight application that runs in the browser doesn't have access to the regular file system. This means it's more difficult to create a log text file that can easily be found and read by your users. It is possible to log to isolated storage, though isolated storage size is limited by default to 1 MB and it is located in an obscure location. This makes it more difficult for users to discover the location and consume the file.

Another commonly used approach for regular Windows applications or web applications is to write log information to the Windows Event Log. This is not possible for Silverlight applications, because the security sandbox does not allow access to the Windows Event Log.

Mark Says:

I don't really miss the ability for Silverlight applications to Log to the Windows Event Log. I want to have a centralized way to monitor the health of my applications. Since Silverlight applications can be started over the Internet and can run pretty much anywhere and on many different platforms, logging to the Windows Event Log of the user is not very practical. Logging to the Windows Event Log of the web servers—now that is very useful.

In the following chapters, we'll discuss how the Enterprise Library 5.0 Silverlight Integration Pack helps you to implement logging to isolated storage and automatically send the log information to a centralized location using a web service.

Not All Diagnostic Information Is Available in Silverlight

In Enterprise Library 5.0, when you create a new log message, it will also gather additional information about the host, such as the machine name, process name, process ID, and Win32® thread ID. The Silverlight security sandbox denies access to these properties, so this information cannot be gathered.

Mark Says:

In our centralized environment for monitoring the Stock Trader application, I really wanted the ability to know which client experienced a particular problem. When a particular user experiences problems, it is very helpful to be able to find all the log messages that originated on his machine. Since Silverlight doesn't allow you to gather this information, we decided to gather it on the server. We have extended the Logging Service to also gather the IP address of the client machine.

Web Service Calls Are Asynchronous

Another difference between Silverlight and the desktop version of the .NET Framework is the fact that all Silverlight web service calls are asynchronous. While asynchronous web service calls improve the perceived performance of an application, they make it more difficult to implement certain cross cutting concerns, such as exception handling, performance measurement, and logging.

In the following sections, we'll discuss how you can apply diagnostic logging and tracing to asynchronous web services.

Next Topic | Previous Topic | Home

Last built: July 8, 2011