How should IPC be handled in .NET Core?

Question

In a past .NET Framework project, our main application ran as a Windows Service and we used WCF NetNamedPipeBinding to communicate with a WPF front end application. Since WCF won't be a part of .NET Core, how should I handle inter-process communication? The new application (worker service) needs to handle typical RPC and also push data to another process.

I'm considering the following:

1. Named pipes. This would work, but these are effectively streams in the API. Handling the streams and establishing a protocol seems like a pain.

2. gRPC, but that would involve converting a number of data models to protobuf which isn't desirable.

3. SignalR, but that would involve hosting an ASP.NET Core application inside my service. Seems like an overkill.

Any insight or alternatives would be appreciated!

Answer 1

Three recent low-effort options that I would consider:

MessagePipe (new)

"MessagePipe is a high-performance in-memory/distributed messaging pipeline for .NET and Unity. It supports all cases of Pub/Sub usage, mediator pattern for CQRS, EventAggregator of Prism(V-VM decoupling), IPC(Interprocess Communication)-RPC, etc.

- Dependency-injection first
- Filter pipeline
- better event
- sync/async
- keyed/keyless
- buffered/bufferless
- singleton/scoped
- broadcast/response(+many)
- in-memory/interprocess/distributed

MessagePipe is faster than standard C# event and 78 times faster than Prism's EventAggregator."

Haven't tried, but this author is a .NET legend.

gRPC:

For larger projects you can use Visual ReCode to automate the conversion of your projects from WCF to gRPC. I have limited experience with this project, but looks very promising and gRPC is definitely the future...

ServiceWire:

ServiceWire is a deliciously lightweight IPC/RPC library. Cross-platform, supports TCP/IP & named pipe channels. Insanely fast and easy to use- simply add [Serializable] to all classes that need to be sent over the wire. I really love this framework.

Only downsides are:

• no SSL support, but does own encryption and automatic compression
• no .NET Core standard DI support, but it's server implementation makes this a non-issue