Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

The NT event log was designed to solve many problems, and although I feel that the Win32 API is a little arcane, I think the event log does its job admirably. The messages in the event log can be exported to a file and read on another machine, or if a remote user has sufficient privileges, the messages can be read over the network. This presents two issues: First, the messages must be stored in a compact way so that they take little bandwidth when read across the network; second, the locale of the machine where the messages are read may be different to the locale of the machine when the event was generated, so there must be some mechanism to allow the user to see the messages formatted in his own language.

The event log addresses these two problems with a single solution, each process that can generate event log messages has "templates" for each of those messages, the template (called a "format string") has placeholders for data that will vary between instances of the same event, and each format string has an identifier number. For example, a message like ‘Disk C is full’ would have the format string "Disk %1 is full" with %1 as the placeholder to be replaced with the name of the disk, in this case C. This solves the space problem because only the format string identifier and the data for the placeholders will be stored in the event log. A process that reads the event must have a resource file that contains the message format strings. Win32 has a function called ::FormatMessage() that will return a complete message based on the format string with the placeholders replaced with the message data. The nice part of this process is that the resource file can have message format strings for several locales, and ::FormatMessage() will use the format string for the locale of the thread that called the function. This means that the responsibility of localizing a message is placed upon the code that reads the message (which knows what locale to use) and not on the code that generates the message.

As I’ve said, the Win32 API is rather arcane, particularly the API for reading messages. It was a relief to see that the .NET framework had provided a class called EventLog in the System::Diagnostics namespace that makes reading events as simple as iterating through a collection. However, the EventLog class makes a very poor attempt at reporting events. The designers of this class clearly felt that it was too much effort to generate resource files with the message format strings and instead produced a single file called EventLogMessages.dll for all processes that use EventLog. This is a one-size-fits-all file that has 65,535 format strings that look like this:

%1

In other words, the data you provide when you report an event is the entire message, which means that the code that generates the message has the responsibility of formatting the message in an appropriate locale. This has the problem that the event log will get bloated if the messages are detailed, and since the event log service can be configured to trim the size of the event log files when they grow too large, this can mean that event messages could be lost. Furthermore, reading such events over the network uses up more bandwidth, which in the long run can mean higher infrastructure costs. The most serious problem, in my opinion, is that the developer of the process that generates the event has to guess the locale of the reader of the event message. Since this is difficult, and often impossible, to do, it results in developers taking a "locale neutral" approach, which means formatting the messages in the so-called International English. In a multicultural, multinational world, this will be interpreted as arrogant cultural imperialism, and yet as a developer, you have no choice.

The other downside of the EventLog class working in the way that it does is that it removes the facility of having categories with meaningful names. When you report an event you can pass a category ID, which is stored along with the message in the event log file. The category ID is actually the index of a format string, but since the EventLog class uses a single generic resource file, there is no space for the category descriptive string. As a consequence, when you read a message you’ll get the category number displayed if the category is greater than 6, and if the category is between 0 and 6 the event log viewer will give the name for the default categories defined in eventlog.dll.

These problems are not new to .NET, indeed, the object in VB6 to read and write the event log behaved in the same way, and this makes me wonder whether the EventLog class is a port of the VB6 code.

My advice is to use the EventLog class only to read events—if you want to write events you should call the Win32 API through platform invoke and provide an event format string resource file. This has two benefits: First, you use the event log correctly with localized format strings, and second, because it is more effort to use the event log, you will be forced to review whether you should be using it. The event log should be used for "eventful" messages for diagnostics purposes, it should not be used for trace messages.

Richard Grimes speaks at conferences and writes extensively on .NET, COM, and COM+. He is the author of Developing Applications with Visual Studio .NET (Addison-Wesley, 2002). If you have comments about this topic, Richard can be reached at dotnet.dev@grimes.demon.co.uk. For questions regarding your newsletter subscription, please contact wdletter@cmp.com. To subscribe, visit http://www.windevnet.com/newsletters/.

RELATED ARTICLES Code Signing in Adobe AIR		TOP 5 ARTICLES No Top Articles.