Access x86 COM from x64 .NET

Solution 1:

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:

1. 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.

2. Run your .NET component as 32-bit x86, instead of x64. I assume you've already considered and rejected this one for some reason.

3. Host the COM component out-of-process using the COM surrogate DLLhost.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.

Solution 2:

I have found this solution, Dealing with Legacy 32-bit Components in 64-bit Windows see 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

Solution 3:

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.

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.