使用 ASP.NET 自动化 Excel

Question

背景

我们正在使用 ASP.NET 2.0 开发一些内部实用程序。 其中之一是从数据库中提取一些信息，并构建一个 Excel 工作簿，其中包含许多电子表格，其中包含基于数据库查询的数据。

问题

概念验证原型（一个简单的 ASP.NET 页面，从数据库查询单个项目并打开 Excel 以将数据添加到工作表）在开发计算机上本地运行时运行良好，可以愉快地创建和显示 Excel按要求制作电子表格。 但是，当在我们的服务器上运行时，我们在尝试实例化 Excel 时收到以下错误。

无法将类型“Microsoft.Office.Interop.Excel.ApplicationClass”的 COM 对象强制转换为接口类型“Microsoft.Office.Interop.Excel._Application”。 此操作失败，因为对 IID 为“{000208D5-0000-0000-C000-000000000046}”的接口的 COM 组件上的 QueryInterface 调用由于以下错误而失败：不支持此类接口（HRESULT 异常：0x80004002 (E_NOINTERFACE)） 。

解决方案？

我们正在使用 Excel 2003 的 PIA，并且我们在服务器上安装了 Excel 2003 和 PIA。 谁能解释为什么这不起作用，或者给我们一些关于如何追踪问题的提示？

感谢您提供的任何帮助。

Answer 1

运行 ASP.NET 应用程序池的用户是否可以访问该应用程序？ 尝试以该用户身份登录（或将应用程序池更改为以该用户身份运行）并打开 Excel。 如果可行，请尝试使用失败的代码以该用户身份在服务器上运行 WinForms 应用程序。

不确定，但我认为 PIA 程序集可能需要通过 regsvr32 注册。

我怀疑如果您作为网络​​服务运行，您将无法启动 Excel（无交互式登录、受限帐户等）。 您的 ASP.NET 代码在应用程序池内运行。 您可以通过 IIS 管理器更改应用程序池运行的用户。 如果您想检查当前正在运行的代码，请在任务管理器中查找 w3wp 进程。

为了进行测试，请将应用程序池更改为以您认识的使用 Excel 的用户的身份运行。

Answer 2

我们使用 Aspose（商业）。 服务器上的办公室没什么乐趣。

• 您必须小心许可。
• 有时您需要终止挂起的进程。
• 获得正确的权利需要付出一些努力。

它被称为 PI(t)A 是有原因的......

Answer 3

考虑使用 XLSX 文件（Office 2007 中的新功能，但 Office 2003 中有一个插件），这些文件只是包含 XML 文件的 ZIP 文件，无需 Excel 即可操作。 （基于 XML 的）SpreadsheetML 有很好的文档记录，并且编程起来也不是太复杂（您甚至可能在网络上的某个地方找到 LINQ to SpreadsheetML）。

正如上面指出的，Excel 并不是真正的服务器产品，在服务器上使用它时可能会遇到各种问题。

Answer 4

我认为问题在于，一旦将应用程序部署到 IIS，您就会突然在 MTA COM 公寓内运行。 我认为 Excel 是一个 STA 组件，因此不能在 MTA 内创建。 您需要在您使用的页面中设置 aspcompat 选项

<%@ page aspcompat=true %>

更多信息< /a>

Answer 5

来自 Microsoft（强调原始来源）：

Microsoft 目前不建议也不支持从任何无人值守、非交互式客户端应用程序或组件（包括 ASP、ASP.NET、DCOM 和 NT 服务）实现 Microsoft Office 应用程序的自动化，因为 Office当 Office 在此环境中运行时，可能会表现出不稳定的行为和/或死锁。

列出了不应执行此操作的原因：

• ... 许多服务在没有用户配置文件的帐户（例如 SYSTEM 帐户或 IWAM_[servername] 帐户）下运行。 因此，Office 在启动时可能无法正确初始化。 在这种情况下，Office 在 CreateObject 函数或 CoCreateInstance 函数上返回错误。 即使 Office 应用程序可以启动，如果不存在用户配置文件，其他功能也可能无法正常工作。
• 如果发生意外错误，或者需要未指定的参数来完成某项功能，Office 会通过模式对话框提示用户，询问用户想要执行的操作。 无法关闭非交互式桌面上的模式对话框。 因此，该线程无限期地停止响应（挂起）。 尽管某些编码实践可以帮助降低出现此问题的可能性，但这些实践不能完全防止此问题。 仅这一事实就使得从服务器端环境运行 Office 应用程序存在风险且不受支持。
• 服务器端组件需要是高度可重入的多线程 COM 组件，为多个客户端提供最小的开销和高吞吐量。 Office 应用程序几乎在所有方面都完全相反。 Office 应用程序是不可重入的、基于 STA 的自动化服务器，旨在为单个客户端提供多样化但资源密集型的功能。

并且您的代码可能会引发以下错误：

• CoCreateInstance

  • 运行时错误“429”：ActiveX 组件无法创建对象
  • 运行时错误“70”：权限被拒绝
  • CO_E_SERVER_EXEC_FAILURE (0x80080005)：服务器执行失败
  • E_ACCESSDENIED (0x80070005)：访问被拒绝
  • 挂起
  • 返回时没有错误，但不起作用

最后：

由于 Office 设计的限制，对 Office 配置的更改不足以解决所有问题。 Microsoft 强烈推荐多种替代方案，这些方案不需要在服务器端安装 Office，并且可以比自动化更高效、更快速地执行大多数常见任务。在将 Office 用作服务器端之前项目中的组件，请考虑替代方案。