2

背景

我们正在使用 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)） .

解决方案？

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

感谢您提供的任何帮助。

4

5 回答 5

1

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

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

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

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

于 2008-11-12T23:08:38.857 回答
1

我们使用 Aspose（商业）。服务器上的办公并不好玩。

  • 您必须小心许可。
  • 偶尔你需要杀死一个挂起的进程。
  • 获得正确的权利需要一些努力。

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

于 2008-11-12T23:21:56.100 回答
1

考虑使用XLSX 文件（Office 2007 中的新功能，但有一个适用于 Office 2003 的插件），它们只是包含 XML 文件的 ZIP 文件，您可以在不需要 Excel 的情况下对其进行操作。（基于 XML 的）SpreadsheetML 有很好的文档记录，编程起来也不太复杂（您甚至可以在网络上的某个地方找到一个 LINQ to SpreadsheetML）。

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

于 2008-11-12T23:54:23.087 回答
1

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

<%@ page aspcompat=true %>

更多信息在这里

于 2008-11-13T00:14:30.177 回答
1

来自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 作为服务器端组件加入项目之前，请考虑替代方案。

于 2012-10-18T14:07:52.013 回答