我们有一个应用程序已经存在一段时间并使用Excel Interop库。该项目引用Microsoft.Office.Interop.Excel，它指向Visual Studio中的默认路径。
最近我被要求基于Word互操作为这个项目添加一些功能。这一切都很顺利。我在同一位置添加对Word interop dll的引用（C：\ Program Files（x86）\ Microsoft Visual Studio 12.0 \ Visual Studio Tools for Office \ PIA \ Office15）。
Word和Excel都安装在服务器上。但是，当Excel互操作继续运行时，尝试使用Word函数会引发此错误：
System.Runtime.InteropServices.COMException（0x80040154）：由于以下错误，检索CLSID为{000209FF-0000-0000-C000-000000000046}的组件的COM类工厂失败：80040154未注册类（HRESULT异常： 0x80040154（REGDB_E_CLASSNOTREG））。
对此错误的引用表明它是由于32/64位冲突引起的，我觉得这很令人惊讶。 dll是32位，项目构建目标是＆＃34;任何CPU＆＃34;。此外，它还可以毫无怨言地运行32位Excel互操作。
据我所知，Excel上的Word都没有在服务器的注册表中安装interop dll。
这里给出了什么？这真的是建筑不匹配吗？如果没有，为什么我的应用程序能够使用已安装的Excel互操作但不能使用Word？
答案 0 :(得分：1)
Interop文件不应该在服务器上注册，它们不是COM服务器。相反，我建议重新安装Office应用程序（修复它们）以确保COM服务器的所有必需的Windows注册表项都是在您尝试自动化时创建并存在的。
否则，您遇到了一个众所周知的问题...... Microsoft目前不建议也不支持从任何无人参与的非交互式客户端应用程序或组件（包括ASP，ASP）自动化Microsoft Office应用程序。 NET，DCOM和NT服务），因为Office在此环境中运行时可能会出现不稳定的行为和/或死锁。
如果要构建在服务器端上下文中运行的解决方案，则应尝试使用已为安全无人值守执行的组件。或者，您应该尝试找到允许至少部分代码在客户端运行的替代方法。如果从服务器端解决方案使用Office应用程序，则应用程序将缺少许多成功运行的必要功能。此外，您将承担整体解决方案稳定性的风险。请在Considerations for server-side Automation of Office文章中详细了解相关内容。
作为一种可能的解决方法，您可以考虑使用Open XML SDK或仅为服务器端执行而设计的任何其他第三方组件。
答案 1 :(得分：1)
这是一个难题，因为Microsoft不支持该方案。参考：Considerations for the server-side automation of office。
尝试更改＆＃34;嵌入互操作类型＆＃34;的设置在参考Office库的属性中。这使代码独立于任何特定应用程序版本的PIA，并且可以解决服务器端安装的任何问题。
PInvoke（GetType.InvokeMember）也使解决方案独立于应用程序版本，并且可以在整个过程中使用它。但是，这是更多的工作，因为你没有得到智能感知。
这种嵌入互操作类型存在一些已知问题，因为有几个＆＃34;打嗝＆＃34;嵌入式互操作类型如何嵌入信息（与PIA的构建方式不同）。在这种情况下，可能需要将PInvoke用于问题方法/属性。这两种方法可以结合起来。