使用互操作库Web服务器端的Excel创建

Question

我试图创建一个使用互操作库的Excel文件，但下面是我得到的错误：

Creating an instance of the COM component with CLSID {00024500-0000-0000- 
C000-000000000046} from the IClassFactory failed due to the following error: 8001010a 
The message filter indicated that the application is busy. 
(Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)). 

我看着很多资源，在那里上了网，其广泛地可分为以下：

1. 互操作库是专门为桌面应用程序构建，以及在服务器端网络应用程序使用它们如WCF是highly not recommended。
2. 与交互式用户或DefaultAppPool相关的权限问题。

等等等等。

那么，这里的警告，我不能改变服务器端的应用程序，一切工作在其他地方。几天前，Office 2016从我的机器上被推到我的机器上，并且在我的本地机器上停止工作（出现以上错误）。现在我不能去改变一个遗留代码，但看看我是否可以解决我的本地问题以进一步开发。

下面是我做什么，请注意一切工作本机（当Office 2013在那里）上：

1. 拿到办公室2016卸载，然后重新安装Office 2013，同样的问题，因此又恢复到办公室2016.目前MS-Office 2016 32位已安装。
2. Microsoft Excel Application安全选项卡的各个部分验证的权限已添加IIS AppPool \ DefaultAppPool用户，IIS_IUSRS，具有完全控制权限的交互式用户（不应该错误为“访问被拒绝”，权限已被错误？）
3. 创建一个新的示例web应用程序，以快速调试，运行它的所有组合的CPU平台，即x86，AnyCpu，x64 - 同样的问题。
4. 有趣的是，它工作如果我的示例应用程序指向IIS Express而不是本地IIS。
5. 增加了最新的版本互操作程序集用（安装，包装的Microsoft.Office.Interop.Excel -Version 15.0.4795.1000） - 还是同样的问题
6. 新增的Microsoft Office 16.0对象库（2.8）到项目 - 仍然相同问题

这是一个古老的问题及其可能更好地逃脱互操作，但我想知道什么可能会错误的 - 所有的上述建议实施IMessageFilter或什么不是错误的直接结果，但我不能更改服务器端代码，下面的代码应该像前几天一样工作：

Microsoft.Office.Interop.Excel.Application l_ExcelApp = 
new Microsoft.Office.Interop.Excel.Application(); 

但它没有，所以改变了？可能出了什么问题？

此外，如果它有帮助--dcomcnfg（/ 32）中列出的ApplicationID是：00020812-0000-0000-C000-000000000046}，但错误有一个不同。

去哪里看？我希望这个问题的答案可以引导失去的灵魂永远关于这个问题。

Answer 1

终于我能解决我的问题。以下工作：

Web应用程序托管在IIS中创建Excel文档。

事实证明，除了权限之外，应用程序体系结构也应该是相似的，即我的应用程序是64位（在64位操作系统上以Any CPU运行）也是非常重要的。每当遇到这样的问题时，请确保以下（除了将权限设置为正确的用户之外）：

1. 确保两个应用程序（您自己的和excel）的架构同步。知道你的excel是64位还是32位的一个快速方法是查看任务管理器正在运行的程序。如果excel被列为EXECEL.EXE*32，那么你的办公室是32位。

2. 当您安装Excel的一个新版本，请确保您完全删除以前的版本（而不仅仅是卸载，而且去除通过删除任何注册表项，即dcomconfig办公室的条目可以在注册表编辑器找到所涉及的Office应用程序的GUID ，特别擅长）。

3. 我把它通过在2描述完全删除Office 2016后安装Office 2013，并在我的代码相应的固定Microsoft.Office.Core参考工作。我被分配以下

4. 权限： 应用程序标识 - 交互式用户 和安全选项卡中，添加IIS应用程序池\默认应用用户所有部分，并给予了充分的权限。
5. 我的应用在IIS内部的ApplicationPoolIdentity中运行。

如果上述所做的一切仍然无法解决您的问题，那么上帝与您同在，为您迈向开放XML的旅程带来更多权力。

Answer 2

我建议使用Open XML SDK在服务器端处理或生成开放式XML文档，有关更多信息，请参阅Welcome to the Open XML SDK 2.5 for Office。或者只是使用为服务器端执行而设计的任何第三方组件。

正如你已经注意到了，​​文章指出以下几点：

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

如果您正在构建一个在服务器端上下文中运行的解决方案，那么您应该尝试使用对于无人执行安全的组件。或者，您应该尝试找到允许至少部分代码运行客户端的替代方案。如果您从服务器端解决方案使用Office应用程序，则该应用程序将缺少成功运行所需的许多必要功能。此外，您将面临整体解决方案稳定性的风险。