NamedPipeWrapper双向消息推送实现及消息事件未触发问题咨询

通信失效的核心原因基本都集中在管道连接建立后，消息读写循环异常终止/阻塞这两个方向，按优先级排查修复即可：

• 序列化不兼容导致读循环静默崩溃
  该库默认使用二进制序列化完成对象传输，要求通信两端的消息类型必须来自同一个被共同引用的程序集，不能在客户端、服务端项目里分别定义结构完全相同但分属不同程序集的SomeClass。
  二进制序列化在反序列化时会严格校验消息携带的程序集标识、类完整类型名，一旦标识不匹配，负责后台读取消息的线程会直接抛出序列化异常。而库内部默认会静默吞掉这类异常并终止整个管道的消息读循环，最终表现为：连接建立的事件（ClientConnected）可以正常触发，但后续所有入站消息都无法被解析，对应的ClientMessage、ServerMessage事件永远不会触发。
  修复方式：把SomeClass类提取到独立的共享类库项目，客户端和服务端统一引用这个共享类库的编译产物，避免重复定义相同结构的消息类。同时确保类上保留[Serializable]特性，不要在类里添加和序列化逻辑冲突的自定义逻辑，保证两端序列化逻辑完全一致。如果是在.NET Core/.NET 5+环境下运行，还需要在项目启动时显式开启BinaryFormatter的序列化支持，否则会因为框架的默认安全策略禁止类型反序列化，直接导致读循环崩溃。
• 回调逻辑阻塞导致管道读写卡死
  库的事件回调是直接在管道的后台读写线程上触发的，如果在事件处理逻辑中执行同步阻塞操作（比如等待输入、执行耗时的同步网络请求、持有锁等待其他线程），会直接卡住负责消息读写的后台线程，导致整个管道的消息传输流程完全停摆。
  修复方式：所有事件处理逻辑不要执行长耗时的阻塞操作，如果有需要处理的耗时任务，要放到独立的线程池后台执行，不要阻塞回调线程。
• 连接握手未完成就推送消息导致首条消息丢失
  客户端的Start()方法是异步执行的，方法调用后仅会启动连接流程，并不会等待管道完全握手成功。如果没有监听连接完成的回调，在握手尚未完成时就调用PushMessage推送消息，会导致消息被直接丢弃。
  修复方式：在客户端侧注册连接完成的回调事件，等管道完全建立连接后再执行消息推送，调整后的客户端代码示例：

  var client = new NamedPipeClient<SomeClass>("MyServerPipe");
  // 等待连接完全握手成功
  client.Connected += conn => 
  {
      Console.WriteLine("Successfully connected to pipe server");
      // 连接就绪后主动向服务端推送测试消息
      conn.PushMessage(new SomeClass { Request = "Hello from client" });
  };
  client.ServerMessage += (conn, message) =>
  {
      Console.WriteLine($"Server says: {message.Response}");
  };
  client.Start();
  Console.ReadKey();
  

  额外注意Windows环境下的权限问题：如果服务端以管理员权限运行、客户端以普通用户权限运行，会出现连接表面建立但消息传输被系统权限拦截的情况，需要保证两端运行权限一致，或者在服务端创建管道时开放对应的访问权限。

按以上调整完成后，双向通信的完整流程可正常运行：

1. 服务端启动管道监听，等待客户端接入
2. 客户端异步发起连接，握手完成后触发两端的连接事件
3. 服务端在ClientConnected事件中，通过当前连接对象的PushMessage方法向客户端推送欢迎消息，客户端的ServerMessage事件可正常接收并打印
4. 客户端在连接就绪回调中，通过连接对象的PushMessage方法向服务端推送请求消息，服务端的ClientMessage事件可正常接收并打印
5. 后续任意一端只要持有对应的连接对象，都可以随时调用PushMessage向对端推送消息，无需额外的握手流程。

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