Event Logging – Writing to the Event Log

First off, let me say thanks to our BSDA (http://www.bsda.info/) President, last week he gave a quick intro to event logging that inspired this piece. If you are a new developer, you may be wondering what Event Logging is.

Let’s face it, users are the worst in the world about telling you what happened.

User: “I had an error with your app.”

You: “OK, what was the error message?”

User: “I dunno, just something about an error.”

You: “Uh, did you write down the message?”

User: “No, but it looked real bad. I think you need to fix it right away. Gotta go!”

Fortunately, Windows has a built in way to track messages that your application generates, called the Event Log. In .Net 2.0 it turns out logging is very simple, just a few lines of code.

First, set a reference to the System.Diagnostics in your class, that’s where the event objects live. Now paste in a few simple lines of code:

The first line creates a new event log entry under the name ArcaneCode. You’d probably want to put the name of your application in this area. The next line creates the message to log, in a real app this would probably be passed in as a string from an error handler or tracer.

The Source property is for designating the area that had the problem. In a “real world” app I would probably put the class and method that generated the event log request here, perhaps passed into a routine as a string. For this example though it’s just hard coded.

The final line actually writes the entry, after all the setup has been done. The first parameter is obvious; it’s the message to log. The second parameter indicates the type of event this is. The EventLogEntryType enumerator has five choices; Information, Warning, and Error being the most common.

To see if this got to the log, we need to look in the Microsoft Management Console. Click Start, Run from your Start menu, then type in mmc and press enter. Once the Console opens, pick File, Add/Remove Snap-in from the menu. Down at the bottom of the screen you’ll see a button that says “Add”. Click it, then in the list that appears find one called “Event Viewer”. Pick it, click Add, then Close. Then click OK. You should see something like this:

You can see the entry for “ArcaneCode”. Click it and you’ll see all of the events generated by your program. Double click on one of the events (or right click and pick properties) will show you all of the detailed info including the date / time, and that spiffy error message you passed in.

You can see that having a place to log messages to could make application debugging much easier once your app winds up in production. It will also be handy for debugging things like web or windows services, things that lack a user interface.

Care should be taken with what you log. It’s easy to go overboard and log every little thing. In my book, you should always log any error message that the application cannot handle. Then you should move into the critical areas of your app that are “problem spots”. Finally, if the user does something that will have a major impact on your database, such as electing to delete every customer record, you’ve found a good candidate for an event to log.

Of course, putting data into the event log is one thing. You can hardly expect your user to have the ability to go into the management console every time they have an error. That’s why the .Net Framework also has a way to get the events back out of the system, and it’s just as easy as putting them in. We’ll cover that in the next post, then go on to build a nifty event logging class you can use in your own applications.