Executing a method in an external program, but having it affect the reference program

Question

I realise this might be hard to explain, so let me start by using an example from Windows; keBugCheckEx().

How would I go about making a method that is contained within one program but, when executed from another, affect the program it is in. For example, in the main program, you could have:

public static void Panic(uint errCode)
{
    System.Windows.MessageBox.Show("Function Panic() was called with error code: "
        + errCode);
    Application.Exit();
}

And then, in the second program, you could call that method, e.g.

public static void Main(string[] args)
{
    Foo.Panic(0x3C);
}

How would I go about making it so that, instead of the MessageBox showing in the second program, it appears in the first program? Sorry if this is not very well explained.

That's why COM/ActiveX was invented :) And RMI, and CORBA... The current "best answer for Windows is "try WCF". — paulsm4, Mar 29 '12 at 18:06
possible duplicate of [Interprocess communication for Windows in C# (.NET 2.0)](http://stackoverflow.com/questions/50153/interprocess-communication-for-windows-in-c-sharp-net-2-0) — paulsm4, Mar 29 '12 at 18:07
Do tell us what version of .NET you are trying to do this with. The "best" answer changes with each version. — Ben Voigt, Mar 29 '12 at 18:09

DRapp · Accepted Answer · 2012-03-29T19:09:12.873

0

You mention two separate "programs". Do you mean two separate executables? I think what you mean is you would have a project that is more of a class library that encapsulates certain functions / validations. You refer to "Foo" but no other declaration... is it a second project within your overall application "Solution" and included as part of the main with #using. Secondary class libraries SHOULD be able to do a simple messagebox as long as its called from within the overall main UI thread.

You might need to elaborate a bit more / update your question.

I guess the final solution was the feedback comment to have the class just have a method within the class that does nothing but pass a string message BACK to the calling source. From that, any application calling it can get the message and display it within their own UI thread.

edited Mar 29 '12 at 19:09

answered Mar 29 '12 at 18:05

DRapp

47,638
12
72
142

Sorry. I mean there are two executables. In this case, as this is an experiment, there is "hostApp.exe" and "callApp.exe." Both are console applications. In hostApp, there is a function called Panic() that would write to the console (Different but similar to my example above), but is called from callApp. Panic() is in hostApp, and calls another function (this time a private one) inside the main class of hostApp. What I am trying to achieve is, instead of writing on callApp, it writes on hostApp. – LMS Mar 29 '12 at 18:11
@LiamMcSherry, then I would just have a method within the class that does nothing but pass a string message BACK to the calling source. From that, any application calling it can get the message and display it within their own UI thread. – DRapp Mar 29 '12 at 18:32

score 0 · Answer 2 · answered Mar 29 '12 at 18:10

The ability of one process to affect another process is, for very good reason, tightly controlled by most OSes. A program that can make another program execute instructions that don't follow the normal logic path of that program can induce undesirable behavior, and such actions are a hallmark of viruses.

That being said, there are ways to structure these two processes to allow for inter-process communication; processes often have to talk to each other, and often one program can "tell" another program to execute code, but the actual decision to do so is made by the program. For two programs that could also stand alone, something like a named pipe would allow for one process to input data into another process which could be interpreted as a command.

If both of these processes are .NET, or the libraries containing the code are COM-compatible, you can simply execute the code from the other program in the calling process. You simply reference the external library, and if Foo as a class is visible to external consumers, you can instantiate one and call its methods. This would be the normal way to execute behavior from a different process within your own; but, you can't tell a different process with a Foo to call Panic(), but not execute absolutely everything in it (which includes showing the dialog in the context of the owning process's UI thread)

Executing a method in an external program, but having it affect the reference program

2 Answers2