I have to implement a bi-directional communication between two local process with support to backward compatibility .NET Core/NET Framework and platform architecture x86/x64.
The options that i have explored so far are:

1. HTTP: gRPC seems like a good solution since it manages the payload serialization, requests timeouts and cancelling. Plus it could be used by both .NET Core and .NET Framework and it is agnostic about platform architecture. However, it supports just simple Server/Client and request-response model. The only way to implement a bi-direction communication is to use bi-directional streaming and here the solution seems to be complex. Another drawback of gRPC is the need to HTTP which seems like an overkill.
2. Web sockets: SignalR seems just like the best solution, it supports bi-directional communication out of the box, however, the need to an embedded server is an overkill since we are talking about local process.
3. Shared Memory:Memory-mapped files has the best performance over every option i have explored , however i should to write myself all the infrastructure code from scratch which has a price.
4. Named pipes: named exposes a stream on which we could write a message and the other end could read and write a response. However as the Memory-mapped files i should write myself all the framework. I have seen some open frameworks like ServiceWire but it is not quite used ,hence i could convince the management to use it on a critical project.
5. Messaging queues: I have heared about ZeroMQ and amazing stuff we could implement with it, however always the same drawback of implementing all the IPC framework from scratch.

I am wondering, what is the standard way of handling inter-process communication in .NET Core/ .NET Framework?

Does all the companies using .NET implement their own IPC framework?