向现有应用程序(EXE)添加COM接口

Question

我打算将COM接口添加到现有的应用程序中(顺便说一句，它是用C++使用Win32编写的)。我有一些使用COM对象的经验，所以我知道接口等的基本COM概念，但这是我第一次实际实现组件。

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

1. 我的应用程序必须充当进程外服务器(即我必须使用MIDL并为代理DLL和存根DLL生成代码)。
2. 一旦我拥有了服务器，我就可以通过实现IDispatch接口来添加自动化功能。

由于使用MIDL的EXE服务器和不太陡峭的东西，我想先了解一下这一切，然后再转到IDispatch。

我正在阅读戴尔·罗杰森( Dale Rogerson )的“内部COM”(Inside COM)一书，并已经完成了关于EXEs中服务器的章节(下一章将介绍自动化)。

“EXEs中的服务器”一章提供了实现服务器和客户端的示例代码。但是有必要手动启动服务器。这让我很困惑。显然，当客户端进程使用我的应用程序(= server)时，这个额外的手动步骤应该是不必要的。没有自动启动服务器的机制吗？还是自动化是实现这一目标所必需的？目前可能需要手动启动服务器(一旦我有了服务器)，这让我怀疑自己是否在朝着正确的方向前进。

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

Answer 1

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

然而，这并不是完全不常见的，特别是对一个现有的程序。要做出的一个设计决定是，是否让客户端代码完全控制您的程序。或者，如果您的程序已经具有现有的用户界面，但也希望将服务公开给其他代码。在后一种情况下，让用户手动启动应用程序是有意义的，就像她通常做的那样。

Answer 2

当您的应用程序注册为LocalServer32时，如果还没有为您的CLSID注册一个工厂对象，则将使用在那里指定的命令行调用它。

这样，您就可以从这两个方面中得到最好的结果--如果应用程序已经在运行，这个实例可以提供服务器端，如果不是，它将被启动。

自动化是完全正交的--您的组件通过实现IDispatch而变得与自动化兼容。