从 x64 .NET 访问 x86 COM
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/359331/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Access x86 COM from x64 .NET
提问by Craig Wilson
I have an x64 server which, since my libraries are compiled to AnyCPU, run under x64. We are needing to access a COM component which is registered under x86. I don't know enough about COM and my google searches are leading me nowhere.
我有一个 x64 服务器，因为我的库被编译为 AnyCPU，所以在 x64 下运行。我们需要访问在 x86 下注册的 COM 组件。我对 COM 知之甚少，我的谷歌搜索无处可去。
Question: Can I use a symbolic registry link from x64 back to x86 for the COM component? Do I need to register the COM component under x64 as well? Can I (any statement here...) ?
问题：对于 COM 组件，我可以使用从 x64 返回到 x86 的符号注册表链接吗？我是否也需要在 x64 下注册 COM 组件？我可以（这里有任何声明......）吗？
Thanks.
谢谢。
回答by puetzk
If a component is running x64-native, it can't load a 32-bit COM server in-process, because it's the wrong sort of process. There are a couple of solutions possible:
如果组件正在运行 x64-native，则无法在进程内加载 32 位 COM 服务器，因为这是错误的进程类型。有几种可能的解决方案：
If you can, build a 64-bit version of the COM code (which would of course register itself in the 64-bit registry). This is the cleanest solution, but may not be possible if you don't have the code for the COM server.
Run your .NET component as 32-bit x86, instead of x64. I assume you've already considered and rejected this one for some reason.
Host the COM component out-of-process using the COM surrogateDLLhost.exe. This will make calls to the COM server much, much slower (they will now be interprocess Windows messages instead of native function calls), but is otherwise transparent (you don't have to do anything special).
This probably won't be an option if the server requires a custom proxy-stub instead of using the normal oleaut32 one (very rare, though), since there won't be a 64-bit version of the proxy available. As long as it can use the ordinary OLE marshalling, you can just register it for surrogate activation.
如果可以的话，构建一个 64 位版本的 COM 代码（当然它会在 64 位注册表中注册自己）。这是最干净的解决方案，但如果您没有 COM 服务器的代码，则可能无法实现。
将 .NET 组件作为 32 位 x86 而不是 x64 运行。我假设你已经考虑过并出于某种原因拒绝了这个。
使用COM 代理DLLhost.exe在进程外托管 COM 组件。这将使对 COM 服务器的调用变得非常非常慢（它们现在将处理 Windows 消息而不是本机函数调用），但在其他方面是透明的（您不必做任何特殊的事情）。
如果服务器需要自定义代理存根而不是使用普通的 oleaut32 代理存根（尽管非常罕见），这可能不是一个选项，因为不会有 64 位版本的代理可用。只要可以使用普通的OLE编组，就可以注册代理激活。
回答by lsalamon
I have found this solution, Dealing with Legacy 32-bit Components in 64-bit Windowssee in article :
? Converting a project type from in-process to out-of-process
? Using COM+ as a host (this work for me)
? Using dllhost as a surrogate host
我找到了这个解决方案，在 64 位 Windows 中处理旧版 32 位组件，请参阅文章：
？将项目类型从进程内转换为进程外
? 使用 COM+ 作为主机（这对我有用）
？使用 dllhost 作为代理主机
回答by Sean
It's your COM component is housed in a COM server (ie a seperate process) then you won't need to do anything special as the COM subsystem will remote your calls from your x64 app to the X86 app and back again.
这是您的 COM 组件位于 COM 服务器（即一个单独的进程）中，然后您不需要做任何特殊的事情，因为 COM 子系统会将您的调用从您的 x64 应用程序远程调用到 X86 应用程序，然后再返回。
If your component is an in-process COM component then you'll have to rethink things as a 64 bit process can't use 32 bit in process COM components. You could force your server to run under x86 so that you can access the components (they'll both be 32 bit processes). If you don't want to do this then you'll have to see if there a x64 bit version of the COM components you're using.
如果您的组件是进程内 COM 组件，那么您将不得不重新考虑事情，因为 64 位进程不能使用 32 位进程内 COM 组件。您可以强制您的服务器在 x86 下运行，以便您可以访问组件（它们都是 32 位进程）。如果您不想这样做，那么您必须查看是否有您正在使用的 COM 组件的 x64 位版本。
