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