Passing Information Between Applications in C#

Question

All. Firstly I am aware of the question Send data back to .exe from dll, however the answers there leave too many open ends for me and as I have no experience of what I am attempting I feel a new question is warranted.

I have an existing C# [All WinForms here] app that heavily relies on SQL. We have been asked (by clients) to provide an SQL Editor and library that can be used to develop and test SQL, but that can also be used to paste directly back in to the main application. The new SQLEditor is a multi-threaded application that parses and executes TSQL. I now have some things to consider; what is the best way to launch this second application from the main application::

1. Make the second app into a DLL and load into the main project, call the second app as a new form (SqlEditor sqlEd = new SqlEditor() etc.)? What are the implication in terms of thread bombardment, would I need [STAThread] - as I want both multithreaded apps to be available and active at the same time.

2. To launch as a separate .exe from the main application?

Depending on you advice; in either of the above cases - what is the best way I can pass information back to the main application from a click event in the second application whilst they are still both running and active [WCF, ApplicationDomains etc.]? Would the Observer design pattern come in to play here?

To make this question a little more appealing, here is the SQL Editor:

I plan to have a button which pastes the selected SQL back into the main application.

I am also aware that there are multiple questions here - which I apologise for. Thanks very much for your time.

Solution 1

You have multiple choices for IPC(Inter Process Communication) such as: Mailslot, NamedPipe, Memory Mapped File, Socket, Windows Messaging, COM objects, Remoting, WCF... http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx http://en.wikipedia.org/wiki/Inter-process_communication

Some of them provide two-way communication, some needs considaration about system security(antivirus & firewall restrictions, you need to add the application as an exception in their settings).

Sending message through WM_COPYDATA can be done just by SendMessage, PostMessage is not supported, it means that the communication is sync.

Using outproc singleton COM object is another way, its not as simple as the other ways and both app. must be run on the same security context to access the same COM object.

Launching a separate application can coz some restrictions in communication methods or types of data you can pass, but separation of them will also protect them from their failures(App. crash will not close the other one).

If the two parts are always run on the same PC, using one of them as dll[inproc] is simpler. Using other techniques such as Socket, Remoting, WCF will provide you with more flexibility for communication, i.e. the two parts can run in different PCs with minor modifications...

Solution 2

If you need a simple way to do an outproc communication of two WinForms applications, then why don't you use the Clipboard with a custom format?

In the source application:

    // copy the data to the clipboard in a custom format
    Clipboard.SetData( "custom", "foo" );

In the destination application, create a timer to peek the clipboard:

    private void timer1_Tick( object sender, EventArgs e )
    {
        // peek the data of a custom type
        object o = Clipboard.GetData( "custom" );
        if ( o != null )
        {
            // do whatever you want with the data
            textBox1.Text = o.ToString();
            // clear the clipboard
            Clipboard.Clear();
        }
    }

This should fit your needs and it's still really simple as it doesn't require any heavyweight outproc communication mechanisms.

Solution 3

Another way of accomplishing intra-app communication is with the use of Windows messages. You define a global windows message id and use Windows API calls such as SendMessage and PostMessage.

Here's a simple article that explains how: Ryan Farley's article "Communication between applications via Windows Messages"

This is in effect the observer pattern, receiving all the Windows messages being directed at the current Window and picking out the one you're listening out for.

In my experience this is definitely less flaky than the clipboard approach.