Bug Tracking

I don't know of any really good bug tracking packages for .NET. There is FogBugz (which I would like to use), but it isn't .NET based, so it is out of the picture for our projects which are generally 100% managed code.

Today, I started working on a bug tracking module for us to use in our ongoing projects. The basic idea is pretty simple, regardless of the amount of testing you do, your code will probably have a few bugs when it hits production (or, beta if you pre-release your products). You want to resolve these bugs before your customers notice them. So, how do we go about doing this?

Well, the first step is really easy, you catch all the unhandled exceptions in your app and redirect them to the bug tracking system. In an ASP.NET app, the code goes something like this:

protected void Application_Error(object sender, EventArgs e)
{
  bugTracker.SubmitBugReport(new BugReport(ex.InnerException, User.Identity.Name, Request.RawUrl));
}

One little line of code is all it takes. Behind the scenes, the bug report is checked against a list of known bugs and appropriate events are fired depending on if the bug is a new bug, an existing bug, or even if an existing bug that you thought was resolved has been reopened. This allows us to process only the bug reports we want to deal with. After all, if you are heavily using a site (especially during dev), you don't want to send out an email, or do whatever it is you do for notification, every time an already known exception gets fired, you only want to know about new bugs as well as bugs you thought you resolved that aren't actually resolved.

The system also allows swapable bug reporting components, so we can actually integrate it with a third party tool like FogBugz if we really wanted to, or send bug reports back to our servers via a webservice and provide resolution information to the client if the bug has already been resolved.

We log the user that experienced the error allong with the url that caused the error, which allows for some great scenarios. One of the guys here was involved on one of those high dollar e-waste-of-money.com projects. The idea behind their system was flawed to begin with (IMO), but they did have a very cool customer support feature. They logged errors in a similar fashion and by examining the logs in real time, so they could tell if a customer was having problems using the site. When a customer was experiencing difficulting, they had live support teams on hand to contact that customer and resolve any issues they were encountering. Their customers loved the feature and where always pleasantly suprised that the company actually cared enough about them to give them a call.

5 Comments

  • Another idea would be to use a more generic logging framework like log4net and create a custom Appender that would submit to your bugtracking system. Then when you are in development, you could use ADO.NET, EventLog, or any of the built-in Appenders, but when you go live you can switch to BugTrackAppender with a simple switch in the config file.

  • Yes, you could go both ways. I think the best thing to do would be to submit the bug to your log using an event handler on the bug tracking system. The problem with a generic handler is that you are going to lose a lot of exception specific information that is useful for resolving the bugs. Additionally, the bug tracking DB is a lot more compicated than a simple log.

  • Jesse where would place the code to catch the exception? within a HTTP handler or some other location?

  • Depends on the type of exception. AppDomains have an unhandled exception handler that you can tap into for windows forms apps. For web apps, you would use the Application_Error method in global.aspx.cs/vb/js. From the Application_Error method, you can call Server.GetLastError to get a wrapped exception. The inner exception of this item is the actual exception that was thrown, the outer is a special HTTP exception.

  • Jesse, I wish I had seen your post earlier...my company, Axosoft offers a 100% managed code bug tracking product called OnTime. It's been available since August of 2002 and we have had the exact feature you describe in our application since V1. We also offer a Web Services SDK for OnTime customers to be able to do exactly what you are talking about (catching exceptions and reporting them to the OnTime database through a web service). OnTime is available for both web and windows. Good luck!

Comments have been disabled for this content.