BugTracker.NET is an excellent piece of software which can be found here.
The description on the BugTracker.NET site is:
BugTracker.NET is a free, open-source, web-based bug tracker or customer support issue tracker written using ASP.NET, C#, and Microsoft SQL Server (or its free cousin, SQL Server Express). It is in daily use by thousands of development and customer support teams around the world.
For those that are looking for a flexible open source helpdesk system, I highly recommend it.
Our need here is that we have several customer web applications running in our hosting infrastructure and we started to receive reports of errors with either incomplete descriptions or without any description at all.
The best solution found here is to use a component from ASP.NET called HealthMonitoring.
The principle is simple, publish events and tracking from the application to a destination. The destination can be just about anything: File, SQL Table, E-Mail, etc. Since this is built on top of the provider model – it is very easy to customize and extend.
Now to the point of this post, we have created a BugTracker WebEvent Provider for ASP.NET (2.0 or above) that can be configured to log events to BugTracker itself.
If you use the following configuration in the <system.web/> section of your ASP.NET app:
<healthMonitoring>
<providers>
<add name="BugTrackerWebEventProvider"
type="BugTrackerWebEventProvider.BugTrackerWebEventProvider" bufferMode="Notification" buffer="true" Username="username" Password="password" URL="http://url_to_bugtracker/insert_bug.aspx?" ProjectID="bugtracker project id"/>
</providers>
<rules>
<add name="LogAllEvents" eventName="All Errors" provider="BugTrackerWebEventProvider"/>
</rules>
</healthMonitoring>
You will be effectively logging “Errors” as new requests/bugs to BugTracker.NET – it is important to understand however that while this is very nice to fill up the database you must be ready to deal with the load and use BugTracker effectively to link and deal with the issues that are created. Our systems have several thousands of users, you can imagine how a client can panic if 50 users all hit a section that triggers a semi-handled exception that happens to be logged in the system regardless.
I have included a demo application below to demonstrate how to set up the provide within the web.config so that you can easily make it fit within your development/production projects.
Personally, I would use this provider mostly in a “client UAT/QA” phase or in production – I don’t recommend it in development.
And here is the same provider, in release build
0 comments:
Post a Comment