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