.NET Core中应如何处理IPC？

Question

在过去的.NET Framework项目中，我们的主应用程序作为Windows服务运行，并且我们使用WCF NetNamedPipeBinding与WPF前端应用程序进行通信。由于WCF不会成为.NET Core的一部分，我该如何处理进程间通信？新的应用程序（工作程序服务）需要处理典型的RPC，还需要将数据推送到另一个进程。

我正在考虑以下内容：

1. 命名管道。可以，但是这些实际上是API中的流。处理流并建立协议似乎很痛苦。

2. gRPC，但这将涉及将许多数据模型转换为protobuf，这是不希望的。

3. SignalR，但这将涉及在我的服务中托管一个ASP.NET Core应用程序。似乎是一种过度杀伤力。

任何见识或替代方案将不胜感激！

Answer 1

我会考虑的三个最近的省力选项：

选项1

看看MagicOnion。快速使用serializer，是跨平台的，具有内置的LZ4消息压缩，SSL / TLS支持和流传输。根据我的经验，从自托管的WCF服务器更改为轻而易举的事-您可以按原样使用数据协定，而无需为gRPC创建原型文件。

我所经历的唯一缺点是：

如果错误配置SSL和
• 错误消息并不是特别有用
• 仅支持.NET客户端。

它还使用/需要HTTP / 2进行通信，因此不支持命名管道，这可能会限制其吸引力/客户支持...

在过去的7个月中，我一直使用.NET Core作为跨平台升级到25多种自托管WCF服务器，并且没有回头，它非常快速，稳定。

注意：版本4不再支持.NET 4.x Server for Framework

选项2：

使用Visual ReCode自动将项目从WCF转换为gRPC。我在这个项目上的经验有限，但是看起来非常有前途，并且gRPC绝对是未来...

选项3：

ServiceWire是一个功能强大的轻量级IPC / RPC库。跨平台，支持TCP / IP和命名管道。疯狂，快速，易于使用-只需将[Serializable]添加到需要通过网络发送的所有类中即可。我真的很喜欢这个框架。

唯一的缺点是：

• 不支持SSL，但具有加密和自动压缩功能
• 不支持.NET Core标准DI，但由于服务器实施，因此这不是问题。