C + C＃进程间通信：命名管道，内存映射文件或其他？

我正在玩C dlls来钩住全局Windows事件，下一步是向C＃应用程序发送一些事件数据（没有任何巨大的数据）。C + C＃进程间通信：命名管道，内存映射文件或其他？

，因为我想这个通信尽可能地快，我分析两种选择：命名管道和内存映射文件。

我知道，.NET 4本机方式带来的MMF，但我必须面向.NET 2，如Win98下的客户端的存在仍然是可能的。我也知道有很多方法可以通过Windows API管理MMF和.NET 2（有些人甚至已经构建了一些包装器）。

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

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

来源

2010-01-06 jfneis

这并不重要，但Win98 EOL是2006年7月11日。我很遗憾听到仍然有人坚持使用它。我不羡慕你菲利普... –

更多关于主题，你可以在.NET 2中使用带有P/Invoke的MMF。 –

在这种情况下，我不能使用P/Invoke，因为全局挂钩会附加到每个流程执行，所以程序必须用本地语言（C，Delphi，VB等）编写。是的，Martinho，这个Win98的依赖真的很臭。如果你很伤心，想象我们的团队.. :) – jfneis

选项1：在您的一个C＃对象上公开一个COM接口，并从您的C++应用程序中调用该接口。

选项2：使用C++/CLI - 您可以使用Win32 API挂钩全球的窗口的事件和暴露在另一侧的.NET类对C＃客户端直接使用。

当然，没有这些选项回答的命名管道与内存映射文件你的问题，但我认为任何一项都将是简单的，除非你有特殊需要，以保持它们作为单独的进程。

来源

2010-01-06 16:13:23 Tarydon

Tarydon，感谢您的答案。在考虑你的选择之前，重要的是要知道全局钩子将它的一段代码（DLL）附加到机器上执行的每个进程，所以它们必须使用本地代码编写。我不知道选项1是否真的有可能，因为COM依赖项会附加到每个正在执行的进程（也许可能，但不是performatic）。就我所知，选项2是不可能的。由于该代码将附加到每个进程，我的C＃客户端不会有一个单一的类来处理（这就是为什么我在考虑命名管道）。 – jfneis

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

此消息设计用于简单的进程间通信（目标具有GUI），本地应用程序或.NET应用程序几乎可以毫不费力地使用此消息，除了任何压力外，不会对系统产生任何影响你把内存创建你绕过数据，并适用于所有Windows系统从Windows 95

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

来源

2010-01-17 19:04:25 TheSmurf

不能告诉MMF虽然我还没有尝试使用它，但从它的外观来看，它似乎有点太复杂，无法设置的东西。在封装了P/invokes之后，为了能够以.NET 2.0的形式公开命名管道（我已经创建了3.5 System.Core类的外观），可以很容易地发送数据包如果您可以设置权限，以使Vista/7更多限制性策略能够正常工作。

也许你最好在C＃应用程序中使用服务器流，并且让你的本地代码中的客户端可能有很多实例可以挑起来（我不确定你能够共享一个单独的实例，与所有注入DLL的进程挂钩，所以我认为你将有多个客户端）。

我已经放弃了DLL挂钩为Vista/7共为这一问题。

来源

2010-01-28 14:31:03 Monoman

C + C＃进程间通信：命名管道，内存映射文件或其他？

回答

相关问题