我们有一个包含FileSystemWatcher的Windows服务。这位观察者收集了新的文件创建和生成Excel文档。然后使用Excel Interop将Excel文档自动发送到打印机。
已执行Excel Automation周围的所有设置(在C:\Windows\SysWOW64\config\systemprofile
中创建桌面目录,为Microsoft Excel应用程序上的服务帐户授予本地激活权限。)
打印工作了几天,但突然间,似乎随机,Excel Interop无法打印。服务陷入困境&不继续处理。没有例外,服务只是停止&似乎挂了。下面的代码行是这样的:
ws.PrintOutEx(Type.Missing, Type.Missing, Type.Missing, Type.Missing, printerName, Type.Missing, Type.Missing, Type.Missing);
上面的 ws
是Microsoft.Office.Interop.Excel.Worksheet
一旦发生这种情况,似乎没有任何干预可以解决它。我们已尝试停止服务(使用taskkill
,因为它变得无法响应),终止了正在运行的EXCEL.exe进程&重新开始。我们还尝试重启服务器(运行Windows Server 2008)。每次加载新文件时,服务都会卡在此行上。解决问题的唯一方法是卸载&重新安装Excel。
有没有人知道这可能是什么原因引起的?怎么解决?甚至是阅读文件的替代建议。欢迎将Excel文档自动发送到打印机。
答案 0 :(得分:0)
Microsoft目前不建议也不支持从任何无人参与的非交互式客户端应用程序或组件(包括ASP,ASP.NET,DCOM和NT服务)自动化Microsoft Office应用程序,因为Office在此环境中运行Office时,可能会出现不稳定的行为和/或死锁。
如果要构建在服务器端上下文中运行的解决方案,则应尝试使用已为安全无人值守执行的组件。或者,您应该尝试找到允许至少部分代码在客户端运行的替代方法。如果从服务器端解决方案使用Office应用程序,则应用程序将缺少许多成功运行的必要功能。此外,您将承担整体解决方案稳定性的风险。请在Considerations for server-side Automation of Office文章中详细了解相关内容。
作为一种解决方法,您可以考虑使用Open XML SDK,请参阅Welcome to the Open XML SDK 2.5 for Office。或者只使用为服务器端执行而设计的第三方组件。