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