让两个 .net 应用程序相互通信的最轻量级的方式是什么？答案

【问题标题】：What's the most lightweight way to have two .net apps talk to each other?让两个 .net 应用程序相互通信的最轻量级的方式是什么？
【发布时间】：2010-12-12 20:34:01
【问题描述】：

我们有一个带有简单命令（例如播放、暂停、下一首曲目）的 .net 服务。这安装在用户的工作站上，具有自己的凭据（例如，FooServiceUser）。如果我想给用户一个可以将命令发送到服务的应用程序，那么最轻量级的方法是什么？请记住，我只想将命令从单个工作站发送到在同一工作站上运行的进程。命令非常简单。此外，应用程序需要从服务接收状态。即暂停，播放第 21 首曲目。

应该很容易吧？ WCF 看起来很复杂而且矫枉过正。 SO上的每个人都在说.net远程处理很糟糕。我不想安装 MSMQ。每次提到套接字都会得到负分。

【问题讨论】：

您希望保持“轻”的“体重”是多少？部署有效载荷的大小？本地化？学习曲线？
轻量级的意思，简单易学、易懂，几乎不会出错。我正在从 c++ win32 过渡。所以命名管道的等价物是我正在寻找的。相反，我看到整本书有价值的额外内容，大量关于我可能不需要的技术的信息。
对不起，我还想补充一点，内存占用不足。

标签： .net ipc

【解决方案1】：

对于一个完整、易于使用的解决方案，我推荐 WCF。它仅支持此应用程序的内存通道协议 (ICP)。

仍然是您所说的“轻量级”。 WCF 的托管部分可以在大约 5 行代码中完成。生成所有客户端代码。那么，您是否真的关心您必须使用（已安装）的程序集的数量和大小，或者您要忽略的功能数量？

只需使用 WCF。
如果需要，它可以让您轻松扩展到套接字和 PC 间。

【讨论】：

“WCF 的托管部分可以在大约 5 行代码中完成”，不翻译轻量级。
@aliosta，也许可以，但有什么作用？
@aliosta，远程处理在学习部门中不符合“轻”条件。我真的看不出它还有什么作用。 WCF 是客户配置文件的一部分，对吧？
我认为他的意思是在性能和硬件要求方面。
不支持TCP！实际上，我从个人经验中知道它不适用于客户资料。

【解决方案2】：

我绝对会说 Remoting 已被取代并使用 WCF 和命名管道绑定，但现在您正在谈论 轻量级，我必须说 Remoting 是轻量级的，并且由于两个 AppDomain 之间的通信而无处可去通常是通过远程处理。所以它确实是一个有效的选择。

话虽如此，考虑到 WCF 的灵活性，我仍然会推荐 - 尽管它又重、又粗又熟。

【讨论】：

我会说Remoting已经被同化（Borg风格）到WCF中，你真的提倡使用过时的技术吗？ “轻量级”的优势究竟是什么？
IpcChannel 是 Remoting 的命名管道通道
WCF 中内置的抽象太重且过度烹饪。它的通道堆栈充满了很多东西。有人称 WCF 丰富，我称其为过度。

【解决方案3】：

如果应用程序与 Windows 服务在同一台机器上，您可能甚至不必担心使用远程处理、Web 服务等，因为您可以实例化 ServiceController Class 并使用其 ExecuteCommand 方法。

【讨论】：

有趣，我不知道你能做到这一点......不过看起来很有限（无法将参数传递给命令，命令数量有限......）
这在安全级别上是如何工作的？应允许所有用户发送“播放”或“暂停”，但不能停止或启动服务或影响其他服务。
同意在某些情况下缺少参数和设置命令数量是压倒性的限制，但它非常适合其他情况。 Windows 服务由访问控制列表处理，该列表还保护文件和目录。用户必须具有启动和停止权限才能启动和停止服务，但您需要发送一个表示启动、停止、暂停等的命令号。用户定义的控制权限可能需要向它发送命令。

【解决方案4】：

WCF 是轻量级的，因为我需要多少行代码才能完成通信。就执行速度和内存消耗而言，它不是很轻量级。 WCF 使用起来非常简单。但是它的可扩展架构有时让找到合适的类有点困难。

普通套接字操作在编码工作方面不是轻量级的，但在运行时操作方面是轻量级的。当通道打开或关闭时，您可以完全控制每一点。

【讨论】：