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 withCalculatorNative
internal static class with x32 P/Invoke methodsRemoteCalculator
class derived fromMarshalByRefObject
which used native methods fromCalculatorNative
;
- Main platform-independent C# library (e.g.
Calculator.dll
), referencingCalculatorRemote.dll
, withCalculator
class which was privately using singleton of theRemoteCalculator
class to invoke x32 functions where needed; - x32 console application which hosted
RemoteCalculator
fromCalculatorRemote.dll
to consume byCalculator.dll
viaIpcChannel
.
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.
精彩评论