使用.Net互操作（使用TlbImp生成）时，我的COM对象拒绝在代理（dllhost）中执行

这很奇怪

我们有一些托管C++（一个程序集），它使用TLBIMP生成的.NETCOM互操作DLL来调用COM对象。当我们注册COM DLL时，我们指定希望它在代理中执行（“DLLSurrogate”注册表项）

我们的COM DLL是64位的，在64位平台上执行

当我们将程序集与32位应用程序（其中包含托管和非托管代码）集成到COM库时，调用将在DllHost中执行。同一应用程序的64位构建导致调用在调用进程中执行

纯非托管客户端应用程序（32位和64位）在64位系统上正确执行，这表明（我希望）我们已经正确配置/安装了COM库

此行为可能表示.NET COM互操作正在忽略注册表中的配置信息。32位客户端无法将64位COM DLL加载到其地址空间中，并且默认使用代理？无论如何，这种行为对我们来说是灾难性的，因为COM库包含一个表示访问某些硬件的单例，并且可能有许多客户端进程

以前有没有人注意到这种行为

谢谢

---

Mike D

这是一个奇怪的请求，几乎总是相反；试图从64位代码使用32位COM服务器。如果您有一个32位的服务器构建，那么一定要在进程中使用它，这比进程外代理更高效、更容易操作

64位版本的Windows上的注册表是针对32位应用程序虚拟化的。所有32位COM注册都存储在HKLM\Software\WOW6432节点中。使用Regedit.exe验证COM服务器注册是否确实存在

---

COM服务器的代理/存根DLL也可能有问题。因为您的服务器运行在另一个进程中，所以需要它们。请确保以32位和64位版本构建这些DLL，并使用正确版本的Regsvr32.exe注册它们，谢谢。一切正常。我们已经使用COM服务器很多年了，32位和64位非托管客户端访问64位服务器。这是一个全新的.Net互操作层，给我们带来了痛苦。我们需要用尽进程来实现我们的单例模式。COM对象访问的驱动程序需要64位客户端，因此需要64位COM服务器。