.NET 6.0 WPF程序跨进程消息队列通信实现方案咨询

首先澄清MSMQ的适配问题：你查到的MSMQ不支持.NET 6的结论并不完全准确——.NET 6确实移除了内置的System.Messaging命名空间，但可以通过安装社区维护的兼容NuGet包实现MSMQ调用。但MSMQ属于依赖Windows系统可选组件的重量级消息方案，需要手动开启系统功能、配置权限，仅适合离线、异构系统的消息传递场景，完全不适合同一程序多实例的同机跨进程通信，没必要为了这个场景强上MSMQ。

针对同一WPF程序不同运行实例的跨进程通信需求，按适配度从高到低的可选方案如下：

• 命名管道（Named Pipes）—— 首选方案
  .NET 6 内置System.IO.Pipes命名空间提供原生支持，无额外依赖、无需部署额外组件，是同机跨进程通信性能最高、实现成本最低的方案。你可以给管道设置带程序唯一标识的固定名称，第一个启动的程序实例自动作为管道服务端监听，后续启动的实例作为客户端接入即可；管道原生支持消息模式传输，自动处理消息边界，支持异步读写、多客户端连接，完全可以实现你需要的消息队列能力。
  服务端最简初始化示例：

  // 管道名加唯一标识避免和其他程序冲突
  var pipeServer = new NamedPipeServerStream(
      "MyWpfApp_Comminication_Pipe_v1", 
      PipeDirection.InOut, 
      NamedPipeServerStream.MaxAllowedServerInstances, 
      PipeTransmissionMode.Message
  );
  await pipeServer.WaitForConnectionAsync();
  // 后续可直接通过StreamReader/StreamWriter或二进制方式读写消息
  

• 内存映射文件—— 高吞吐场景方案
  如果你的场景需要高频传递消息、甚至需要共享大块内存数据，可以使用.NET 6内置的System.IO.MemoryMappedFiles实现共享内存，搭配互斥量、信号量做进程同步，自己实现简单的环形消息队列即可，通信延迟是所有方案里最低的，适合对性能有极致要求的场景。
• 本地回环gRPC/HTTP—— 可扩展场景方案
  如果你后续有计划把通信能力扩展到跨设备场景，可以直接用.NET 6内置的gRPC或ASP.NET Core Kestrel绑定127.0.0.1回环地址做消息服务，生态成熟调试方便，缺点是需要处理端口占用问题，同机通信性能比命名管道低30%左右。
• 兼容使用MSMQ—— 存量代码迁移方案
  如果你有大量基于MSMQ的存量代码不想重写，可以安装对应兼容NuGet包在.NET 6环境下调用MSMQ，注意前提是目标机器必须在Windows功能中开启MSMQ组件，且需要配置对应的队列访问权限，部署成本很高，非必要不选。

实现注意点：所有跨进程通信方案都要做好异常重连、并发读写的同步处理，命名管道本身的消息传输模式已经帮你处理了TCP类方案常见的消息粘包问题，对于绝大多数WPF客户端的多实例通信场景，直接选命名管道即可，不需要额外引入第三方消息队列组件。

内容的提问来源于stack exchange，提问作者fabraham