并行模拟进程外ActiveX 我们正在适应客户机相对复杂的应用程序（ActiveX／.NET/Delphi／C++／COM），使用SXS实现非管理部署和与我们产品的旧版本隔离。

我们能够为几乎所有的进程内组件（如.net ui、Delphi ui和我们在进程中使用的COM服务器）实现这一目标，方法是编写一个清单文件，该文件描述了我们进程使用的所有库，而没有在客户端注册任何组件（几乎）

接下来是几乎所有的部分： 目前，我们的应用程序（从它的C++部分）调用了一个OPROC ActiveX服务器（Delphi ActiveX Exe），而它本身又调用另一组OPro ActiveX服务器（第三方插件，任何东西都在这里，Delphi，C++，只要它不在PROC ActiveX EXE中，实现我们的接口）。 SxS不支持进程外ActiveX服务器。我们不能像在主进程中的proc com服务器那样使用这些对象，因为这需要对我们的应用程序进行重大重写，甚至最糟糕的是，需要中断第三方工具和供应商使用的面向公众的API，这是我们不允许的API中断

我们偶然发现了一个描述如何从运行在单独进程中的Internet Explorer窗口中提取IHTMLDocument2的方法。这让我们想到了这种方法：

我们将创建一个辅助卫星应用程序/进程，它将在进程服务器中运行ActiveX。 然后，我们将使用和将ActiveX对象的引用从卫星应用程序传输到主应用程序进程。卫星应用程序将有自己的清单文件，允许它在SxS模式下运行

此Delphi ActiveX EXE和第三方AciveX EXE插件之间的通信将采用相同的方法

还有一种替代解决方案，目前我们不喜欢上面提出的解决方案，即使用.net远程处理和.net com代理类打开两个进程之间的通信通道，方法是将com请求转换为.net远程处理，然后在第二个进程上返回com

所以问题来了：

你认为这种方法怎么样

你认为这个问题有更好的解决办法吗

---

这是可能的。所需：

• 应用程序需要自己启动服务器，而不是依赖COM来启动。您不需要注册表提供的额外间接寻址，只需使用CreateProcess（）
• 服务器应使用CoRegisterClassObject（）在其main（）方法中注册其类工厂
• 重要提示：它用于每个工厂的CLSID应该更改为对于每个服务实例是唯一的。这可确保客户端连接到正确的服务器。我只是将进程ID与类工厂CLSID进行异或。客户机也知道进程ID，因此可以进行相同的更改
• 应用程序应该在循环中使用Sleep（）调用调用CoCreateInstance（），以等待对象工厂出现。在至少60秒过去之前不要宣布失败（这对我来说太麻烦了）
• 应用程序和服务器都需要一个清单，其中包含每个代理/存根DLL的
  元素和每个远程接口的
  元素
亚历克斯
nobugz是对的，您可以访问Running Object表，从当前运行的Delphi automation exe进程创建COM对象的实例
然而，我发现了一个我无法解释的大问题。当以这种方式工作时，我只能通过variant dispatch方法访问对象
基本上，如果我的Active X exe未注册，如果我尝试通过接口实例对象，则会出现“接口不受支持”错误，例如：
网络更新：信息自动化

---

WebUpdate:=协同自动化。创建；如果我错了，请纠正我，但你的提议没有像我建议的那样使用ObjectFromLresult，对吗？关于CoreRegisterClassObject，它在哪里注册，如果它没有在注册表中注册，即使它在清单中，我的应用程序如何使用CoCreateInstance找到它？它没有。CoCreateInstance（）将在正在运行的对象表中找到它。非常感谢，如果没有您的帮助，它将使我无法正常工作。我在转换到实现的接口时遇到问题，我在转换操作HRESULT:0x80004002（E_NOINTERFACE）时遇到此错误。这没有意义，因为我的对象实现了相关接口，我可以通过反射从客户端应用程序按名称访问接口的方法，有什么想法吗？这可能与使用.net实现的客户端和服务器有关，我不是Delphi方面的专家，但据我所知，Delphi com框架与注册表中实际注册的内容以及类型库中存在的内容（特别是运行代码的类型库）具有高度耦合，因此它在使SX无效方面非常有效。但这只适用于接口，而不适用于对象。通过将接口和类型库（而不是coclass）的ROT和相对注册结合起来，我们可以绕过这个限制。相对的意思是，在注册表中，我们不放置库的整个路径，而只放置。\libName.dll，这样每个进程都可以在自己的文件夹中找到libName.dll。libName.dll甚至可以是进程本身，因此您可以在代码中引用自己的接口，而无需担心。