使用和不使用 .net 的进程间通信答案

【问题标题】：interprocess communication with and without .net使用和不使用 .net 的进程间通信
【发布时间】：2010-07-14 20:38:03
【问题描述】：

我正在开发一个 .net WPF 应用程序，我想加入一个双向 IPC 机制。我意识到命名管道和远程处理是选项，但是我想让非 .NET 应用程序与我的应用程序通信的机制不依赖于 .NET。

SO 推荐什么作为解决方案？ WM_COPYDATA？

【问题讨论】：

标签： .net ipc

【解决方案1】：

在这种情况下，我会使用命名管道。

在本机代码和 .NET 中，命名管道是 fully supported。它们提供了一种非常快速、高效的工作方式，并且非常容易在 .NET 中用于您当前的开发。这是 WM_COPYDATA 的更好选择（几乎在所有方面，IMO）。

话虽如此，Interprocess Communication options 还是不少的。其中许多都适用于 .NET 和本机代码，包括：

【讨论】：

同意他们击败 WM_COPYDATA。不过，不确定它们是否像 TCP/IP 解决方案一样得到很好的支持。（我在这里包括 WCF 之类的东西，而不仅仅是普通的 HTTP。）
@Steven：这就是我包含 Windows 套接字（最后一个选项）的原因，它包括 TCP/IP（以及 UDP 套接字）。
@Steven：不过，管道在 Windows 上得到了很好的支持 - 所以在 WM_COPYDATA 可以工作的任何地方，管道都应该可以工作。
虽然任何能够调用 SDK 的东西都可以进行管道 I/O，但 .NET 仅在 3.5 中得到了不错的支持。即使那样，它也只是操作系统的一个薄包装，它的包装并不是很有趣。在过去的 15 年里，我在 IPC 和 RPC 中广泛使用了命名管道，但我仍然不喜欢它们。最后，IPC 部分是通过共享内存实现的，就像 TCP/IP 到 localhost 一样，但是您会获得 Windows 文件安全性的所有复杂性，并且无法访问 SOAP、REST 和所有其他内容。无论如何，这不是一个愚蠢的选择，但它不会是我首先转向的地方。我的 0.02 美元。

【解决方案2】：

命名管道不是 .NET 特定的。共享内存映射甚至 TCP/IP 都不会。至于 .NET 远程处理，我会避免使用它，即使双方都是 .NET。

【讨论】：