随着64位计算机和应用程序变得普遍,我必须从托管的64位进程调用本机32位代码的情况越来越频繁。我不想将我的applciation标记为32位,我无法获得正在调用的64位版本的代码。
我目前使用的解决方案是创建在进程外加载的C ++ COM填充程序,以便从64位进程进行32位调用。
这个COM填充程序解决方案运行良好,跨进程调用由COM在幕后处理,这最大限度地减少了这种方法的开销。
但是我想保留我们使用C#进行的所有新开发,并想知道是否有任何框架可以最大限度地减少执行此操作的开销。我看过IPCChannel,但我觉得这种方法并不像COM shim解决方案那样整洁。
感谢, 编
答案 0 :(得分:7)
我遇到了同样的问题,我的解决方案是使用remoting。基本上该项目包括:
CalculatorRemote.dll
库
CalculatorNative
带有x32 P / Invoke方法的内部静态类RemoteCalculator
派生自MarshalByRefObject
的类,它使用CalculatorNative
中的原生方法; Calculator.dll
),引用CalculatorRemote.dll
,Calculator
类,私有地使用RemoteCalculator
类的单例来调用x32函数需要; RemoteCalculator
从CalculatorRemote.dll
托管Calculator.dll
以RemoteCalculator
通过IpcChannel
消费。因此,如果主应用程序在x64模式下启动,则会生成RemoteCalculator
主机应用程序并使用远程RemoteCalculator
实例。 (在x32中它只使用了{{1}}的本地实例。)棘手的部分是告诉计算器主机应用程序关闭。
我认为这比使用COM更好,因为:
答案 1 :(得分:5)
几乎唯一的答案就是流程外的沟通。您可以创建一个32位可执行文件的.NET项目,该项目需要进行所有32位调用,并通过Windows消息,WCF,命名管道,内存映射文件(4.0)等与之通信。我非常确定这就是Paint.NET如何通过64位进程进行WIA(Windows Imaging Acquisition)。
在PDN的情况下,他们只是将他们期望的文件名称作为输出传递,但更复杂的通信并不困难。取决于你正在做什么,这可能是一个更好的方法。