.NET process to Borland C++ process communication

Question

Back in 1999 a project was started that required communication between two processes; one was a VB6 application and the other was a Borland C++ process. The VB6 was designed as a COM ActiveX server EXE (out-of-process) application, and the Borland C++ application would instantiate the VB6 COM server and access methods and properties of the VB6 COM server. This has served us well for the last 14 years and has been very reliable; note both processes run on the same server, but we designed for processes to run on different windows systems on local network only if ever required.

Basically the Borland C++ application can request data from a couple of methods and get a response, and there is one event fired by the VB6 COM server that sends a BSTR to the Borland C++ process that it must receive as an event - these are sent every 100ms and the BSTR size ranges between 250 to 2500 bytes.

I need to start thinking about how best to replace the VB6 ActiveX COM EXE server with an updated - probably C# .NET application. I have good access and communication with the developer of the Borland C++ process so that side of the equation could also be changed very easily if desired.

The Borland C++ developer is using a fairly old version - I believe Borland 7? At least that is a lot newer than VB6, and I have to assume he won't upgrade at least not for the foreseeable future.

Here are some of the current design decisions: we don't need persistence or message reliability, if a message is lost its okay (he can do another request or in the case of the event fired from the COM server to the Borland client the next message 100ms later will be fine). Neither process must affect the other - that is why we chose a COM EXE out-of-process server. No type of in-process, even a DLL wrapper, will be considered for the Borland C++ client.

Here is what I have considered going forward:

1. An ATL COM EXE server using VS2012 C++ that replicates exactly the old VB6 COM EXE server; I really was hoping to leave the complexity of COM and move to a new really simple easier method of process to process communication. (I don't feel this is moving forward and sounds gross to maintain, debug, and add new features too?) Advantage Borland C++ client does not need to change anything if I get it exactly right.

2. ZeroMQ I have written several other C# apps that use this and I really like it - but I don't know if there is ZeroMQ client for Borland C++ (can Borland C++ developer just use the C/C++ ZeroMQ library?)

3. Redis - I have written two C# apps using Pub/Sub that works well and I really like this - couple of issues will there ever be a "production" release of Redis for Windows 7/8 and can I find a Redis client for Borland C++, is there one?

4. ? - looking for advice, on the above choices or something even better?

Thanks

Major Edit to the question: If you were starting a brand new C# .net application and a brand new Borland C++ application and these two applications need to run on Windows 7/8/9 and they must be able to send data to each other - what technology would you use to do process to process communication?

Thanks Neal Davis

Answer 1

C# does almost as good a job hiding the complexity of COM as VB6 did. So implementing the same COM interface in C# should give the advantages of #1 in a lot less time.