我有一个进程外com服务器，指定CLSCTX_LOCAL_SERVER作为上下文，并指定REGCLS_MULTIPLEUSE作为连接类型。这导致单个服务器进程被多个客户端的多个调用重用。
我现在想要对服务器进行一些更改，遗憾的是，这些更改无法与客户端共享的单个进程一起工作（有这样的原因，但是它们已经很长时间了）。我知道您可以将服务器设置为使用REGCLS_SINGLEUSE作为连接类型，这将为每次调用的OOP服务器创建一个新进程。这解决了我的问题，但在流程使用方面是不起作用的;短时间内的多次呼叫会导致许多进程，并且这种特定的服务器可能会经常遭受重击。
有没有人碰巧知道混合这两种连接类型的机制？基本上我想要的是每个调用进程一个服务器进程。 （即，客户端1创建一个进程，该进程被重用于该客户端的后续调用。客户端2尝试调用服务器，并创建一个新进程）。我怀疑我可以通过强制REGCLS_SINGLEUSE服务器在客户端永久保持打开来实现它，但这既不优雅也不可能（因为我无法更改其中一个客户端）。
思想？
更新 正如所料，似乎没有办法做到这一点。如果时间和资源允许，我很可能将其转换为In-Proc解决方案。但就目前而言，我不得不采用任何调用客户端所使用的新行为。幸运的是，这种变化的影响非常小，并且客户可以接受。我稍后会研究更激烈和适当的变化。
注意 我已经将Hans的回复标记为答案，因为事实上它确实解决了维护OOP解决方案的问题。我只是没有能力实施它。
卡
答案 0 :(得分：5)
COM不支持此激活方案。它应该由进程内服务器覆盖，确保这不是您想要的方式，因为它具有相当大的优势。
使用REGCLS_SINGLEUSE是另一种选择，但这需要您扩展对象模型以避免现在创建的服务器实例风暴。 Application coclass是样板方法。为它提供工厂方法，为您提供现有接口的实例。
我会提到一种截然不同的方法，一种是在我想解决相同问题时使用的方法，但需要进程外服务器以利用桥接位差。您不会因为COM为您启动服务器进程而烦恼，客户端也可以启动它。当然，它提供了足够的关于服务器安装位置的信息。现在客户端当然可以完全控制服务器实例。服务器调用了CoRegisterClassObject（），其中包含一个已更改的CLSID，这是带有进程ID的guid的一部分。客户端也这样做，所以它始终与正确的服务器连接。客户端需要额外的代码以确保它等待足够长的时间以使服务器有机会注册其对象工厂。工作得很好。