如何在不使用 SendMessage 的情况下将“消息”发送到 .Net 中的另一个进程？答案

【问题标题】：How can I send a "Message" to another process in .Net, without using SendMessage?如何在不使用 SendMessage 的情况下将“消息”发送到 .Net 中的另一个进程？
【发布时间】：2016-10-27 02:38:04
【问题描述】：

我有多个应用程序在一台机器上运行。一个是在工作并将日志记录到磁盘上（我称之为 WorkerApp），另一个是总结有关 WorkerApp 状态的支持信息以及更多细节（我称之为 Dashboard）。

我想从仪表板指示 WorkerApp 采取行动（例如，“Ping 远程服务”），并且我希望 WorkerApp 在收到它时向仪表板发送“pong”响应。

我已经看到使用SendMessage 的示例，但这似乎很陈旧（2016 年现在进程间通信没有更标准的东西吗？）。

我对@987654322@ 的经验很少，但它的Remoting 功能似乎是一个不错的方法，尽管设置它对于我想做的事情来说似乎有点矫枉过正。

目前在 .Net 中的两个进程之间进行通信的最简单方法是什么？是否有一些这样的例子，在本地机器上工作？

【问题讨论】：

Akka.NET可以，或者你可以使用MSMQ...任何消息总线基本上都是你做IPC的方式
“过度杀伤”是相对的。如果您有任何解决方案，您可能想要更多（如安全性、可靠性、远程（如在不同的计算机中）等）。将所有这些东西添加到基于原语（如原始管道等）的本土解决方案中并非易事。我会使用现有的技术，Akka.NET 甚至 WCF。
@Christian.K 我知道“矫枉过正”是一个主观术语。这就是我目前对 Akka.net 的感受，因为我对它没有太多经验。我可能会尝试使用 Akka.net Remoting 来解决这个问题，但我想了解一下其他人是否已经走上了这条路并且有过糟糕的体验。
“IPC Mechanisms in C# - Usage and Best Practices”可能重复

标签： c# .net win32-process akka.net

【解决方案1】：

为此，我整理了一个 Akka.Net 示例。这就是它的样子。

仪表板（发送消息）

using System;
using Akka.Actor;
using Akka.Configuration;

namespace DashBoard
{
    class Program
    {
        static void Main(string[] args)
        {
            var config = ConfigurationFactory.ParseString(@"
akka {  
    actor {
        provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote""
    }
    remote {
        helios.tcp {
            transport-class = ""Akka.Remote.Transport.Helios.HeliosTcpTransport, Akka.Remote""
            applied-adapters = []
            transport-protocol = tcp
            port = 0
            hostname = localhost
        }
    }
}
");

            using (var system = ActorSystem.Create("Dashboard", config))
            {
                var server = system.ActorSelection("akka.tcp://WorkerApp@localhost:8081/user/WorkerAppActor");
                while (true)
                {
                    var input = Console.ReadLine();
                    server.Tell(input);
                }
            }
        }
    }
}

WorkerApp（接收消息）

using System;
using Akka.Actor;
using Akka.Configuration;

namespace WorkerApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var config = ConfigurationFactory.ParseString(@"
akka {  
    actor {
        provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote""
    }
    remote {
        helios.tcp {
            transport-class = ""Akka.Remote.Transport.Helios.HeliosTcpTransport, Akka.Remote""
            applied-adapters = []
            transport-protocol = tcp
            port = 8081
            hostname = localhost
        }
    }
}
");

            using (var system = ActorSystem.Create("WorkerApp", config))
            {
                system.ActorOf<WorkerAppActor>("WorkerAppActor");

                Console.ReadLine();
            }
        }
    }

    class WorkerAppActor : TypedActor, IHandle<string>
    {
        public void Handle(string message)
        {
            Console.WriteLine($"{DateTime.Now}: {message}");
        }
    }
}

【讨论】：

【解决方案2】：

看看 .Net 远程处理。它比 SendMessage 更现代一点，但不是很多。虽然它很容易使用。我认为这些天来执行此操作的官方方法可能是使用 WCF，但我很确定它在引擎盖下是一样的。

.Net 远程处理支持各种通道（Http、TCP），但在你的情况下，我建议 IPC 远程处理。它位于命名管道之上。

如果你用谷歌搜索（.Net 远程处理）可能最简单，但一般的想法是在你的“服务器”应用程序中定义一个从 MarshalByRefObject 派生的类。完成后，使用 RemotingConfiguration.RegisterWellKnownServiceType 将其注册到远程处理基础架构。

然后，您的客户端应用程序可以使用 Activator.CreateObject 创建该类的实例，然后您就可以开始了。

需要注意的一件事：您似乎需要一个回调机制 - 因此您的仪表板不会因为等待您的 WorkerApp 而被阻塞。这在 .Net 远程处理中受支持，但您需要创建两个通道 - 一个用于传出调用（从 Dashboard 到 WorkerApp），另一个用于传入回调。

另一个建议：如果你的工作类（从 MarshalByRefObject 派生的）也暴露了一个接口，将更容易处理。将该接口放在可供应用程序使用的 DLL 中，生活会更轻松。

【讨论】：

.NET Remoting 不建议用于新开发，quote the MSDN：“本主题 [.Net Remoting] 是特定于保留的遗留技术，以向后兼容现有应用程序和不建议用于新开发。现在应该使用Windows Communication Foundation (WCF) 开发分布式应用程序。"
WCF 与 .NET 远程处理一样容易配置，您甚至可以做到 without configuration files。
@ScottChamberlain 感谢您提供的链接，请检查一下。
没错...这就是我提到 WCF 的原因，尽管不是很强烈。我知道 WCF 现在是首选方式，但我喜欢 .Net 远程处理的简单性，听起来这里的用例非常简单。
同上感谢@ScottChamberlain 的链接 - 显然我有时间复习了，只是从来没有遇到过 .Net Remoting 问题迫使我转向 WCF。

【解决方案3】：

一个建议可能是使用数据库或其他持久存储来创建仪表板可以将任务插入到其中的“队列”类型。这也可以存储有关可以由工作进程更新的任务的状态。尽管这可能被认为是“矫枉过正”，但它带来了各种各样的好处，例如审计、历史报告和服务器崩溃/断电冗余。它还可能使将来更容易扩展应用程序。

【讨论】：