Best IPC for VB6 and .net application

In our application (a document management system) we are supposed to be notified of screen changes (or notify the other program of screen changes) in order to keep the two applications looking at the same data, one being the order fulfillment app, the other the document viewer of the original fax. The fulfillment app is written in vb6 and the document manager is in .net 3.5 (c#). It runs on a terminal server so it also has to be session aware. The document viewer or the fulfillment app may be open first and both can be used without the other. What would be the best method of IPC?

From stackoverflow

• If you want to be able to run on Vista or Windows 7, the best form of IPC is going to be TCP (which is done very easily from VB6 with the Winsock control).

  The advantage of this is that two apps can communicate even if they aren't running as the same user, they can communicate (you can't do that with SendMessage or Named Pipes under Vista+). The only thing you have to remember to do, is set a rule in the firewall so it doesn't get blocked. This can be done in your installer with:

  netsh.exe firewall set allowedprogram "{PROGRAM PATH}" "{PROGRAM NAME}" enable
  

• Kris's answer is probably still the best bet, but you would likely need a kludge to maintain sanity with terminal server.

  On whichever application you want to act as the "server" app, you could open an unused port, and display it to be entered into the "client" app. Perhaps even utilizing environment variables. Depending on your needs, this approach could be all wrong.

  If you simply have two apps where one needs to be notified when the other changes (and not notified of what actually changed), you could probably do it by sending and hooking windows messages.

• Named pipes and mailslots are still some of the best choices available, and they work cross-user as well as cross-process. Of course in Vista+ there are issues with processes running at different integrity levels, and security applies on earlier OSs as well - much like file security.

  TCP is always significantly slower within the same machine, probably even worse than WM_COPYDATA across processes.

  Using pipes or mailslots you can handle terminal services by making the session ID part of the name. TCP will always be challenged by its limited "namespace" of port numbers (imagine a hard drive that can only have files named 0 through 65535 - and each connection requires TWO port numbers).