将COM接口添加到现有应用程序（EXE） 我打算向现有的应用程序添加一个COM接口（顺便说一下，用Win32用C++编写）。我有一些使用COM对象的经验，所以我知道接口等的基本COM概念，但这是我第一次真正实现组件

最终，我希望能够使用COM接口从脚本（如VB）自动化我的应用程序。我知道有两个步骤：

我的应用程序必须充当进程外服务器（即，我必须使用MIDL并为代理DLL和存根DLL生成代码）

一旦我拥有了服务器，我就可以通过实现IDispatch接口来添加自动化功能

由于服务器与MIDL的EXE连接已经有点困难了，所以我想在转到IDispatch之前先了解一下这一切

我正在阅读Dale Rogerson的书“Inside COM”，并且已经完成了关于EXEs服务器的一章（下一章将介绍自动化）

“EXEs中的服务器”一章提供了实现服务器和客户机的示例代码。但是需要手动启动服务器。这使我困惑。显然，当客户端进程使用我的应用程序（=服务器）时，不需要执行此额外的手动步骤。是否没有自动启动服务器的机制或者自动化是实现这一点所必需的？目前，必须手动启动服务器（一旦我有了服务器）的前景让我怀疑我是否朝着正确的方向前进

---

希望对此有更多了解的人能看到我缺少的信息，并为我指出正确的方向。

不，COM服务器通常不是手动启动的。我不知道这本书为什么要提出它，可能是因为它想避免谈论允许COM自动启动EXE所需的注册表项。这不是很复杂，您可以使用LocalServer32键值注册应用程序的应用程序类，该键值给出EXE的路径

---

然而，这并非完全不常见，尤其是在现有的程序中。要做的一个设计决策是，是否让客户机代码完全控制您的程序。或者，如果您的程序已经有一个现有的用户界面，但您还想向其他代码公开服务。在后一种情况下，让用户像平常一样手动启动应用程序是有意义的。

当您的应用程序注册为

LocalServer32

时，如果还没有运行的进程为您的CLSID注册工厂对象，则将使用此处指定的命令行调用该应用程序

通过这种方式，您可以两全其美——如果应用程序已经在运行，这个实例可以提供服务器端，如果没有，它将被启动

自动化与此完全正交——您的组件通过实现

IDispatch

实现自动化兼容