views:

438

answers:

3

I'm trying to launch an external updater application for a platform that I've developed. The reason I'd like to launch this updater is because my configuration utility which handles updates and license configuration for the platform has shared dependencies with other assemblies in the folder where the update will be deployed. So, while I can rename the configuration utility and overwrite it when deploying the update, I can't rename or overwrite the DLLs it depends on. Hence, the external updater application.

I'm handling all of the update gathering logic in the configuration utility, then attempting to launch the updater to handle the actual file copy/overwrite operations. Obviously, because of the file in use issues, I need the configuration utility to exit right after the updater begins.

The problem I'm having is that I'm using the standard Process.Start method of launching the updater, and as soon as the configuration utility exits, the updater process gets killed too.

Is there any way that I can create a Process that outlives its parent, or launch an external application that can run beyond the program that launched it?

EDIT:

Apparently, in my updater application, I miscalculated the number of command line arguments which are passed to it. Because of this, the updater would exit immediately. I misinterpreted this to mean that the launcher application was killing the "child" process, when in fact, it wasn't.

The answers below are correct.

+1  A: 

There's no reason why a process started with Process.Start should automatically die when the launcher exits. My guess is that you're doing something odd in the updater.

I've written an updater doing exactly this kind of thing before, and it's been fine.

For example:

Launcher.cs:

using System;
using System.Diagnostics;

class Launcher
{
    static void Main()
    {
        Console.WriteLine("Launching launchee");
        Process.Start("Launchee.exe");
        Console.WriteLine("Launched. Exiting");
    }
}

Launchee.cs:

using System;
using System.Threading;

class Launchee
{
    static void Main()
    {
        Console.WriteLine("       I've been launched!");
        Thread.Sleep(5000);
        Console.WriteLine("       Exiting...");
    }
}

Compile both of them, separately, and run Launcher.exe. The "launchee" process definitely lasts longer than the launcher.

Jon Skeet
The configuration utility launching the updater is a windows forms application, could that have anything to do with what I'm seeing?
Chris Carter
+3  A: 

Could you share some code please? It seems that the problem you are seeing has a different reason because the Process class will not kill any processes started using Process.Start when your application exits.

See this simple sample program, the calculator will stay open:

using System.Diagnostics;

class Program
{
    static void Main(string[] args)
    {
        Process.Start(@"C:\windows\system32\calc.exe");
    }
}
0xA3
You're absolutely correct, my assumptions were clouded by speed, unfortunately. I've updated my question accordingly.
Chris Carter
A: 

Just a thought from my foggy memory, but I seem to remember having a discussion a while back that when the Process.Start method is called from Form that the spawned process has some sort of dependency (not sure what, why or how, memory is a bit foggy).

To deal with it, a flag was set that was actually called from the Main() method of the application after the main form/app exited and that if the process was launched from the Main() method, eveything worked out just fine.

Just a thought, like I said, this is purely from memory, but some of the examples posted here all being called from the Main() method of a console app seemed to jog something.

Hope all works out well for you.

James Conigliaro
I wasn't able to reproduce such a behavior and I would be really surprised if this was the case. A child process will typically not notice if it its parent dies (and this is an OS level thing) unless you have implemented a special behavior inside the parent process to kill all children.
0xA3
I had the same assumption, apparently our memories are using some kind of psychic IPC or something :)
Chris Carter