【发布时间】：2016-06-29 14:18:54
【问题描述】：
基本上我只需要知道这 2 个 CLSID 之间的区别。我有服务器，全新安装，与办公室新映像。在 Excel 应用程序下的 DCOM 中，我的 APPID 为 {00020812-0000-0000-C000-000000000046}。我已经为此 AppID 设置了特定的身份和启动权限。
当我运行正在转换 Excel 文件的应用程序时，我得到：
错误：检索 CLSID 为 {00024500-0000-0000-C000-000000000046} 的组件的 COM 类工厂失败，原因是以下错误：8000401a 无法启动服务器进程，因为配置的标识不正确。检查用户名和密码。
我查了那个 CLSID ID，它也是一个 Excel 应用程序 GUID。这不是 DCOM 中列出的内容。所以我认为我在这里有冲突？可能不同版本的 office 或 x86 与 x64 拱门在同一个盒子上相互竞争？我不确定我应该如何在 {00024500-0000-0000-C000-000000000046} 上设置身份用户，因为它不是 DCOM 中列出的用户。我环顾四周，但在这个主题上没有找到太多东西。任何帮助将不胜感激。
关于这个问题的小更新修复！！！！！！
虽然我愿意接受以下答案，因为互操作对于基于服务器的应用程序/服务来说是不好的自动化。我知道这是真的。事实证明，在我的情况下，我从某个地方得到了一个糟糕的 dcomperm.exe 实用程序。我在安装 Windows 7 .NET 4.0 SDK 时遇到了问题，所以我没有解决这个问题，而是从某个地方的网络上获取了一个已编译的 DcomPerm。馊主意。今天早上我找到了解决 SDK 安装问题的方法。然后，我能够从 SDK 参考 (C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\com\fundamentals\dcom\dcomperm) 编译我自己的 DcomPerm.exe 工具。这个工具有效。不再有身份错误。
旧的 DcomPerm 工具也没有出现错误，但不知何故，它并没有正确连接所有东西。显然，Interop 是一种敏感的非企业解决方案，这一切都说得通。
【问题讨论】：
-
您是在服务内部还是在 IIS 内部运行此程序？如果是这样，您可能需要阅读知识库文章“Considerations for server-side Automation of Office”，您可能会遇到很多问题，看起来您正在遇到其中之一。短版本是尽可能切换到 Open XML SDK，它可以读取 xlsx 文件并且没有 COM 互操作的问题。
-
这是一个服务应用程序。我同意，互操作很烂。但就目前而言，它必须留下来。这是主要问题，如果我进入 DCOM，将用户更改为交互式，然后将用户更改回我最初设置服务器的特定用户，我不再收到错误消息。我应该提一下，我最初使用 DcomPerm.exe 来设置身份用户。它似乎工作正常。所以我只是不确定当我在 GUI 中设置用户时和我使用命令行工具以编程方式设置用户时发生了什么。
-
互操作工具需要加载用户配置文件才能运行，更改用户并将其改回会在您改回配置文件后保持加载配置文件。请参阅我链接到的知识库文章中的“用户身份”项目符号。并且提醒您，同样来自该页面“Microsoft 目前不推荐也不支持从任何无人值守、非交互式客户端应用程序或组件（包括 ASP、ASP.NET、DCOM）自动化 Microsoft Office 应用程序和 NT 服务），因为当 Office 在此环境中运行时，Office 可能会表现出不稳定的行为和/或死锁。"
-
您说互操作必须保留，但为什么必须保留？您正在使用Office Open XML SDK 中无法使用的互操作的哪些功能（例如，您是否需要支持 .xls 文件）？如果您可以说明为什么我们可以帮助您找到一种解决方法，使该特定功能可以正常工作，而无需让整个互操作正常工作。
-
这是一个转换工具。 OpenXML 对于 xlsx 和 docx 办公室的东西效果更好。但是我们通过这个转换引擎得到了非常古老的东西。 Word 6.0、Excel 5.0 等。新的互操作库可以读取这些旧版本的 Office。我真的不想在这里为 Interop 辩护，我讨厌它。我现在没有其他解决方案。即使我这样做了，也需要花费大量时间来实施更改并将其发布到我的环境中的生产环境中。但我全神贯注。感谢斯科特的投入！
标签： c# .net excel office-interop dcom