We are considering interprocess communication assuming the following environment.

ExeA (X86) ==>Hook =>TargetExe (32Bit) OK
'Hook =>TargetExe (WoW32Bit) OK
'Hook =>TargetExe (64Bit) Cannot!

ExeA (X86) ==>ExeB (AnyCPU)
'ISProcess64Bit ...
'Assembly.LoadFile (...
'======>Dll32 == Hook =>TargetExe (32Bit)
'Dll64 == Hook =>TargetExe (64Bit)

We are considering a global hook from ExeA to TargetExe.
However, the ExeA of the caller in the specification is an Exe compiled with 32Bit, so
If Os is 64-bit and TargetExe is 64-bit, global hook cannot be performed.
So, we want to prepare ExeB and dynamically load Dll according to the hook target to perform hook.

I think process communication between ExeA and ExeB is necessary to achieve this.
In general, what technology should I use?
As far as I investigated,
Win32API SendMessage, WCF (too exaggerated?), .Net Remoting "IPC" (legacy?)
What do you think is true?

In terms of processing, it is a thing that calls the method of ExeB from ExeA and receives the result
I think that simple things are better than extensibility, so I think that SendMessage is good.
What do you think?
Please let us know what you think.
Thank you.

◆◆◆ Addition of information ◆◆◆
Added notes from yohhoy.
Frequency of inter-process communication: Low (only at start and end)
Amount of communication data per time: small (parameters required for method activation and results)
Allowable delay time: None is desirable.
Two-way/one-way communication: Two-way (I want the execution result)

  • Answer # 1

    I think that the simplest mechanism is a named pipe.
    Both Win32 API and .Net Framework are supported, and communication is possible even if ExeA and ExeB are running on different PCs.

    Reference site:
    How to: Use Named Pipes for Network Interprocess Communication

    If you can help.