BugNET

The reports were using the microsoft report viewer which causes numerious problems in a medium trust / host environment so thats why it was pulled. Reports will return eventually and more feedback like yourself will help us decide what reports to build in the future.

One of the main issues with any software that can handle reporting is how to implement it.  With custom software you can often get away with doing canned reports since you can have all the users/management design the reports they want.  From there is it picking a reporting engine and developing the reports.

With software like this it is very hard because of the limitations of the install base and the unknown as to what kind of reports are useful.

I suggest some ways to handle this:

1. Having a way to plug into SQL Server reporting service, BugNET could simply have a page that shows a list of reports to offer and when you select the report it opens a report viewer page from the Reporting Server.  Offer a way to enable and configure the Reporting Server (web apis, login credentials for a user that has access to the reports, report folder in Reporting Server that holds the reports, etc.) in BugNET.  Doing this would allow users to be able to install Reporting Services if they can and run the reports from BugNET.  The reporting page(s) and assemblies could be offered as a separate download (so no reference to Reporting Service is needed within BugNET) with instructions on how to implement.

2. Create a generic reporting page that displays a list of reports.  Have like a report table and a report parameter table (these reports map to an existing SQL View).  Each report can be configured with one or more parameters as needed, when the report is viewed the parameters are displayed (if any) and when you hit the [Generate] button it uses Xml/Xsl transforms to generate csv file of the data.  Possibly use the provider pattern to implement the different types of formats behind the scenes.

3. Create a reporting page like above but that does an Xml/Xsl transform to Excel.  If you save an Excel file as Xml it can be literally imported into an Xsl template and used, all that is required is replace the <Row/> element data with the data from the Xml (using <xsl:select />).  The transform would create an Xml version of the Excel file (like what was saved).  I believe that Excel 2003+ supports Xml file formats named (.xls).

The pattern here is creating a way to allow access to the reports but have the users create the reports and or install the infrastructure for the reports.

My .02.