C+C# 进程间通信：命名管道、内存映射文件还是其他？答案

【问题标题】：C+C# Interprocess Communication: Named Pipes, Memory Mapped Files or other?C+C# 进程间通信：命名管道、内存映射文件还是其他？
【发布时间】：2011-01-02 03:01:17
【问题描述】：

我正在使用 C dll 来挂钩全局 Windows 事件，下一步是将一些事件数据（不是很大）发送到 C# 应用程序。

由于我希望这种通信尽可能快，我正在分析两个选项：命名管道和内存映射文件。

我知道 .NET 4 以本机方式带来了 MMF，但我必须针对 .NET 2，因为 Win98 客户端的存在仍然是可能的。我也知道有一些方法可以通过 Windows API 使用 .NET 2 来管理 MMF（有些人甚至为它构建了一些包装器）。

在这种情况下，我想知道：

选择命名管道而不是 MMF 有什么大的缺点（主要是性能）吗？请务必记住，我不会传输大量数据；
在 NP 或 MMF（针对 .NET 2）中是否存在任何安全问题？
还有比这些更好的选择吗？

【问题讨论】：

这并不重要，但 Win98 EOL 是 2006 年 7 月 11 日。听到仍然有人坚持它，我很难过。我不羡慕你菲利佩……
有关主题的更多信息，您可以在 .NET 2 中通过 P/Invoke 使用 MMF。
在这种情况下我不能使用 P/Invoke，因为全局挂钩附加到每个进程执行，所以程序必须用本地语言（C、Delphi、VB 等）编写.是的，Martinho，这个 Win98 依赖真的很臭。如果你很难过，想象一下我们的团队.. :)
我想你误解了什么 pinvoke 它。这就是c#调用本机代码的方式

标签： .net c ipc named-pipes memory-mapped-files

【解决方案1】：

如果目标应用程序有一个可以发送消息的窗口，并且发送的数据量比较小，可以考虑使用 WM_COPYDATA 消息传递信息。

此消息是为简单的进程间通信而设计的（其中目标具有 GUI），可以由本机或 .NET 应用程序以几乎零的努力使用，除了您施加的任何压力之外，不会对系统产生任何影响通过创建您正在传递的数据来存储内存，并且在 Windows 95 之后的所有 Windows 系统上都可用。

http://msdn.microsoft.com/en-us/library/ms649011(VS.85).aspx

【讨论】：

【解决方案2】：

选项 1：在您的 C# 对象之一上公开 COM 接口并从您的 C++ 应用程序中调用它。

选项 2：使用 C++/CLI - 您可以使用 Win32 API 来挂钩全局 Windows 事件并在另一端公开一个 .Net 类供您的 C# 客户端直接使用。

当然，这些选项都不能回答您关于命名管道与内存映射文件的问题，但我认为这两个选项中的任何一个都会更简单，除非您特别需要将它们保留为单独的进程。

【讨论】：

Tarydon，感谢您的回答。在考虑您的选择之前，重要的是要知道全局挂钩将其代码（DLL）附加到机器上执行的每个进程，因此必须使用本机代码编写它们。我不知道选项 1 是否真的可行，因为 COM 依赖项将附加到每个执行进程（也许可能，但不是执行的）。据我所知，选项 2 是不可能的。由于代码将附加到每个进程，我的 C# 客户端不会有一个单点类来处理（这就是我考虑命名管道的原因）。

【解决方案3】：

由于我没有尝试过使用它，所以无法详细说明 MMF，但从它的外观来看，它看起来有点太复杂而无法设置。在包装 P/invokes 之后，为了能够使用 .NET 2.0 将命名管道公开为流（我创建了类似于 3.5 System.Core 类的类），无论哪种方式都可以很容易地发送数据包如果您可以设置权限以使事情在 Vista/7 上运行更严格的政策。

您可能最好在 C# 应用程序中使用服务器流，并在本机代码中使用您可能的无数客户端实例（我不确定您是否能够在挂钩之前共享单个实例）使用您注入 dll 的所有进程，所以我认为您将有多个客户端）。

为此，我完全放弃了对 Vista/7 的 DLL 挂钩。

【讨论】：