c# - 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:

Option 1

Have a look at MagicOnion. Uses a blazing fast serializer, is cross-platform, has built-in LZ4 message compression, SSL/TLS support and streaming. In my experience changing from a self-hosted WCF server to this is a doddle- you can use your data contracts as is, no need to create the proto files for gRPC.

Only downsides I've experienced are:

• error messages are not particularly useful if you mis-configure SSL and
• only .NET clients supported.

It also uses/requires HTTP/2 for communications and therefor does not support named pipes, which may limit it's appeal/client support...

I've used this for the past 7 months with .NET Core as a cross-platform upgrade to 25-odd self hosted WCF servers and haven't looked back- it's very fast and stable.

NOTE: Version 4 no longer supports .NET 4.x Framework for Server

Option 2:

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...

Option 3:

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