【问题标题】:Word Automation with ASP.NET使用 ASP.NET 实现文字自动化
【发布时间】:2014-08-13 14:49:02
【问题描述】:

我有一个在 asp.net 中使用 Microsoft Word 自动化的旧应用程序,我需要将它安装在带有 Office 2013 Standard x86 的 Windows Server 2012 R2 x64 上。我知道应该避免像 IIS 这样的服务器技术中的 Office 自动化,但我目前没有重写应用程序的绿灯,所以我必须照原样。

最初我启动了应用程序,它给出了这个错误:

由于以下错误,检索具有 CLSID {000209FF-0000-0000-C000-000000000046} 的组件的 COM 类工厂失败:80070005 访问被拒绝。 (来自 HRESULT 的异常:0x80070005 (E_ACCESSDENIED))。

网上查了一些资料说{000209FF-0000-0000-C000-000000000046}是通用Word的标识符,没有具体版本。

我转到组件服务 -> 我的电脑 -> DCOM 配置 -> Microsoft Word 97 - 2003 文档(请注意,Microsoft Word 或 MS Word 或 Word 没有节点,而 Microsoft Excel 有节点)并更改了安全性以允许 IIS AppPool 用户“本地启动”、“本地激活”和“本地访问”。这使得应用程序需要一些时间来响应(超过一分钟)并失败并出现以下错误:

由于以下错误,检索具有 CLSID {000209FF-0000-0000-C000-000000000046} 的组件的 COM 类工厂失败:80080005 服务器执行失败(来自 HRESULT 的异常:0x80080005 (CO_E_SERVER_EXEC_FAILURE))。

同时事件查看器系统日志显示:

服务器 {000209FF-0000-0000-C000-000000000046} 未在要求的超时时间内向 DCOM 注册。

我在网上搜索了一些可能访问权限不对的信息,包括系统驱动器路径和注册表。我运行了进程监视器并检查了进程试图打开的内容。我授予 IIS AppPool 用户对以下内容的完全访问权限:

  • C:\Windows\SysWOW64\config\systemprofile
  • C:\Windows\Temp
  • HKU.DEFAULT\Software\Microsoft\Office
  • HKLM\Software\Wow6432Node\Microsoft\Office
  • HKLM\Software\Wow6432Node\Microsoft\Shared Tools

当我再次运行该应用程序时,它只在 Process Monitor 中显示了一些访问问题,这似乎只是试图读取不同的配置。应用程序本身不再显示任何类型的错误,它只是冻结了。我没有在该机器上安装 Visual Studio,但我在应用程序日志中看不到任何错误,因此没有引发异常。

我还尝试在 DCOM 身份中设置特定用户(本地管理员),但没有任何变化。

现在我恢复了所有权限,我又回到了 0x80080005 错误,因为它至少为我提供了一些尝试使用的信息。

我成功地用这个代码在一个简单的应用程序中重现了错误:

try
{
    l1.Text = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
    var application = new Microsoft.Office.Interop.Word.Application();
    l2.Text = "OK";
}
catch (Exception ex)
{
    this.Label2.Text = ex.ToString().Replace("\r\n", "<br/>");
}

在带有 Office 2013 Pro x64 的 Windows 8 x64 上也失败,错误完全相同。

如果我将当前用户冒充为管理员,那么它可以工作。但是,即使将 IIS APPPOOL\DefaultAppPool 添加到管理员组,它仍然失败。

对接下来的步骤有什么想法吗?

【问题讨论】:

  • 首先授予 apppool 对所有内容的完全访问权限。如果可行,您至少知道您的方向是正确的,需要弄清楚它需要哪些特定的权限
  • 我尝试在默认情况下将所有 COM 组件的完全访问权限授予所有人(在我的电脑中),但仍然无法正常工作。您指出的另一个问题使用了另一个版本的 Word - 我根本没有这些键和 DCOM。
  • 当我遇到这个问题时,我通过将 IIS_IUSRS 和 IUSR 添加到允许的用户来成功尝试如果这对你有用
  • 如果我是你,我会强烈反对在服务器上使用互操作 API。这是灾难的秘诀。明确指出,使用 Interop 库比部分重写应用程序以使用不依赖 COM 的体面库的成本更高。

标签: asp.net office-automation windows-server-2012-r2


【解决方案1】:

所以这就是最后的工作:

  • 创建管理员用户并在 DCOM 设置中设置 Word 以使用它运行
  • 在设置中为 AppPool 用户以及 IIS_IURS 和 IUSR 提供​​激活、启动和访问权限。请注意,如果您不将权限授予其他人,仅授予 AppPool 用户,Windows 仍然会报告 AppPool 用户没有足够的权限,这完全是误导

我还发现了冻结 Word 的问题是:创建新文件导致 Word 以特殊模式打开,它告诉您该文件可能存在危险。当然,使用 COM 您看不到问题,但除非您允许,否则它将无法继续。这是 Word 2013 中的一种新行为,这就是我以前没有它的原因。

【讨论】:

  • 在 Windows 8/2012 及更高版本上自动化 Word 需要 64 位版本的 Office。然后,在完成所有棘手的 DCOM/IIS 设置之后,您必须准备好让 Word 通过对话框等待答案。我建议,万一失败,你枚举winword进程的窗口并转储标题。它可能会给你一个关于哪里出了问题的线索。您可能还必须杀死虚拟实例。
【解决方案2】:

我在 Windows Server 2016 和 Office 2013 上使用 Office 互操作的旧代码遇到了完全相同的错误,这让我发疯了。因此,首先我想加入那些已经提到最佳实践是不使用它并将您的代码重写为 DocX 或类似的人,如果您有任何机会。只是有太多的陷阱会消耗时间。

我遵循了 Vladimir 帖子的所有提示,但仍然出现错误。毕竟是项目Office的doc文件模板无法以互操作模式打开(但在服务器上的RD会话中打开没有任何问题)。它们是在较旧的 Office 版本中创建的。我在 Word 中打开/保存了一次模板,一切正常。

【讨论】:

    猜你喜欢
    • 2013-12-13
    • 2016-12-17
    • 1970-01-01
    • 2016-10-10
    • 2021-09-28
    • 2018-11-27
    • 2016-11-27
    • 2017-11-13
    • 2020-01-09
    相关资源
    最近更新 更多