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

Posted

技术标签:

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

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

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

【问题讨论】:

【参考方案1】:

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

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

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

剪贴板 COM 文件映射 管道 Windows 套接字

【讨论】:

同意他们击败 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。

【讨论】:

以上是关于使用和不使用 .net 的进程间通信的主要内容,如果未能解决你的问题,请参考以下文章

.NET 进程间通信的最佳选择是啥? [关闭]

.NET 进程间通信的最佳选择是啥? [关闭]

使用 NamePipe [进程间通信] VB.NET 传输对象

Linux进程间通信—使用共享内存

如何使用内存映射文件进行进程间通信?

Linux进程间通信——使用信号量