How can you ensure an executable is opened via another executable?

Question

There's a neat little trick that you can use to never have the OS hold a lock on the .dll's / .exe's an .exe needs to run.

Let's say our directory looks like this:

>opener.exe
>actualProgram.exe
>dependency.dll

As a basic example, we could do this:

namespace Opener
{
    class Program
    {
        static void Main(string[] args)
        {

            AppDomain domain = AppDomain.CurrentDomain;
            AppDomain newDomain = AppDomain.CreateDomain(
                domain.FriendlyName,
                domain.Evidence,
                domain.BaseDirectory,
                domain.RelativeSearchPath,
                true,  // "shadow copy" files: copy rather than lock
                domain.SetupInformation.AppDomainInitializer,
                domain.SetupInformation.AppDomainInitializerArguments
            );
            string assembly = 
                System.Reflection.Assembly.GetExecutingAssembly().Location 
                + "\\..\\actualProgram.exe";
            newDomain.ExecuteAssembly(assembly, args);
        }
    }
}

We could also put more logic in there, which we could use to actually replace/update actualProgram.exe despite an instance of the process being opened. Try it: you'll be able to delete/modify/replace dependencies and the "actual" program when it's loaded via the "opener". Obviously this has its benefits, namely making updates a lot easier.

But in your "actual.exe", how can you be sure that it was loaded via another executable, and know that it was loaded without having a lock taken on the .exe? If someone is to just load the "actual.exe", i.e. not via the "opener", I want to make sure that the process immediately exits.

Hints?

Answer 1

1. Pass a command line parameter to actualProgram.exe that lets it know it was launched by the launcher. (Also suggested in a comment on the OP by oleksii)
2. Set an environment variable in the launcher that can be inherited by the child process.
3. Use one of the documented methods for getting the parent process id, and use that to get information about the launching process. (Of course if the parent process terminates, Windows is free to re-assign the PID to a new process.)
4. Create a memory-mapped file/named pipe/etc. in the launcher that can be used to pass information to the child.
5. Manually load and unload the library references in the child. If they are .Net assemblies, you can use the AssemblyResolve event, loading the file from disk into a byte array and using the Assembly.Load(byte[], byte[]) overload.

Note: As long as all of your assemblies are loaded manually or by the runtime before you modify/move/delete them, you're probably ok. Also, changing the DLL after it's been loaded will probably have no effect on the running process. I say probably in both cases, because it's generally a good idea to leave the libraries alone at runtime, especially if you aren't loading them manually.

See Also:

• Run-Time Dynamic Linking @ MSDN
• How can a Win32 process get the pid of its parent?
• Assembly.Load Method (Byte[], Byte[])