4

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

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

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

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

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

3 回答 3

2

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

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

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

于 2010-01-17T19:04:25.463 回答
1

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

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

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

于 2010-01-06T16:13:23.073 回答
0

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

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

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

于 2010-01-28T14:31:03.097 回答