I need to create a simple application that would generate reports based on database data and some user input. I have vast C/C++ experience, but for this project we had to choose C#.
I want to avoid using 3rd-party components that would require installation on a client machine as much as possible. Thus, I would like to avoid using even the features provided by MS Office (I could have used an XLS template, just like my predecessor did, but it doesn’t look like a way to go; anyways, my predecessor’s sources are long lost, which is probably good, since it is a roughly 10-years-old VB monstrosity that crashes every now and then). The same goes for crystal reports and whatnot.
My current idea is to build HTML tables (using an HtmlDocument) on the fly, to present them to the user (using a WebBrowser) and to print them. Is it a right way to go? Are there any simpler/more robust/better approaches? What are the possible pitfalls?
Building tables on the fly would work. I use that technique every so often, but it seems like a hack to me. I only use it because quite often, the business need requires “good enough” and quick turnaround as opposed to “beautiful”.
I’m going to preference what I’m about to suggest bysaying that I have a strong bias against 3rd-party components myself.
I flat out refuse to use them in most cases and will go out of my way to come up with another solution, because I’ve been burned on upgrades/licensing too often.
That said…
Fortunately, with .NET not all 3rd party components need to be installed to your clients PCs. With XCOPY deployment, often you can just reference a .DLL or a project in the solution ans specify the “Copy Always” or “Copy if newer” option to just include the dll (or resulting dll if you’re referencing a class library project) and as long as the .dll is present in the same directory as the executable, the 3rd party component works.
With all of that in mind, there’s a project that I’ve used to print a DataGridView from Windows Forms at CodeProject. This is one that you can get the source for, reference it, and use it without having to actually install anything at the client. I’ve used it in more than one app, and it’s one of my favorite tools.
It will print ONLY the DataGridView, but it prints it exactly as it appears on screen, so if that’s what you want, I’d recommend at least checking it out.
As a third option, you could consider using ASP.NET. If you’re going to be generating HTML, it’s just as easy (easier actually) to do it using ASP.NET than in a WinForms app. Using ASP.NET you get Repeaters, ListViews, etc, all of which make the reports easy to create.
I’ve got more than one real-world app that is primarily a WinForms app but has an associated reporting site.
For example, I have a WinForms app used for scanning coupons accepted at our retail locaitons. It’s a WInForms app because I need to interact directly with the scanner on a COM port. However, for the reporting portion, I set up an ASP.NET website. In the WinForms app it’s very simple to create a reporting menu option and point to the pages. Our users generally don’t even think about the fact that this is two distinct applicaitons. They see it as one – their Coupon Scanning app.
The point of all that is that it’s usually possible to do things with any given tool, but it’s far easier to use the tool that is meant for the job. If you’re going to be generating HTML reports, ASP.NET is a better tool than building the reports manually, and if you need to have a WinForms app for most of the UI, you can still do that and use the website for the reports – using the best tool for each task.