Introduction

Every developer knows how important a good bug report is, and every developer wants as much details about the issue as the user can provide. There are different solutions that aim to facilitate the error reporting process, from tiny third-party components to such powerful technologies like Microsoft Windows Error Reporting, but most of them are designed to report fatal error only.

Missed text, incorrect functionality, wrong output - your users may want to report these issues too. And, even if it looks like a minor problem for the user, you may want to see log files, configurations, system information, etc. Moreover, the user may use multiple applications developed by your company, and to locate the problem, you may be interested to add to the report a few common logs or configurations.

All these thoughts were taken into account during the designing of Sedge - an Open Source, free utility that helps to automate error reporting by collecting all the necessary information, files, descriptions, and presenting it in a nice HTML view. The target platform is Microsoft .NET 2.0.

How it works

Sedge is a wizard style application, and proposes the user to take an issue screenshot, enter description and contact information, and add the user's files. The last step of the wizard is a report generation. Sedge copies all the files you want to see in the report, collects system information, creates report HTML pages, and zips the report. The user can review the report and email it to you.



The configuration file (default extension is .sedge) is the key to all the features of the tool. The configuration describes all the aspects of the process - the wizard's steps, files, and information to collect, report representation, etc. If the path to the configuration file is not provided as a command line parameter, Sedge will try to read it from Sedge.exe.config and tries to search for it in the current folder and subfolders.

Command line example:


Sedge.exe /suite="C:\Apps\QuickStart.sedge"




Configuration example:


?>
xml version="1.0" encoding="UTF-8" >

caption="TaggedFrog Error Reporting" partial="no">














































The main unit of the configuration is a suite. The suite represents a collection of the related applications, and could be described in one file or split into multiple parts. This means that you can have one main configuration file describing the wizard UI and the common properties, and add/remove the suite part when you install/uninstall applications. The error report will include information requested in the main configuration plus information specific for the reported application (see Sample 4 in the attached archive).

The schedule section describes the steps that will be displayed to the user. Every step tag represents a class implementing the IStepController interface, and you can easily create your own steps to add or replace the existing ones (Sample 5). Because the GUI code is separated from the logic, you can even completely replace the user interface, for example, if you like to use WPF instead of WinForms.

Eventually, you are able to customize almost every aspect of the process. For example, if you don't like e-mail as a method of reports delivering, you can add your own transport protocol.

Report

The next aspect of the report generations is... the report itself. The configuration defines the structure of the report while the style is controlled by the template. The template consists of the HTML, CSS files, and the images, so you can modify it to match your corporate style.



Every page may include one or more sources of information to report. There are four types of sources:

• displays information provided by the user (screenshots, error details, etc.)
  
• displays information about the files - path, size, and version
  
• instructs the application to copy files to the report and print links to these files on the page
  
• is actually a meta-source; the name attribute is used to select a class implementing the IDataSource interface and returning the required information
  
  Out of the box, there are three classes:
  
  
  
  • Processes to display the running processes information
    
  • System to display information about the OS and the hardware
    
  • Table to print the provided information in the table form; it can be used to display the information contained in the properties
    
    And as usual, you can create your own source:
    

<Data name="CurrentDate" assembly="${custom.dll}" caption="Now" />

    
    
    
    A property is a container that can store text information, and can be set directly in the configuration to get a value from the Registry. If you'd like to setup a property in a different way, for example from .ini files, you are able to create a custom property handler.
    

public class EchoProperty : ICustomProperty
{
public string GetValue(Options options)
{
return String.Concat("Echo: ",
options.GetGeneralOption("Param", "param"));
}
}






value="${sedge.this.folder}\DLL\Demo.Customization.dll" />
assembly="${custom.dll}" value="Echo">




    
    
    
    Two predefined properties are available in every configuration: ${sedge.this.folder} - the path to the configuration file, and ${sedge.this.file} - the configuration file name.
    
    To be usable in the real world, Sedge supports localization and rebranding. All strings are located in a separate file; you can modify the current translation or add a new one, and change the application name.
    
    

    Conclusion
    
    Sedge aims to help your customers create better bug reports, and gives you a way to control what information should be added to the report. With Sedge, users can report not only fatal crashes but also usability issues, incorrect functionality, etc. One of the main tasks of the application is to provide an error report in the context of the application suites, and it could be achieved using partial configurations. Sedge can be used as a ready-to-go tool, or customized to satisfy your specific goals.
    
    Project site: sedge.codeplex.com.
    
    First version of the article.
    
    

    About the Author
    
    I am a software developer from Toronto with 15 years of experience in software design and development. My major professional area is the development of highly customized software solutions, including desktop and web applications. Industrial process automation and hardware-related software development are among my favorite projects and I enjoyed developing several applications for semiconductor manufacturing companies.
    
    My blog: http://LunarFrog.com/blog
    
    
    
    

    License
    
    This article was authored by Andrei Marukovich and reproduced for the benefit of our viewers under the terms of the Ms-PL license.