The frequency with which I am coming across the situation where I have to call native 32-bit code from a managed 64-bit process is increasing as 64-bit machines and applications
I had the same problem and my solution was to use remoting. Basically the project consisted of:
CalculatorRemote.dll
library with
CalculatorNative
internal static class with x32 P/Invoke methodsRemoteCalculator
class derived from MarshalByRefObject which used native methods from CalculatorNative
;Calculator.dll
), referencing CalculatorRemote.dll
, with Calculator
class which was privately using singleton of the RemoteCalculator
class to invoke x32 functions where needed;RemoteCalculator
from CalculatorRemote.dll
to consume by Calculator.dll
via IpcChannel.So if the main application started in x64 mode it was spawning a RemoteCalculator
host application and used remoted RemoteCalculator
instance. (When in x32 it just used a local instance of RemoteCalculator
.) The tricky part was telling calculator-host application to shut down.
I think this it better than using COM because:
Pretty much the only answer is out of process communication. You could create a .NET project that is a 32-bit executable that makes all of the 32-bit calls needed and communicate with it via Windows Messages, WCF, Named Pipes, Memory Mapped Files (4.0), etc. I am pretty sure this is how Paint.NET does their WIA (Windows Imaging Acquisition) from a 64-bit process.
In the case of PDN, they simply pass the name of the file they expect as the output, but more complex communication isn't difficult. It could be a better way to go depending on what you're doing.