我正在尝试在运行 Windows 2003 64 位的服务器上使用 C# ASP.NET 进行 Office 2003 互操作（尽管我在 32 位模式下运行 IIS）并收到如下错误消息：
机器默认权限设置不会将具有 CLSID {00024500-0000-0000-C000-000000000046} 的 COM 服务器应用程序的本地激活权限授予用户域\用户名 SID (SXX-XX-XXX-XXXX-XXX-XXXXX) . 可以使用组件服务管理工具修改此安全权限。
有人知道我需要改变什么才能让它工作吗？谢谢，如果你能帮忙。
编辑 - 这在 32 位服务器上运行良好。
编辑 2 - 似乎没有人喜欢这个，但我不确定根据我们的要求还有其他方法。如果您能想到一个，我已经打开了另一个问题替代办公室互操作用于文档生成
从服务器环境调用时，任何 Office 应用程序都不能正常工作。它们的 COM 接口用于桌面自动化，而不是来自服务器应用程序的自动化。你为使它们工作所做的任何事情都将涉及建立在 hack 之上的 hack，并且注定会失败。
这撇开您没有获得从服务器应用程序运行它们的许可这一事实。
更正：知识库文章Office 服务器端自动化的注意事项确实说您获得了 Office 产品服务器端自动化的许可，仅当客户端都获得许可时才能使用：
除了技术问题，您还必须考虑许可问题。当前的许可准则禁止在服务器上使用 Office 应用程序来服务客户端请求，除非这些客户端本身具有 Office 的许可副本。最终用户许可协议 (EULA) 不涵盖使用服务器端自动化向未授权工作站提供 Office 功能。
另一方面，该知识库文章列出了大量从不这样做的理由。它们包括：
我向任何考虑 Office 产品服务器端自动化的人推荐这篇知识库文章。
正如 John Saunders 所说，除了许可问题之外，您不会让 Office 自动化在服务器端正常工作。
查看 OpenXML SDK，您可以利用它来实现相同的最终结果。DocumentReflector 尤其会帮助您解决这个问题。
尝试在更多特权的 Indentity 下运行 AppPool（右键单击 AppPool 并选择 Identity 选项卡）。
我找到了答案。在 regedit 中搜索问题指南。然后，您将遇到一个包含两个值的键——组件的名称和它在组件服务中的 guid。
正如其他人提到的，Microsoft 不支持在服务器环境中使用 COM Interop。
话虽如此，您没有指定您是在谈论 ASP.NET、WinForms、控制台应用程序还是???。如果您构建控制台应用程序并将 Visual Studio 配置管理器中的目标 CPU 设置为 x86 而不是 Any CPU，您可能会发现它会起作用。这将强制您的应用程序在 64 位服务器上以 32 位模式运行。当然，您可能还会遇到许多其他问题，例如权限问题。
SpreadsheetGear for .NET在 W2K3 64 位和 W2K8 64 位环境中经过测试和支持。
免责声明：我拥有 SpreadsheetGear LLC