问题标签 [dcom]

我正在使用两台机器上的服务器和客户端处理 DCOM 应用程序，这两台机器都运行带有 Service Pack 2 的 WinXP。在两台机器上，我都使用相同的用户名和密码登录。

当一台机器上的客户端调用 CoCreateInstanceEx，要求另一台机器启动服务器应用程序时，它返回 E_ACCESSDENIED。

我尝试在 dcomcnfg 中进入服务器应用程序的组件属性，并为所有人提供所有权限，但这并没有帮助。

我需要做什么才能让这个调用成功？

更新：当服务器应用程序在 Windows 2000 机器上运行时，我没有收到此错误；CoCreateInstanceEx 返回 S_OK。

.net 框架的引入是否使 COM 和 DCOM 中的原始编程变得多余？

（除了使用一些 COM+ 服务，例如通过 System.EnterpriseServices 命名空间进行事务管理）

我在一个应用程序上工作，它使用 DCOM 在本质上是几个对等点之间进行通信；在正常使用过程中，不同机器上的实例为彼此提供各种对象。从历史上看，为此我们使用了一些魔法咒语，其中主要是在每台机器上，用户必须登录到同名的帐户（请注意，这些是本地帐户；没有可用的域）。显然，这是我们可以改进的用户体验的一个方面。

我想更好地了解 DCOM 身份验证的工作原理，但是我很难从 MSDN 文档中为CoInitializeSecurity()、CoSetProxyBlanket()等组装整个故事。对于 DCOM 操作是如何被接受或拒绝的，是否有任何详尽的解释？书籍、期刊、网络，任何格式都可以。

我希望每个人都能原谅这个问题的长度和叙述方式。我决定在我的博客中详细描述一下这种情况。后来我看到乔尔对这个网站的邀请，我想我会把它贴在这里看看是否有人对这种情况有任何见解。

我编写了一个应用程序，现在支持一个应用程序，该应用程序包含一个 Visual Basic 胖客户端，它将 DCOM 与使用 ATL 用 C++ 编写的中间层 COM+ 组件进行通信。它在我们所有的八个办公室中运行。每个办公室都有一个后端服务器，其中包含 COM+ 应用程序（由 18 个独立的组件组成）和 SQLServer。SQLServer 通常位于同一后端服务器上，但不一定如此。

我们最近将我们最大的办公室——纽约——的后端服务器从一个 MSC 集群迁移到了一个托管在 VMWare 的 ESX 技术上的新虚拟机。由于 COM+ 应用程序的位置已从旧服务器移动到具有不同名称的新服务器，因此我必须重定向所有客户端，以便它们在新服务器上激活 COM+ 应用程序。该程序是旧帽子，因为我对经历过类似基础设施升级的几个较小的办公室做了基本相同的事情。

一切看起来都很正常，周一早上，整个办公室——大约 1,000 台 Windows XP 工作站——都在新服务器上顺利运行。但随后电话来自我的移动组——有一位在家工作的律师使用 VPN 连接，在被重定向到新服务器后出现奇怪的错误：

嗯？我以前从未见过此错误消息。是新服务器吗？但是办公室里的所有工作站都工作正常。我告诉移动组将律师切换回旧服务器（仍在运行），错误消失了。那么有什么区别呢？原来这位律师正在家里运行 Vista。

我们的任何办公室都没有运行 Vista，但我们确实有一些在家里运行 Vista 的律师（当然有些在我的纽约办公室）。我也这样做，我从未见过这个问题。为了确认存在问题，我启动了我的 Vista 笔记本电脑，将其指向新服务器，并得到了同样的错误。我将它指向旧服务器，它运行良好。显然，Vista 和新服务器上的组件存在一些问题——这个问题似乎不会影响 XP 客户端。会是什么呢？

下一站——我的笔记本电脑上的应用程序错误日志。这产生了有关错误的更多信息：

界面 ID 提供了我解开谜团所需的线索。“预期”接口 id 标识 MDAC 的 Recordset 接口——特别是该接口的 2.1 版。“返回”接口对应于 Recordset 的更高版本（2.5 版与 2.1 版的不同之处在于在 vtable 的末尾包含了一个附加条目——方法 Save）。

实际上，我的组件接口公开了许多将 Recordset 作为输出参数传递的方法。那么他们是否突然返回了更高版本的 Recordset —— 具有不同的接口 ID？显然情况确实如此。然后我想，这有什么关系。对于旧接口的客户端，vtable 看起来是一样的。事实上，我怀疑如果我们谈论的是进程内 COM，而不是 DCOM，这种看似无害的阻抗失配会被默默地忽略，不会造成任何问题。

当然，当进程和机器边界发挥作用时，客户端和服务器之间存在代理和存根。在这种情况下，我将类型库编组与自由线程编组器一起使用。所以有两个谜团需要解开：

为什么我在新服务器上的方法的输出参数中返回了不同的接口？

为什么这只会影响 Vista 客户端？

