Launcher

Launching and Process Control

Launch starts the process. After it, WaitForExit blocks for the milliseconds given, IsRunning answers whether it is still up, and Kill or KillTree stops it. IsRunning answers false before Launch as well as after the process ends, so a workflow can ask without minding which. Kill, KillTree and WaitForExit on a launcher that was never started publish a WARNING and do nothing. KillTree is the one to reach for whenever the process starts others. Kill ends only the process GPAL started and leaves whatever it spawned behind, which on a shell or a build is most of what was running.

Examples

GPAL Fluent: High-level fluent C# API

//The handlers are given before Launch and called once per line as the process writes it, so a long run reports as it goes rather than all at once at the end. The second launcher is held rather than chained because the workflow starts it, does something else, and then decides whether to wait or to stop it. A chain that launches and waits in one breath cannot do that.

// read the output as it comes, then wait for it to finish

GPAL.Launcher

.WithExecutable(@"C:scriptsprocess.exe")

.WithArgument("--input=data.csv")

.WithOutputTo(line => GPAL.PublishSimpleEvent(GPALEventType.NOTICE, $"OUT [{line}]"))

.WithErrorTo(line => GPAL.PublishSimpleEvent(GPALEventType.CAUTION, $"ERR [{line}]"))

.Launch()

.WaitForExit(30_000); // 30 seconds


// held, so the workflow decides when it starts and when it stops

Launcher report = (Launcher)GPAL.Launcher

.WithExecutable(@"C: ools eport.exe")

.ToGPALObject();


report.Launch();


// the workflow gets on with something else while it runs


if (true == report.IsRunning())

report.WaitForExit(60_000);


// KillTree takes the children with it, which is what a process that spawned others needs

report.KillTree();

💬 Ask GPAL