How can I send a message from a VB6 application to my C# application

Hi have a VB6 Windows application (old.exe) and a separate C# Winfor开发者_如何学Pythonms application (new.exe). They both run on the same Windows machine.

I have access to both the VB6 and the C# source code, but the apps need to remain separate.

If both are running and have knowledge of each other (process Id), what's the best way to send a message from one window to the other?

Update:

In this case, I'm only talking about very infrequent and small messages - e.g. change the tab you're looking at using a small message like, "Invoice 67"

Bi-directional messaging would be great, but VB6 to .Net is the most important.

Neither of the two prior answers consider the fact that this may be a multi-tentant environment or even span you domain. As you move into distributed systems you shold consider messaging as opposed to inter-process communication, which over time will limit scalability.

For on-premise solutions consider MSMQ, there is a multitude of documentation out there, demonstrating the simplicity of this messaging infrastructure.

for broader scenarios, you should consider Windows Azure Storage Queues, you get an almost identical usability, but with a broader accessibility and improved management tools.

MSMQ is domain-specific, by Azure spans the globe.

Agreed with Clay's comments.

However, I'll take a stab in the dark and go with the most obvious answer:

.NET (w/ WCF) supports both IPC and Named Pipes for local intra-process communications.

Here's a link on the topic using named pipes... but it's super old, and doesn't use WCF like it should... but the point is the same: http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp Updated version using WCF: http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication

Here is a more-or-less complete list of IPC alternatives for Windows.

http://msdn.microsoft.com/en-us/library/aa365574%28v=vs.85%29.aspx

Most of them can be utilized from VB6 and C# as well.

The solution that I have used for this very purpose is to have TCP communications between the processes. It allows for bidirectional communication. And as a bonus, should you ever move one of the applications to a different box, your apps will continue functioning with very little changes.

In .NET, you can use a plethora of classes for this purpose (ton of stuff from low-level to high-level in System.Net). In VB6, you could go with the Winsock control that ships with the IDE. I use Dart Winsock control (costs $$$), just because it is so much more flexible.

I set up both apps to send/receive XML fragments with a known schema. There is typically an attribute that tells the other app the type of message being received, along with the payload.

A basic solution (based on the info provided):

Create a dedicated folder for incoming and outgoing messages (the one applications incoming folder will be the others outgoing folder)

Write messages (or data) into text/xml or other format to the output folder (adding a Source field so the application knows where its from)

Read the messages, based on date, and import messages/data

This allows integration to/from any application.

The Ultimate Answer To This Question

VIRTUAL NULL MODEM: http://en.wikipedia.org/wiki/Null_modem#Virtual_null_modem

From Wikipedia:

A virtual null modem is a communication method to connect two computer applications directly using a virtual serial port. Unlike a null modem cable, a virtual null modem is a software solution which emulates a hardware null modem within the computer. All features of a hardware null modem are available in a virtual null modem as well. There are some advantages to this:

Higher transmission speed of serial data (limited by computer performance only). Virtual connection over network or Internet is possible, mitigating cable length restrictions. An unlimited number of virtual connections is possible. No serial cable is needed. The computer's physical serial ports remain free.

For instance, DOSBox has allowed older DOS games to use virtual null modems.

Another common example consists of unix pseudo terminals (pty) which present a standard tty interface to user applications, including virtual serial controls. Two such ptys may easily be linked together by an application to form a virtual null modem communication path.

With the HIGHLIGHT of this solution being: IT REQUIRES NO CABLES!!!

*Note; This is an attempt at humor. Forgive me if it's not funny.