Excel 的不同 excel CLSID 导致 C# 程序中的 Interop 出现问题
Different excel CLSID's for Excel cause issues with Interop in C# program
基本上我只需要知道这两个 CLSID 之间的区别。我有服务器，全新安装，新映像与办公室。在 Excel 应用程序下的 DCOM 中，我的 APPID 为 {00020812-0000-0000-C000-000000000046}。我已经为此 AppID 设置了特定的身份和启动权限。
当我 运行 我的应用正在转换 Excel 文件时，我得到：
Error: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password.
我查了那个 CLSID ID，它也是一个 Excel 应用程序 GUID。这不是 DCOM 中列出的内容。所以我认为我在这里有冲突？可能不同版本的 office 或 x86 与 x64 archs 在同一个盒子上相互竞争？我不确定我应该如何在 {00024500-0000-0000-C000-000000000046} 上设置身份用户，因为它不是 DCOM 中列出的用户。我环顾四周，但没有发现太多关于这个问题的信息。任何帮助将不胜感激。
修复此问题的小更新！！！！
虽然我愿意接受下面的答案，因为互操作对于基于服务器的自动化来说很糟糕 applications/services。我知道这是真的。事实证明，在我的案例中，我从某个地方得到了一个糟糕的 dcomperm.exe 实用程序。我在安装 Windows 7 .NET 4.0 SDK 时遇到了问题，所以我没有解决这个问题，而是从某个地方的 Web 上获取了一个已编译的 DcomPerm。馊主意。今天早上我找到了解决 SDK 安装问题的方法。然后我能够从 SDK 参考 (C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\com\fundamentals\dcom\dcomperm) 编译我自己的 DcomPerm.exe 工具。这个工具奏效了。没有更多的身份错误。
我也没有在使用旧的 DcomPerm 工具时遇到错误，但不知何故它没有正确连接所有内容。显然，Interop 是一种敏感的非企业解决方案，这一切都是有道理的。
您需要使用专为服务器端执行而设计的组件（例如，Aspose 提供的）或者在打开 XML 文件（.xslx）的情况下仅使用 Open XML SDK等），请参阅 Welcome to the Open XML SDK 2.5 for Office 了解更多信息。
正如之前评论中提到的，Microsoft 目前不建议也不支持从任何无人值守的非交互式客户端应用程序或组件（包括 ASP、ASP.NET、DCOM 和 NT 服务），因为当 Office 在此环境中 运行 时，Office 可能表现出不稳定的行为 and/or 死锁。
如果您正在构建 运行 在服务器端上下文中的解决方案，您应该尝试使用已针对无人值守执行安全设置的组件。或者，您应该尝试找到至少允许 运行 客户端部分代码的替代方案。如果您从服务器端解决方案使用 Office 应用程序，该应用程序将缺少许多 运行 成功所必需的功能。此外，您将承担整体解决方案稳定性的风险。
基本上我只需要知道这两个 CLSID 之间的区别。我有服务器，全新安装，新映像与办公室。在 Excel 应用程序下的 DCOM 中，我的 APPID 为 {00020812-0000-0000-C000-000000000046}。我已经为此 AppID 设置了特定的身份和启动权限。
当我 运行 我的应用正在转换 Excel 文件时，我得到：
Error: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password.
我查了那个 CLSID ID，它也是一个 Excel 应用程序 GUID。这不是 DCOM 中列出的内容。所以我认为我在这里有冲突？可能不同版本的 office 或 x86 与 x64 archs 在同一个盒子上相互竞争？我不确定我应该如何在 {00024500-0000-0000-C000-000000000046} 上设置身份用户，因为它不是 DCOM 中列出的用户。我环顾四周，但没有发现太多关于这个问题的信息。任何帮助将不胜感激。
修复此问题的小更新！！！！
虽然我愿意接受下面的答案，因为互操作对于基于服务器的自动化来说很糟糕 applications/services。我知道这是真的。事实证明，在我的案例中，我从某个地方得到了一个糟糕的 dcomperm.exe 实用程序。我在安装 Windows 7 .NET 4.0 SDK 时遇到了问题，所以我没有解决这个问题，而是从某个地方的 Web 上获取了一个已编译的 DcomPerm。馊主意。今天早上我找到了解决 SDK 安装问题的方法。然后我能够从 SDK 参考 (C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\com\fundamentals\dcom\dcomperm) 编译我自己的 DcomPerm.exe 工具。这个工具奏效了。没有更多的身份错误。
我也没有在使用旧的 DcomPerm 工具时遇到错误，但不知何故它没有正确连接所有内容。显然，Interop 是一种敏感的非企业解决方案，这一切都是有道理的。
您需要使用专为服务器端执行而设计的组件（例如，Aspose 提供的）或者在打开 XML 文件（.xslx）的情况下仅使用 Open XML SDK等），请参阅 Welcome to the Open XML SDK 2.5 for Office 了解更多信息。
正如之前评论中提到的，Microsoft 目前不建议也不支持从任何无人值守的非交互式客户端应用程序或组件（包括 ASP、ASP.NET、DCOM 和 NT 服务），因为当 Office 在此环境中 运行 时，Office 可能表现出不稳定的行为 and/or 死锁。
如果您正在构建 运行 在服务器端上下文中的解决方案，您应该尝试使用已针对无人值守执行安全设置的组件。或者，您应该尝试找到至少允许 运行 客户端部分代码的替代方案。如果您从服务器端解决方案使用 Office 应用程序，该应用程序将缺少许多 运行 成功所必需的功能。此外，您将承担整体解决方案稳定性的风险。