We're looking to print a very high volume of rendered reporting services reports (up to 100 users printing and some batch jobs printing thousands to tens of thousands of reports serially). I've done a lot of research and the best bet that I've found is using their URL access to render as EXCEL and using Aspose.Cells .NET to print the rendered stream (best combination of speed and fidelity ... their IMAGE format simply doesn't cut it for barcodes). This seems to work decently fast (around a second to print a simple 1 page report), but I was hoping to get some information about the amount of volume and performance testing done on the SheetToPrinter method. Based on the little GUI that pops up, I see that you're using the System.Drawing.Printing namespace to print the document. When I look at the MSDN help for that namespace, I see the following warning:
Classes within the System.Drawing.Printing namespace are not supported for use within a Windows service or ASP.NET application or service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.
Has Aspose done any research on printing a large number of sheets using Aspose.Cells .NET, specifically in a server process?
Also, if there are any suggestions on a better way to do this with another reporting services method/Aspose product, I'm all ears.
Thanks for sharing us the details.
We will get back to you for your inquiry soon.
Since you want to do printing in a Web Service using our product, so there might be four components involved, e.g.., Web Service application, Aspose.Cell, printer and web browser etc.
We want to know where is the printer located. Is it on the Web service side or on the Web browser side?
Thanks for providing us further details.
The printer is located server-side. This web service would be callable by any client that has access to standard HTTP libraries, and those clients do not need access to the printer.
Let me know if you need more information,
Thanks for providing us further details.
We will get back to you soon.
We have made some tests: we tried to connect the printer in an ASP.NET application on the server side, but it failed as MSDN describes.
We provide a solution for your requirement if it suits you:
1) In an ASP.NET environment, try using sheet to image feature provided by Aspose.Cells and save them (images) to some directory, for example: “d:\ImageToPrint”
2) Now, setup a new application that could read images from that directory and print them one by one accordingly.
BTW in our opinion and according to your description provided, there would be lots of people using this system at the same time, so, there will be many pieces of paper printed on the server side and they might be mixed together too, how will you separate and manage them?
We have a highly configurable routing module that will select the appropriate printer based on the user, process, and/or business object(s) driving the documentation.
Do you have a suggestion on how to safely print these images? The only option I see is again using System.Drawing.Printing, which gets us back to the same issue.
Well, you may try the following steps:
1. You can save workbook to xls/xlsx files with strong password. No one should be able to open these files unless he/she provides the valid the password.
2. Run another regular application with Aspose.Cells which does not run in the context of IIS or windows service. It converts those encrypted xls/xlsx files to printer when finding new excel file(s) generated by Web application. This application will cross the System.Drawing.Printing namespace limitation set forth by IIS and windows service.
3. This asynchronous method will also avoid web application’s blocking when the printer is printing files.
Aspose.cell supports every strong encryption provided by Microsoft Excel.
Hopefully, it will help you a bit.
Is this a tested solution at the scale we're discussing? We used to do something similar to this with Microsoft Word automation in .NET and ran into all types of issues, to the point where Microsoft basically told us Word was not made to handle such a load. Without some benchmarking results to prove otherwise, I'd expect the same end result out of System.Drawing.Printing based on their above statement. Also, running a console dependent application to perform server-scale processing just isn't that attractive of an idea (imagine telling a customer's IT staff that they have to have one of their servers logged in to run your software).
I've done some more research and I'm thinking there's no reliable way to do this with .NET unless you're willing to develop the software that will produce the raw data that you can send directly to the printer using the Win32 spooler functions (`http://support.microsoft.com/kb/322091`... and this isn't something I'm willing to invest). Otherwise, you have to depend on some sort of 3rd party solution that already does this for you (and often times that's an unmanaged solution that runs in its own process).
So, I guess the question has evolved to whether or not Aspose.Cells, or any other Aspose product, will provide an alternative to their System.Drawing.Printing solution.
Our products are written with managed code and depends on System.Drawing.Print classes to render it to printer.
Aspose.Cells can convert an Excel file to Pdf file. Maybe you can try to send the pdf files to a virtual Pdf printer for printing.