views:

1066

answers:

2

I need to integrate some legacy 32-bit code - for which I don't have the source code, into a project in such a way that it can be called from a 64-bit .NET assembly. The original code is implemented as a 32-bit COM object in a DLL. Windows doesn't allow direct calls from 64 to 32-bit objects, so I'm looking for inspiration on how to deal with this situation.

How can a legacy 32-bit COM object be accessed from a 64-bit .NET assembly?

UPDATE: We discovered that the COM component was itself a wrapper around some ANSI C, which we founf the original source for. We were able to compile that in Visual Studio as a native 64-bit dll, and import that into .NET - sorry to move the goalposts!

+4  A: 

The best approach is to make an out of process COM server that wraps your 32-bit DLL. You can then call this from 64bit code.

Here is an explanation of the basic concepts.

Reed Copsey
I moved the goalposts a bit because we discovered some source code that led us to a different solution. I'm accepting this answer as I feel it best answers the original question and links to useful reading material.
Tim Long
+2  A: 

What you need to do is create two processes communicating with IPC. This way, one can be 32 bit, and one can be 64 bit. You need to create a 32 program which links with the COM object and exposes its API through some IPC mechanism such as a named pipe. This way your .NET program can access it from another process.

Zifre
This approach works, although if you're already using COM, why switch to named pipes instead of just using COM interop?
Reed Copsey
@Reed Copsey: Oh, yes, of course you could use that for COM. But my approach is more general; it could work for normal libraries too.
Zifre
I thought of using WCF to do the IPC using Named Pipes. Only problem is, both ends of the pipe need to see the same interface definition, which has to be in a 32-bit assembly. The whole thing explodes when you try to run it.
Tim Long