一个out-proc COM服务器最终会在所有情况下都停止使用吗？

Question

我发现了一个out-proc COM服务器实现（假设是由于一个bug），如果客户端调用CoGetClassObject()然后再尝试用检索到的工厂实例化任何东西，服务器进程将永远运行。 COM服务器不是作为服务启动的，而是一个普通的可执行文件。

在描述的场景中，客户端不会调用IClassFactory::LockServer()，因此这个问题是完全忽略那些“服务器锁”。

这是正确的行为吗？如果一个out-proc COM服务器在一段时间内没有服务对象时总是停止，或者是否应该有一个out-proc COM服务器连续运行的情况，即使它不提供任何对象？

Answer 1

Out of process servers and IClassFactory::LockServer()

  

当客户端释放IClassFactory接口时，COM在对IClassFactory接口进行编组时以及使用FALSE对LockServer进行隐式调用时，会向类对象添加一个对TRATE的隐式调用。因此，没有必要将LockServer远程调用回服务器，而LockServer的代理只返回S_OK而不实际远程调用该调用。

该进程应该一直运行，直到类对象被释放为（原始）COM不提供任何类型的超时机制。所以，是的，直到您使用CoGetClassObject（）获取的＆gt; Release（）类对象的接口，服务器进程（托管的dll或exe）将继续运行。该行为与类对象（工厂）创建的类无关，因为它们是单独引用的。

FWIW，检索到的接口也不必是IClassFactory。它可以是某种自定义实现，因此您可以在COM提供的众所周知的接口之外执行操作。我觉得奇怪的是调用CoGetClassObject而不是CoCreateInstance（Ex），因为调用CoGetClassObject（）实际上是一个用于创建多个对象的特殊用途工具。我从未发现自己使用了类对象，或者是monikers，或者是COM支持的其他几十种行为。 DCOM，COM +，OLE，当然，但不是低级原始内容。

Answer 2

我认为该计划是对的。 CoGetClassObject返回一个AddRef'ed接口，如果那不是Release'd，则EXE不应该退出。