来自 COM 经验的八个教训

核心提示： 此问题似乎与安全有关，当处理远程激活请求的 COM 服务控制管理器 (SCM) 在另一台机器上启动一个进程时，来自 COM 经验的八个教训(7)，它会为该进程分配一个标识，除非另外指定，并将“launching user ”更改为“This user&r

此问题似乎与安全有关。当处理远程激活请求的 COM 服务控制管理器 (SCM) 在另一台机器上启动一个进程时，它会为该进程分配一个标识。除非另外指定，它选择的标识就是启动用户的标识。换句话说，分配给服务器进程的标识与启动它的客户端进程的标识相同。在这种情况下，如果 Bob 登录机器 A，并使用 CoCreateInstanceEx 连接机器 B 上的 Singleton 对象，而 Alice 也在机器 C 上如法炮制，就会启动两个不同的服务器进程（至少在两台不同的 WinStation 上），实际上使客户端无法再用 Singleton 语义与共享的对象实例连接。

两个测试场景之所以会产生大相径庭的结果，其原因就是在一个场景（那个可以工作的场景）中，所有测试人员都使用只为测试而设置的一个特殊帐户以同一个人的身份登录。而在另一个场景中，测试人员都使用他们的普通用户帐户登录。当两个或更多的客户端进程具有相同标识时，它们可以成功连接到配置为假定启动用户标识的服务器进程。但是，如果客户端有不同的标识，SCM 会使用多个服务器进程（每个唯一客户端标识一个）分隔分配给不同对象实例的标识。

图 1 DCOMCNFG 中的用户帐户

找到问题以后，解决起来就很简单了：配置 COM 服务器，让其使用特定的用户帐户而不是假定启动用户的标识。完成这一任务的一种方式是在服务器机器上运行 DCOMCNFG（Microsoft 的 DCOM 配置工具），并将“launching user ”更改为“This user”（请参见图 1）。如果您喜欢通过编程方式进行更改（可能从安装程序着手），请在主机注册表的 HKEY_CLASSES_ROOT\AppID 部分的 COM 服务器项中添加 RunAs 值（请参见图 2）。