基于ASP.NET的Word自动化

我有一个在asp.net中使用Microsoft Word automation的旧应用程序，我需要将其安装在Windows Server 2012 R2 x64上，并使用Office 2013标准x86。我知道像IIS这样的服务器技术中的办公自动化应该避免，但我目前没有重写应用程序的绿灯，所以我不得不照原样去做

最初我启动应用程序时，它出现以下错误：

由于以下错误，检索CLSID为{000209FF-0000-0000-C000-0000000000 46}的组件的COM类工厂失败：80070005访问被拒绝。（来自HRESULT的异常：0x80070005（E_ACCESSDENIED））

我在网上找到了一些信息，{000209FF-0000-0000-C000-0000000000 46}是泛型词的标识符，没有具体的版本

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

由于以下错误，检索CLSID为{000209FF-0000-0000-C000-0000000000 46}的组件的COM类工厂失败：80080005服务器执行失败（HRESULT异常：0x80080005（CO_E_服务器执行失败））

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

服务器{000209FF-0000-0000-C000-0000000000 46}未在要求的超时时间内向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标识中设置特定用户（本地管理员），但没有更改

现在我恢复了所有权限，我又回到了0x80005错误，因为它至少给了我一些信息来尝试使用

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

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/>");
}

试试看
{
l1.Text=System.Security.Principal.WindowsIdentity.GetCurrent（）.Name；
var application=new Microsoft.Office.Interop.Word.application（）；
l2.Text=“确定”；
}
捕获（例外情况除外）
{
this.Label2.Text=ex.ToString（）.Replace（“\r\n”和“
”）；
}

它在使用Office 2013 Pro x64的Windows 8 x64上也会失败，错误与此完全相同

如果我将当前用户模拟为管理员，则它可以工作。但是，即使将IIS APPPOOL\DefaultAppPool添加到administrators组，它仍然失败

---

对下一步有什么想法吗？

所以这就是最后的工作：

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

---

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

我在Windows Server 2016和Office 2013上使用Office Interop时遇到了与旧代码完全相同的错误，这让我发疯。因此，首先我想加入那些已经提到的人，最好的做法是不使用它，如果有机会的话，将代码重写为DocX或类似的代码。它只是有太多的陷阱来消耗时间

---

我遵循了弗拉基米尔邮报的所有提示，但仍然得到了错误。毕竟，project Office的文档文件模板未能在互操作模式下打开（但在服务器上的RD会话中打开时没有任何问题）。它们是在较旧的Office版本中创建的。我在Word中打开/保存了一次模板，一切正常。

首先让apppool完全访问所有内容。如果这样做行得通，你至少知道你正朝着正确的方向努力，需要弄清楚它需要什么特定的权限。因此，我尝试在默认情况下为每个人（在我的计算机中）提供对所有COM组件的完全访问权限，但它仍然不起作用。您提到的另一个问题使用了Word的另一个版本-我根本没有这些密钥和DCOM。当我遇到此问题时，我成功地将IIS_IUSR和IUSR添加到允许的用户中。如果这对您有效，请尝试如果我是您，我将强烈反对在服务器上使用互操作API。这是灾难的秘诀。请明确，使用互操作库比部分重写应用程序以使用不依赖COM的像样库的成本更高。在Windows 8/2012及更高版本上自动化Word需要64位版本的Office。然后，在完成了所有棘手的DCOM/IIS设置之后，您必须为Word通过对话框等待答案做好准备。我建议