使用托管代码包装器从64位托管代码调用32位非托管代码的最佳方法

Question

我需要从托管的64位进程调用本机32位代码的情况越来越频繁,因为64位计算机和应用程序变得普遍.我不想将我的applciation标记为32位,我无法获得正在调用的64位版本的代码.

我目前使用的解决方案是创建C++ COM填充程序,这些填充程序在进程外加载以从64位进程进行32位调用.

这个COM填充程序解决方案运行良好,跨进程调用由COM在幕后处理,这最大限度地减少了这种方法的开销.

但是,我想保留我们使用C#进行的所有新开发,并想知道是否有任何框架可以最大限度地减少执行此操作的开销.我看过IPCChannel,但我觉得这种方法并不像COM shim解决方案那样整洁.

谢谢,艾德

Answer 1

我有同样的问题,我的解决方案是使用远程处理.基本上该项目包括:

• 与平台无关的CalculatorRemote.dll库
  • CalculatorNative 内部静态类与x32 P/Invoke方法
  • RemoteCalculator派生自MarshalByRefObject哪个类的本地方法CalculatorNative;
• 独立于主平台的C#库(例如Calculator.dll),引用CalculatorRemote.dll,Calculator类私有地使用RemoteCalculator类的单例来调用需要的x32函数;
• 其托管的X32控制台应用程序RemoteCalculator从CalculatorRemote.dll由消耗Calculator.dll通过IpcChannel.

因此,如果主应用程序在x64模式下启动,则它会生成一个RemoteCalculator宿主应用程序并使用远程RemoteCalculator实例.(在x32中它只使用了本地实例RemoteCalculator.)棘手的部分是告诉计算器主机应用程序关闭.

我认为这比使用COM更好,因为:

• 您不必在任何地方注册COM类;
• 与COM互操作应该比.NET远程处理慢;
• 有时如果COM端出现问题,您需要重新启动应用程序以从中恢复; (可能我对COM不是很熟悉)
• 在x32模式下运行时,远程处理不会有任何性能损失 - 所有方法都将在同一个AppDomain中调用.

Answer 2

几乎唯一的答案就是流程外的沟通.您可以创建一个32位可执行文件的.NET项目,该项目需要进行所有32位调用,并通过Windows消息,WCF,命名管道,内存映射文件(4.0)等与之通信.我非常确定这就是Paint.NET如何通过64位进程进行WIA(Windows Imaging Acquisition).

在PDN的情况下,他们只是将他们期望的文件名称作为输出传递,但更复杂的通信并不困难.取决于你正在做什么,这可能是一个更好的方法.