c# - 使用托管代码包装器从 64 位托管代码调用 32 位非托管代码的最佳方式

Question

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

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

这种 COM shim 解决方案运行良好，跨进程调用由 COM 在幕后处理，从而最大限度地减少了这种方法的开销。

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

谢谢，埃德

Answer 1

我遇到了同样的问题，我的解决方案是使用 remoting .该项目基本上包括:

• 独立于平台的 CalculatorRemote.dll 库
  • CalculatorNative 带有 x32 P/Invoke 方法的内部静态类
  • RemoteCalculator 派生自 MarshalByRefObject 的类它使用了 CalculatorNative 中的本地方法；
• 独立于平台的主要 C# 库(例如 Calculator.dll)，引用 CalculatorRemote.dll，带有私下使用单例的 Calculator 类RemoteCalculator 类在需要时调用 x32 函数；
• x32 控制台应用程序，托管来自 CalculatorRemote.dll 的 RemoteCalculator，由 Calculator.dll 通过 IpcChannel 使用.

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

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

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