COM方法调用在哪里执行

比方说，我正在执行一个用 c# 编写的 exe（只是我选择的语言）。它有以下一段代码：

var comObj=new ComClass();
comObj.DoSomething();

现在我想知道在哪个过程中DoSomething方法执行。是与当前exe运行的同一个进程还是不同的进程响应DoSomething call?

这在 COM 中是完全透明的，你也无法从你的程序中发现。它由存储在注册表中的配置信息确定。 COM服务器需要注册的核心原因。不同的场景是：

• 在创建对象的同一线程上。当服务器注册为进程内服务器并且线程单元与 COM 对象的线程模型兼容时使用。最常见的情况，尤其是当您在程序的 UI 线程上创建对象时。

• 在另一个线程上，如果需要的话由 COM 创建，为对象提供一个线程安全的家。当您的new语句在 MTA（多线程单元）中的线程上运行。通常来自工作线程。您创建的对象是proxy，它的主要工作是序列化传递给方法的参数并在stub它在另一个线程上运行。它确保对该对象的所有调用都是线程安全的。否则，与 .NET Remoting 中使用的机制相同。负责封送处理的底层是 LRPC，这是一个不起眼的 Windows 组件，经过优化以尽可能快地进行线程间和进程间调用。

• 里面一个代理人进程内组件的进程。不太常见，但代理可以非常方便地解决例如进程位数问题。允许您在 64 位进程中使用 32 位服务器。需要 32 位和 64 位代理/存根。

• 在另一个注册为进程外服务器的进程内。典型的示例是 Microsoft Office 程序（例如 Word 和 Excel），它们在 .NET 编程中非常常见。这就是 COM 开始变得脆弱的地方，当服务器继续运行时，意外的程序中止往往会导致混乱。 AverySO 的常见问题。

• 在另一台机器上的另一个进程内。称为 DCOM 或分布式 COM。需要额外的配置步骤来确保可以选择目标计算机和正确的帐户权限。它因让人类头疼而臭名昭著，现在已经不再使用了。 DCOM 最大的名声是让 Java 在 90 年代末的中间件战争中抢走了微软的午餐。

如果您不知道哪些场景适用于您的情况，那么像 SysInternals 的进程监视器这样的实用程序往往会提供洞察力。您将看到您的程序读取注册表，告诉您在哪里查找，并加载 DLL 或启动 EXE。