使用ASP.NET自动化Excel
背景
我们正在使用ASP.NET 2.0开发一些内部实用程序。 其中之一是从数据库中提取一些信息，并build立一个Excel工作簿，其中包含许多基于查询数据的电子数据表。
问题
概念validation原型（从数据库查询单个项目并打开Excel以将数据添加到工作表的简单ASP.NET页面）在开发机器上本地运行时运行良好，可以愉快地创build和显示Excel电子表格按照要求。 但是，在我们的服务器上运行时，尝试实例化Excel时出现以下错误。
无法将“Microsoft.Office.Interop.Excel.ApplicationClass”types的COM对象转换为接口types“Microsoft.Office.Interop.Excel._Application”。 此操作失败，因为具有IID“{000208D5-0000-0000-C000-000000000046}”的接口的COM组件上的QueryInterface调用由于以下错误而失败：没有此类接口支持（exception来自HRESULT：0x80004002（E_NOINTERFACE）） 。
解？
我们使用PIA for Excel 2003，并且在服务器上安装了Excel 2003和PIA。 任何人都可以解释为什么这不起作用，或给我们一些提示，我们可以跟踪这个问题？
感谢您提供的任何帮助。
运行ASP.NET应用程序池的用户是否可以访问该应用程序？ 尝试以该用户身份login（或更改应用程序池以作为该用户运行）并打开Excel。 如果这样做的话，尝试在该服务器上以失败的代码运行一个WinForms应用程序。
不知道，但我认为PIA程序集可能需要通过regsvr32进行注册。
我怀疑，如果你作为networking服务运行，你将无法启动Excel（没有交互式login，受限制的帐户等）。 您的ASP.NET代码在应用程序池内运行。 您可以通过IISpipe理器更改应用程序池运行的用户。 如果你想检查你的代码是否正在运行，查找任务pipe理器中的w3wp进程。
对于testing，将应用程序池更改为以您熟悉Excel的用户身份运行。
我们使用Aspose（商业）。 在一台服务器上的办公室没有太多乐趣。
- 你必须小心许可。
- 有一段时间，你需要杀死一个挂起的过程。
- 获得正确的权利需要一些努力。
它被称为PI（t）A的原因…
考虑使用XLSX文件 （在Office 2007中是新增function，但是有一个用于Office 2003的插件），它们只是包含XML文件的ZIP文件，您可以在不需要Excel的情况下操作它们。 （基于XML的）SpreadsheetML有很好的文档logging，不需要太复杂的编程（你甚至可以在networking上find一个LINQ to SpreadsheetML）。
如上所述，Excel并不是真正的服务器产品，在服务器上使用时可能遇到各种问题。
我认为问题在于，一旦将应用程序部署到IIS，您将突然在MTA COM Apartment中运行。 我相信Excel是一个STA组件，因此不能在MTA内创build。 您将需要在您正在使用的页面中设置aspcompat选项
<%@ page aspcompat=true %> 更多信息在这里
来自微软 ，（原文重点）：
Microsoft目前不推荐并不支持从任何无人参与的非交互式客户端应用程序或组件（包括ASP，ASP.NET，DCOM和NT服务）中自动化Microsoft Office应用程序，因为Office可能会出现不稳定的行为和/或在此环境中运行Office时发生死锁。
有一系列你不应该这样做的原因：
- …许多服务在没有用户configuration文件的帐户下运行（例如SYSTEM帐户或IWAM_ [服务器名称]帐户）。 因此，Office启动时可能无法正确初始化。 在这种情况下，Office在CreateObject函数或CoCreateInstance函数上返回一个错误。 即使Office应用程序可以启动，如果没有用户configuration文件存在，其他function可能无法正常工作。
- 如果发生意外的错误，或者如果需要未指定的参数来完成一个function，Office被devise为提示用户一个模式对话框，询问用户想要做什么。 非交互式桌面上的模式对话框不能被解除。 因此，该线程无限期地停止响应（挂起）。 虽然某些编码做法可以帮助减less这个问题的可能性，但这些做法并不能完全防止这个问题。 仅凭这一事实，使得从服务器端环境运行Office应用程序的风险和不受支持。
- 服务器端组件需要是高度可重入的，multithreading的COM组件，对于多个客户端来说，它具有最小的开销和高吞吐量。 几乎所有的办公应用程序都完全相反。 Office应用程序是不可重入的，基于STA的自动化服务器，旨在为单个客户端提供各种资源密集型function。
而你的代码可能会抛出以下错误：
-
CoCreateInstance- 运行时错误“429”：ActiveX组件不能创build对象
- 运行时错误“70”：权限被拒绝
- CO_E_SERVER_EXEC_FAILURE（0x80080005）：服务器执行失败
- E_ACCESSDENIED（0x80070005）：访问被拒绝
- 挂起
- 没有错误返回，但没有工作
最后：
由于Officedevise的限制，对Officeconfiguration的更改不足以解决所有问题。 Microsoft强烈build议大量替代scheme不要求在服务器端安装Office，并且可以比自动化更高效地执行最常见的任务。 在将Office作为服务器端组件引入到项目之前，请考虑其他select。