在.NET Windows窗体中，如何在两个EXE或应用程序之间发送数据？

Question

The scenario that I bring forward is basically that of, interaction between two .NET executables.

I have made a .NET Windows Forms application in C# (Application-A) that runs on a user's machine and does some specific activity, due to which it collects some data. Now I have another .NET Windows Forms executable (Application-B), also made in C#, which also does some specific activity based certain inputs or data provided.

Now what I want to do here is, call Application-B from the Application-A and pass the some data to it.

How do I accomplish this?

Answer 1

You can use several options. You have some resources for each option below.

• .NET Remoting
• WCF
• Use a communication file
• MSMQ

Two last options are valid only if the processes are in the same machine.

Since they are two separated processes I think that the easiest way to do this is using .NET Remoting . Here you can find documentation and examples about how to do it.

An alternative to Remoting is WCF (>= .NET 3.0). It performs better than remoting.

If the processes will be always in the same machine, if you don't want to use remoting on localhost you can communicate them through a file ( simple solutions usually work fine! )

And other more complex solution is communicate them using a Message Queue ( MSMQ ). Here you cand find out an example about how to use it.

Answer 2

You can use MSMQ to communicate between the applications.

Any mechanism will do, however.

You could use file based communications (write to a known directory and read from it).

WCF is another solution.

Answer 3

If both the applications are running on same user computer than

1- this can be achieved through inter-process communications channel (IPC channel)

2- If you are using .NET 4.0, you can use memory mapped files

If both the applications are running on different system

1- You can make use of .NET Remoting

2- You can have WCF service based communication

3- Web Service is also an option if using .NET 2.0 or lower versions

Answer 4

WCF is going to allow you a lot of flexibility in the future : Should you ever decide to enhance this communication to support multiple modes of communication, app.config changes should be the majority of the work to support a different binding.

In some of the projects I've been involved in, there's a mix of communications technologies where one choice would've been far easier to maintain-- this leads me to embrace the WCF decision for its inherent flexibility (WCF also supports MSMQ should the need arise to have queued communication).

If you're concerned about the learning curve and you're sure that no future need will arise for you to embrace other communication topologies, remoting could be a useful solution. Remoting is probably the easiest, least-developer-work needed way of setting up IPC.

You should stay away from things like Web Services -- there's unnecessary overhead in the web service operations that WCF doesn't suffer from (WCF can still allow binary transport, for instance).