.NET6 控制台服务与WPF共享命名管道空引用架构优化咨询

出现WPF端pipeServer始终为null的核心原因非常明确：静态变量是进程内存范围内隔离的，不会跨进程共享。
你的控制台服务、WPF托盘程序是两个完全独立的操作系统进程，各自加载运行自己的代码副本，有独立的内存空间。你只在控制台进程的启动逻辑里给Globals.pipeServer做了赋值初始化，这个操作完全不会影响WPF进程里的同名静态变量——WPF进程从来没执行过初始化管道服务端的代码，这个变量自然从启动到退出一直是null。
另外你本身的管道角色也搞混了：命名管道是典型的客户端/服务端架构，你实现的NamedPipesServer是管道服务端，本身就只能在作为后台服务的控制台进程里启动运行，WPF作为用户态的UI程序，是管道的客户端，根本不应该去初始化服务端实例。

• 拆分管道两端的实现逻辑，明确进程职责
  把现有管道代码按角色拆分，不要混在公共类里让两个进程随便调用：
  • 控制台服务进程：唯一持有并初始化NamedPipesServer实例，用固定管道名drawbridgepipe启动监听，负责处理客户端连接、收发管道消息，是管道通信的服务端
  • WPF托盘进程：新增NamedPipesClient实现，用相同的管道名初始化H.Pipes提供的PipeClient<PipeMessage>，主动连接控制台端的管道服务，作为通信的客户端，不要在WPF进程里实例化任何服务端相关的对象
• 移除全局静态管道变量，用接口抽象解耦业务逻辑和管道实现
  删掉Globals类里存的静态pipeServer字段，在两个项目共用的公共类库里定义统一的管道通信接口：

  public interface IPipeCommunicator
  {
      // 发送消息
      Task SendAsync(PipeMessage message);
      // 收到消息的事件
      event EventHandler<PipeMessage> MessageReceived;
      // 连接状态
      bool IsConnected { get; }
  }
  

  分别在两个进程里实现这个接口：控制台端的实现内部包装NamedPipesServer的逻辑，WPF端的实现内部包装NamedPipesClient的逻辑。
  改造你的TapDevice类，不再直接访问全局静态变量，而是通过构造函数注入IPipeCommunicator实例：不管是在服务端进程还是WPF进程运行，只要传入对应进程的管道实现，就能正常调用收发能力，从根源上避免null引用问题。
• 拆分跨进程的业务边界
  梳理TapDevice里的逻辑，区分哪些逻辑只能在控制台服务进程执行，哪些是WPF端的交互逻辑：
  • RSA密钥操作、服务端注册、设备状态采集这类需要后台长期运行、高权限的逻辑，只放在控制台服务进程里执行，状态变化时通过管道主动给WPF端推送通知
  • 托盘菜单交互、弹窗提示、用户操作触发的指令，不要在WPF端直接执行业务，通过管道客户端把指令发给服务端，等服务端执行完成返回结果后再更新UI

• Windows系统服务运行在Session 0，和用户态运行的WPF程序不在同一个会话，初始化PipeServer的时候必须配置管道安全规则，给交互式用户开放读写权限，不然WPF端会连不上管道
• 不要用.GetAwaiter().GetResult()这种同步阻塞方式调用异步的管道初始化方法，控制台服务启动时直接用await等待初始化完成即可，否则容易出现线程池死锁
• 服务端不要只存单个PipeConnection对象，要用ConcurrentDictionary之类的线程安全集合存储所有接入的客户端连接，否则多个客户端连接时会覆盖之前的连接实例，导致消息发错目标或者发送失败

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