首次从 ASP.NET Web 服务打印时 Excel 挂起
我们在 ASP.NET Web 服务中使用 Excel 将 SpreatSheetML 转换为 XLS。 此外，如果用户选中正确的复选框，我们会生成一个使用 Excel 打印电子表格的线程。
最近，我们在新环境中部署了应用程序，然后开始遇到问题：第一次有人尝试打印时，Excel 似乎挂在服务器上 - 即对 PrintOut 方法的调用工作簿永远不会返回。
但是，如果我们以应用程序池身份登录服务器并打开 Excel，向打印机发送一些内容，然后再次关闭它，从此打印就可以了！
我怀疑 Excel 显示了一个不可见的对话框 - 症状与我们之前的情况相同，当时 Excel 似乎因“无法使用对象链接和嵌入”而停滞不前 - Excel 时出现的对话框打开。
我知道使用服务器端 Office 自动化很糟糕，但这是一个很难更改的遗留应用程序，所以请不要只是建议我重新设计我们的解决方案。
有人有过这种行为的经历吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好吧，似乎没有人遇到过这个问题。
真正奇怪的是，我的夜间工作（普通的 .NET .exe）完全能够打印 - 只有我的网络服务有这个问题。
所以我通过做我早就应该做的事情解决了这个问题：我用 Topshelf 做了一个简单的 Windows 服务，它响应一些 MSMQ 消息并进行打印，然后我的 Web 服务可以通过消息队列订购打印输出。
各方面都好得多！
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!
我在使用 Microsoft Excel、Word 和 PowerPoint 通过 Web 服务中的互操作将 Office 文档打印为 PDF 格式时遇到了无穷无尽的问题（性能差、进程挂起、进程崩溃等）。 我也遇到过问题，我怀疑是由于看不见的对话框造成的（可能文件已损坏，已设置只读建议，文件受密码保护，或其他）。
我知道有一些不使用 Office 的工具，但它们非常昂贵。 我的解决方案是改用自动化 OpenOffice。 OpenOffice 似乎更加稳定，并且我已经将挂起的进程等抛在了后面。
因此，虽然我想我是在说“不要将 Microsoft Office 自动化”，但我并不是建议您完全放弃自动化；而是建议您完全放弃自动化。 只是我在 OpenOffice 自动化方面比 Microsoft Office 取得了更多的成功。
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.
SpreadsheetGear for .NET 可以读取 xls 或 xlsx 工作簿，并且可以打印到默认打印机而不显示任何对话框 (请参阅 WorkbookView.Print() 方法）。
您可以在此处下载评估版。
免责声明：我拥有 SpreadsheetGear LLC
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
和许多人一样，我见过这种行为。 这是由于在服务器中使用 Office API 引起的，尤其是多线程 ASP.NET 应用程序。
然而，你说过你不想知道不要搬起石头砸自己的脚，所以没什么可说的。 你似乎被先前愚蠢的后果所困。
好吧，如果您听说过这个：
一个男人在 StackOverflow 上问一个问题。 他说：“所以，当我从服务内部自动化 Office 应用程序时，会发生不好的事情”。 因此，约翰·桑德斯 (John Saunders) 表示，“所以，不要从服务内部自动化 Office 应用程序。从桌面应用程序内部自动化它，就像 Microsoft 打算做的那样。”
当收到需要 Excel 的请求时，您应该创建一个运行 Windows 窗体应用程序的进程。 应用程序可能必须在没有窗口的情况下启动，或者您可能需要在远程桌面连接。 在任何情况下，要执行的任务都可以作为命令行参数传递，或者程序可以托管 WCF 服务以将命令发送给它。
该程序可以像 Excel 期望的那样调用 Excel。 它甚至可能可以处理多个 Excel 命令（一次一个）。 但是，如果它挂起，则可以终止该进程并启动另一个进程。
我从来没有尝试过这个，但听起来它比试图让办公自动化做一些它没有设计做的事情效果更好。
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.