EurekaLog for VisualStudio

Abstract

This article provides a quick overview of a “on-site” bug tracking solution. An application add-in, if you will, which catches, logs and reports uncaught exceptions.

The Scenario

After months of sleepless nights spent in front of the PC monitors trying to implement on time every single feature the marketing team promised, the countless remarks from the QA team and the reports of weird behavior by the beta testers, the product is finally finished, polished, packed in a pretty box and decorates the store shelves. In the meantime, you and your team celebrate release 1.0 of the latest hottest software. There’s just the users test to be passed and the job’s done perfectly… at least, until requirements for release 2.0 arrive. Well, not quite. Sub releases exist for a reason…

The Problem

Always, and I do mean always, there are unforeseen situations, unexpected user behaviors and uncaught bugs. Meaning, sooner or later a bug will surface. When this happens the user can be helpful and provide some information about what really happened, or (in most cases) will ignore the problem, restart and go on with the daily duties. Unfortunately, sometimes, even the users who want to help can’t really explain what’s going on and you really need a bit more technical information instead of just “I clicked this, then pressed on that and a message saying…”. So, there must be a better way of getting the information you need about the circumstances under which the application crashed, right? After all, it may be a simple error, or maybe a separate process is interfering, maybe it’s a hardware issue, maybe it’s the OS. Who knows? The user couldn’t possibly point out any of these as the problem.

The Solution

There is a simple, yet effective solution. It’s called EurekaLog (www.eurekalog.com). What does it do? Actually, primarily, more important is what it doesn’t do. After all, you don’t want anything messing with your code’s performance or, God forbid, behavior, right? Well, EurekaLog doesn’t decrease performance, doesn’t let an exception go uncaught (and unreported, should you chose so) and doesn’t require you to quit your day job to learn how to use it.

Back to the first question, what does it do?

When the application throws an exception which isn’t handled, it usually is left to the operating system to deal with it, which isn’t the most graceful thing you want the user to see, and it always terminates the application. EurekaLog doesn’t allow an exception to go that deep. It intercepts every unhanded exception (unless you set up events filter) displays a dialog with the information you want, and (if set to) sends a bug report to an e-mail, a web bug tracker, or just saves the

log file.

Getting Started

The usual steps… download, install, configure, catch bugs. There are two main versions available. The first targets Borland’s Delphi and C++ Builder, and the other targets Microsoft’s Visual Studio. My weapon (uhm… IDE) of choice, Visual Studio.

After installation, first step, of course, I create my project. It doesn’t matter what kind of project, EurekaLog supports them all: Console, WinForms, WebForms, WPF, and as of late Device projects (using .NET Compact Framework), too. What’s even better, it doesn’t have to be a new project. EurekaLog easily integrates into an existing project.

Next step, activate EurekaLog for the new project.

Now would be the right time to notice the new “EurekaLog” menu on the menu bar. Selecting the first item makes defining the behavior when an exception is thrown wizardly easy. After tweaking the behaviors the desired way, a simple recompile of the project, and that’s it! Automatic bug reporting in a few minutes.

Tweaking It

I mentioned tweaking the behavior when an exception is thrown. The settings are divided into six categories:

Email & Web send One of the greatest features EurekaLog has is the Email & Web send feature. You can set up the program to automatically send an email to a number of e-mail addresses, or send a web report to a bug tracker (BugZilla, Mantis, FogBugz, or set up a custom one).
Send Options This category lets you select what exactly is sent with the bug report. You can set whether the send and success dialog should be displayed, the format of the log file, configure the screen shot, set additional files to be attached and a password for the archive, and similar settings.
Log File Of course, no bug tracker/handler can’t call itself such if no log is produced. This tab lets you define what exactly you want logged. First of all, the location of the log file can be set, if you don’t want the default to be used. After that, the number of logs, whether duplicate errors should be logged, should a “steps to reproduce” text be added to the log, and are modules, processes assembles and CPU information to be logged.
Exceptions Dialog We already agreed that we don’t like the standard exception dialog, nor the server error page. So, here’s where the looks of the exception dialog (or page, in case of a web application) is defined. For desktop applications, three types of dialogs are predefined. A simple message box, a classical MS dialog, or a powerful EurekaLog dialog. Or, if you don’t like any of those, turn the exception dialog off completely. For web applications, it would be illogical to use any of these. Instead, a exception page is generated, the looks of which you have complete control through the HTML Layout section of this tab.
Message Texts Nowadays, internationalization is very important if you want the latest hottest software we discussed to succeed outside the US & UK borders. For the non English speaking users, there’s the Message Texts tab which lets you translate every single message displayed by EurekaLog. Utile, giusto?
Exception Filters Of course, there are some exception types that you don’t want reported. Or, some that you want slightly different behavior (different dialog shown, the application to be restarted afterwards, etc). Easily achieved. All this can be set up in a few steps. EurekaLog’s Exception Filters tab lets you specify exception classes you want special behavior for, and the behavior you want. Simple as that .

In the event of…

So, EurekaLog has got it all covered, right? Well… maybe, maybe not. No one can ever predict everything an application might need. So, the guys at EurekaLabs were clever enough to provide a

component with few events defined. The  events are spread across the exception reporting process, and practically cover every main checkpoint of the process.

• ExceptionNotify is raised when EurekaLog traps an exception.

• ExceptionActionNotify is raised before and after the man checkpoints. A parameter is passed which defines at which point of execution the process is. This event’s raised: before and after the exception information has been shown, before and after the log file has been saved, before and after an e-mail has been sent, before and after a web message has been sent and before the application is terminated.

• ExceptionErrorNotify is raised when an error occurs while EurekaLog handles an exception. It can be raised if saving the log file, or sending the e-mail, or sending the web message fails. Once again, a parameter is passed which defines which of these actions failed.

• AttachedFilesReques is raised when EurekaLog is set to attach additional (besides the log file) files when sending e-mail or a web message.

• CustomDataRequest is raised on handling an exception, and allows the user to add additional data to the log file.

• CustomWebFieldsRequest is used when sending a web message to a custom system. Here, the custom HTTP fields that are to be filled are set up.

• CustomButtonClickNotify is raised when the user clicks on a customizable button that can be set up to appear on the EurekaLog dialog.

Conclusion

There are two main reasons why this tool deserves a try… First, you’ll get reliable data that you can actually use when fixing bugs. Second, you’ll keep your software’s reputation by making sure it never disappears from the user’s display in a crash, leaving the user wondering what happened.