Best way to call 32-bit unmanaged code from 64-bit Managed Code using a managed code wrapper

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 become prevalent. I don't want to mark my applciation as 32-bit and I cannot obtain 64-bit versions of of the code that is being calling.

The solution that I currently use is to create C++ COM shims that are loaded out of process to make the 32-bit calls from the 64-bit process.

This COM shim solution works well and the cross process calls are hand开发者_开发问答led behind the scenes by COM, which minimises the overhead of this approach.

I would however like to keep all the new development that we undertake using C# and wondered if there are any frameworks that minimise the overhead of doing this. I have looked at IPCChannel but I feel that this approach is not as neat as the COM shim solution.

thanks, Ed

I had the same problem and my solution was to use remoting. Basically the project consisted of:

• Platform-independent CalculatorRemote.dll library with
  • CalculatorNative internal static class with x32 P/Invoke methods
  • RemoteCalculator class derived from MarshalByRefObject which used native methods from CalculatorNative;
• Main platform-independent C# library (e.g. Calculator.dll), referencing CalculatorRemote.dll, with Calculator class which was privately using singleton of the RemoteCalculator class to invoke x32 functions where needed;
• x32 console application which hosted 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:

• You don't have to register COM classes anywhere;
• Interoperating with COM should be slower than .NET remoting;
• Sometimes if something is going wrong on the COM-side you need to restart your application to recover from that; (possibly I'm just not very familiar with COM)
• When running in x32 mode there won't be any performance penalty with remoting -- all methods will be invoked in the same AppDomain.

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.