Excel hangs when printing the first time from ASP.NET webservice

Question

We are using Excel to convert SpreatSheetML to XLS in an ASP.NET webservice. Moreover, if the user checks the right checkboxes, we spawn a thread that uses Excel to print the spreadsheet.

Recently, we have deployed the app in a new environment, and then we started having problems: the first time someone tries to print, Excel seems to hang on the server - i.e. the call to the PrintOut method on the workbook never returns.

But if we log in to the server as the application pool identity and open Excel, send something to the printer, and close it again, printing will work from then on!

I suspect that Excel is showing an invisible dialog - the symptoms are the same as we had earlier, a time when Excel seemed to stall on a "cannot use object linking and embedding"-dialog that appeared when Excel opened.

I know that using server-side Office automation is bad, but this is a legacy app that is very hard to change, so please don't just advise me to re-design our solution.

Has anyone had any experiences with this kind of behavior?

Answer 1

Well, noone seems to have had this problem.

The really weird thing is that my night jobs (ordinary .NET .exe) are perfectly capable of printing - it's only my web services that have this problem.

So I solved the problem by doing what I should have done long ago: I made a simple Windows service with Topshelf, that responds to some MSMQ messages and does the printing, and then my web services can order print-outs via a message queue.

Much nicer in every way!

Answer 2

I've had no end of problems (poor performance, hanging processes, crashing processes etc) using Microsoft Excel, Word and PowerPoint through interop in a web service to print Office documents to PDF format. I too have faced problems that I suspect are because of invisible dialog boxes (maybe a file is corrupt, read-only recommended has been set, file is password protected, or whatever).

I know there are tools available that don't use Office, but they are very expensive. My solution was to switch to automating OpenOffice. OpenOffice seems to be much more stable, and I've left hanging processes and the like behind.

So, while I suppose I am saying "don't automate Microsoft Office", I'm not suggesting that you abandon automation altogether; just that I've had much more success automating OpenOffice than Microsoft Office.

Answer 3

SpreadsheetGear for .NET can read xls or xlsx workbooks and can print to the default printer without displaying any dialog boxes (see the WorkbookView.Print() method).

You can download an evaluation here.

Disclaimer: I own SpreadsheetGear LLC

Answer 4

Like many people, I have seen this sort of behavior. It is caused by using the Office APIs in a server, especially a multithreaded ASP.NET application.

However, you've said you don't want to know about not shooting yourself in the foot, so there's little more to say. You seem to be trapped by the consequences of earlier foolishness.

---

OK, stop me if you've heard this one:

A man asks a question on StackOverflow. He says, "SO, bad stuff happens when I automate an Office application from inside a service". So, John Saunders says, "So, don't automate the Office application from inside a service. Automate it from inside a desktop application, as Microsoft intended to be done."

When a request comes in for something that requires Excel, you should create a process running a Windows Forms application. The application may have to start with no window, or you may need to start it in the context of a Remote Desktop connection. In any case, the task to be performed may be passed as a command line parameter, or the program can host a WCF service to have commands sent to it.

This program can call Excel just like Excel expects to be called. It can probably even handle more than one command to Excel (one at a time). However, if it hangs, the process can be killed and another one started.

I've never tried this, but it sounds like it would work better than trying to get Office Automation to do something it was not designed to do.