In principle, you get information on the parent process (like "launcher.exe"), using P/Invoke (see, for example,
http://spradip.wordpress.com/2008/10/24/getting-parent-process-id-from-child-without-passing-any-arguments-2/[
^]) or in a managed way (see, for example,
http://stackoverflow.com/questions/394816/how-to-get-parent-process-in-net-in-managed-way[
^]).
But what can it give you? You still need to tell which of the possible parent processes you current parent is, and, for this purpose, you would need to pass some identification information (such as PID) to the child process (application), and this will, in turn, require some IPC mechanism. Even if you reduce the problem to comparison of the parent process name (if you have the PID, you can traverse all current process using
System.Diagnostics.Process.GetProcesses() and find then name by known PID), this would not be a dirty method, because there is some chance of having some unrelated process with the same name; and, in general, having any hard-coded names in the application is dirty programming.
So,
does it even worth bothering? I don't think so. If you already have to pass some information to the child process via IPC, it would be much better to directly give this process information on its environment.
You really need to modify this "launcher.exe" (or whatever it is), to tell the child process information on the runtime environment (whatever it is). In the simplest variant, you can define a
command-line parameter in your application which tells it something about the environment. There are many other ways to pass some data. Please see:
http://en.wikipedia.org/wiki/Inter-process_communication[
^].
And, finally, if, by any chance, you need maximum flexibility or advanced featured of hosting of your application, you can have a custom CLR host. Please start here:
http://msdn.microsoft.com/en-us/library/dd380850%28v=vs.110%29.aspx[
^].
—SA
Submit an article or tip