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

Question

我遇到的情况是必须从托管的64位进程中调用本机32位代码的频率随着64位机器和应用程序的普及而增加。我不想将我的应用程序标记为32位，并且我无法获取正在调用的64位版本的代码。

我当前使用的解决方案是创建C++ COM垫片，这些垫片是从进程中加载​​的，以便从64位进程进行32位调用。

这个COM shim解决方案效果很好，并且跨进程调用由COM处理，这最小化了这种方法的开销。

但是我想保留所有使用C＃进行的新开发，并想知道是否有任何框架可以最大限度地减少这样做的开销。我已经看过IPCChannel，但我觉得这种方法并不像COM shim解决方案那么简单。

感谢， 埃德

Answer 1

我有同样的问题，我的解决方案是使用remoting。基本项目包括：

• 平台无关CalculatorRemote.dll库与X32 P
  • CalculatorNative内部静态类/调用方法从MarshalByRefObject其用于从CalculatorNative本机方法衍生
  • RemoteCalculator类;
• 主平台独立的C＃文库（例如Calculator.dll），引用CalculatorRemote.dll，用其私人使用RemoteCalculator类的单援引在需要的地方的X32功能Calculator类;
• x32控制台应用程序托管RemoteCalculator从CalculatorRemote.dll消耗Calculator.dll通过IpcChannel。

因此，如果主要应用在64位模式下，它是产卵RemoteCalculator主机应用程序和使用远程的启动实例RemoteCalculator。 （在x32中，它只使用了一个本地实例RemoteCalculator。）棘手的部分是告诉calculator-host应用程序关闭。

我觉得这比使用COM，因为更好：

• 您没有在任何地方注册COM类;
• 与COM的互操作应该比.NET远程处理慢;
• 有时候，如果COM端发生问题，您需要重新启动应用程序才能从中恢复; （可能我对COM不太熟悉）
• 在x32模式下运行时，远程处理不会有任何性能损失 - 所有方法都将在同一AppDomain中调用。

Answer 2

几乎是唯一的答案是出于进程通信的。您可以创建一个.NET项目，这是一个32位可执行文件，它可以完成所有需要的32位调用，并通过Windows消息，WCF，命名管道，内存映射文件（4.0）等与它进行通信。我很确定这就是Paint.NET如何从64位进程中完成他们的WIA（Windows图像采集）。

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