Office 与 ASP.NET 中的 64 位 Windows 互操作

Question

我正在尝试在运行 Windows 2003 64 位的服务器上使用 C# ASP.NET 进行 Office 2003 互操作（尽管我在 32 位模式下运行 IIS）并收到如下错误消息：

机器默认权限设置不授予具有 CLSID 的 COM 服务器应用程序的本地激活权限 {00024500-0000-0000-C000-000000000046} 到用户域\用户名 SID (S-X-X-XX-XXX-XXXX-XXX-XXXXX)。可以使用组件服务管理工具修改此安全权限。

有人知道我需要改变什么才能让它工作吗？感谢您的帮助。

编辑 - 这在 32 位服务器上运行良好。

编辑 2 - 似乎没有人喜欢这个，但我不确定根据我们的要求还有其他方法。如果你能想到一个，我已经打开了另一个问题alternative-to-office-interop-for-document-generation

Answer 1

尝试在更多特权的身份下运行 AppPool（右键单击 AppPool 并选择身份选项卡）。

Answer 2

从服务器环境调用时，任何 Office 应用程序都不能正常工作。它们的 COM 接口用于桌面自动化，而不是来自服务器应用程序的自动化。你所做的任何试图让它们工作的事情都将涉及建立在 hack 之上的 hack，并且注定会失败。

这忽略了您没有获得从服务器应用程序运行它们的许可这一事实。

---

更正：知识库文章 Considerations for server-side Automation of Office 确实说您获得了 Office 产品服务器端自动化的许可，只有在客户端都获得许可的情况下才能使用：

除了技术问题，您还必须考虑许可问题。当前的许可准则禁止在服务器上使用 Office 应用程序来服务客户端请求，除非这些客户端本身具有 Office 的许可副本。最终用户许可协议 (EULA) 不涵盖使用服务器端自动化向未授权工作站提供 Office 功能。

另一方面，那篇知识库文章列出了大量从不这样做的理由。它们包括：

• 用户身份
• 与桌面的交互性
• 可重入性和可扩展性
• 弹性和稳定性
• 服务器端安全

我向所有考虑 Office 产品服务器端自动化的人推荐这篇知识库文章。

Answer 3

就像 John Saunders 所说，除了许可问题之外，您不会让 Office 自动化在服务器端正常工作。

查看 OpenXML SDK，您或许可以利用它来实现相同的最终结果。 DocumentReflector 尤其会在这方面为您提供帮助。

http://blogs.msdn.com/alspeirs/archive/2008/12/09/generating-documents-with-c-open-xml-and-the-document-reflector.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=c6e744e5-36e9-45f5-8d8c-331df206e0d0&DisplayLang=en

Answer 4

我找到了答案。在 regedit 中搜索问题指南。然后您会遇到一个包含两个值的键 - 组件的名称和它在组件服务中的 guid。

Answer 5

正如其他人提到的，Microsoft 不支持在服务器环境中使用 COM Interop。

话虽如此，您并没有具体说明您是在谈论 ASP.NET、WinForms、控制台应用程序还是 ???。如果您构建控制台应用程序并将 Visual Studio 配置管理器中的目标 CPU 设置为 x86 而不是 Any CPU，您可能会发现它会起作用。这将强制您的应用程序在 64 位服务器上以 32 位模式运行。当然，您可能还会遇到许多其他问题，例如权限问题。

SpreadsheetGear for .NET 在 W2K3 64 位和 W2K8 64 位环境中经过测试和支持。

免责声明：我拥有 SpreadsheetGear LLC