由于我的服务器软件托管在我的八个办公室的每个服务器上，我决定尝试按顺序将我的 Vista 客户端指向所有这些办公室，以查看哪些与 Vista 有问题，哪些没有。光照测试。一些较旧的服务器仍可与 Vista 一起使用，但较新的服务器则不能。尽管一些较旧的服务器仍在运行 Windows 2000，而较新的服务器在 2003 年，但这似乎不是问题。

在比较了组件 DLL 的日期之后，似乎每当客户端指向具有 2003 年之前的组件 DLL 的服务器时 Vista 都可以。但是那些拥有日期在 2003 年之后的 DLL 是有问题的。信不信由你，多年来，服务器组件上的代码没有（或至少没有重大）变化。显然，不同的日期仅仅是由于在我的开发机器上重新编译了我的组件。似乎其中一个重新编译发生在 2003 年。

灯泡亮了。在将记录集从服务器传回客户端时，我的 ATL C++ 组件将接口称为 _Recordset。此符号来自嵌入在 msado15.dll 中的类型库。这是我在 C++ 代码中的行：

不要被msdad15.dll中的15个骗了。显然，这个 DLL 在长系列的 MDAC 版本中没有更改名称。

那天我编译应用程序时，MDAC 的版本是 2.1。所以 _Recordset 使用 2.1 接口 id 编译，即运行这些组件的服务器返回的接口。

所有客户端都使用 1999 年生成（我相信）的 COM+ 应用程序代理。定义我的接口的类型库包括以下行：

这解释了为什么他们希望在我的方法的输出参数中使用 Recordset 2.1 版。很明显，问题出在我 2003 年的重新编译上，而且当时 _Recordset 符号不再对应于 2.1 版。实际上 _Recordset 对应于 2.5 版本，其接口 id 不同。我的解决方案是在我的 C++ 代码中将所有引用从 _Recordset 更改为 Recordset21。我重建了组件并将它们部署到新服务器。瞧——客户似乎又高兴了。

总之，有两个困扰我的问题留给我。

为什么代理/存根基础结构似乎与 Vista 客户端的行为不同？与 XP 相比，Vista 似乎对从方法参数返回的接口 ID 进行了更严格的检查。

我应该如何在 1999 年以不同的方式对此进行编码，以免发生这种情况？接口应该是不可变的，当我在较新版本的 MDAC 下重新编译时，我无意中更改了我的接口，因为这些方法现在返回了不同的 Recordset 接口作为输出参数。据我所知，当时的类型库没有特定于版本的符号——也就是说，更高版本的 MDAC 类型库定义了 Recordset21，但该符号在 2.1 类型库中不可用。

我可以使用 DCOMCNFG 在我的 DCOM 应用程序上禁用远程启动，但我想以编程方式执行此操作。我查看了 CoInitializeSecurity，但似乎并没有这样做。有人做过吗？

我正在使用德尔福顺便说一句。

我在 DCOM Config 中有一个组件，其“本地路径”（在 dcomcnfg 中该组件的“属性”页面的“常规”选项卡上）指向错误的位置。但是，当我转到该目录并使用“componentname.exe /unregserver”取消注册组件时，该组件的本地路径保持不变。

我还尝试使用“componentname.exe /regserver”转到正确的目录并在那里注册组件，但“本地路径”中的值仍然没有改变。

有什么建议么？

我有一个 VB6 dll 正在尝试使用以下代码行创建一个 COM 对象：

但是，这会失败并出现错误“对象变量或未设置块变量”。

我可以在 dcomcnfg 中看到 OPSValuer.OPSValue 并且它似乎注册得很好。有没有人对可能导致问题的原因有任何想法？

问题真的说明了一切......

我尝试更改属性页上的“允许非管理员用户运行此程序”设置，并且还为有问题的非管理员用户提供了组件服务-> DCOM 配置中的正确权限。

还有什么我可以做的吗？

这是在 Server2003 顺便说一句。

谢谢

马特

我已经导出了一个 COM+ 应用程序代理，它可以生成 MSI 和 CAB 文件，并且我已经成功地将它们安装在几个不同的 Win XP 和 Vista 机器上。但是，我有一个不能很好玩的 WinXP 机器。当我尝试运行 MSI 时，它给了我以下错误消息：

“注册 COM+ 应用程序时出错。”

它停在那里，甚至没有达到在 COM+ 中创建应用程序的程度。关于在哪里看的任何想法？我猜某些依赖项是 MIA、禁用或配置错误，但我似乎无法弄清楚魔术酱中缺少什么。

此外，如果你们中的任何人有手动注册客户端应用程序代理的经验，那也会很好。

和平|露水

我可以找到各种关于如何为 DCOM 编程的东西，但几乎没有关于如何以编程方式设置/检查安全性的内容。

我不是要重新创建 dcomcnfg，但如果我知道如何在 C#（首选或 VB.net）中重现 dcomcnfg 的所有功能，那么我的目标就在眼前。

我似乎无法在这方面找到任何好的资源，没有开源 API，甚至没有关于如何执行每个步骤的快速示例。即使在这里 DCOM 或 dcomcnfg 返回的结果很少，也没有真正关于如何设置/验证/列出安全性。

如果有人有一些指向开放 API 或一些示例的指针，我将不胜感激。