Request for feedback on new .NET Process APIs

[adamsitnik]

Hi @Tyrrrz,

My name is Adam, I'm working on a set of new APIs for .NET to address many of the pain points with System.Diagnostics.Process. Since your project makes heavy use of process execution, I'd greatly appreciate your feedback on the design.

Overview

I'm proposing a layered API approach:

• High-level convenience methods for common scenarios (Process: easy-to-use, reliable and efficient APIs for (some of the) common scenarios dotnet/runtime#123959)

// Capture output - no deadlock possible
ProcessOutput output = await ChildProcess.CaptureOutputAsync(options);

// Stream lines as they're produced
await foreach (var line in ChildProcess.StreamOutputLines(options))
{
    Console.WriteLine(line.Content);
}

// Redirect directly to files (much faster than piping through .NET)
await ChildProcess.RedirectToFilesAsync(options, null, "output.txt", "error.txt");

• Low-level primitives for advanced scenarios (Process: SafeChildProcessHandle and option bag dotnet/runtime#123380)

// Full control over handles, piping between processes, signal handling, etc.
File.CreatePipe(out SafeFileHandle readPipe, out SafeFileHandle writePipe);

using (readPipe)
using (writePipe)
{
    ProcessStartOptions producer = new("cmd")
    {
        Arguments = { "/c", "echo hello world & echo test line & echo another test" }
    };
    ProcessStartOptions consumer = new("findstr")
    {
        Arguments = { "test" }
    };

    // Start producer with output redirected to the write end of the pipe, no input and discarding error.
    using SafeChildProcessHandle producerHandle = SafeChildProcessHandle.Start(producer, input: null, output: writePipe, error: null);

    // Start consumer with input from the read end of the pipe, writing output to file and discarding error.
    using SafeFileHandle outputHandle = File.OpenHandle("output.txt", FileMode.Create, FileAccess.Write, FileShare.ReadWrite);
    using SafeProcessHandle consumerHandle = SafeProcessHandle.Start(consumer, readPipe, outputHandle, error: null);

    // Wait for both processes to complete
    await producerHandle.WaitForExitAsync();
    await consumerHandle.WaitForExitAsync();
}

Key benefits:

• Handle inheritance by default limited to standard IN/OUT/ERR (with an allow list)
• No deadlock pitfalls - the API handles draining stdout/stderr correctly
• Built-in timeout/cancellation that kills the process and its descendants
• Optional KillOnParentDeath to prevent orphaned processes
• Native file redirection (significantly faster)
• Efficient multiplexing for sync scenarios (no background threads)

The full proposal and working implementation is available at: https://github.com/adamsitnik/ProcessPlayground

Request for Feedback

I'd love to hear your thoughts on:

• Would these APIs address your use cases?
• Are there important scenarios that aren't covered?
• Any API naming or design suggestions?

Thanks for considering this, and I look forward to your feedback!

Best regards,
Adam

[Tyrrrz]

Hi Adam.

These changes are a welcome addition to .NET as it has well-recognized issues when dealing with child processes. I think any new APIs that simplify these workflows are going to improve the state of the framework in that regard.

In the context of CliWrap, many of the issues mentioned (deadlocks, cancellation, kill on parent death, etc) have already been solved either by leveraging the existing Process APIs or by native system calls.

However, there are some things that CliWrap could benefit from, namely:

• Some sort of signal that the child process has exited and its stream handles were inherited. Currently, there's no way to tell if that happened as the out/err streams can realistically outlive their parent, even without being inherited further.
• Ideally a way to prevent the streams from being inherited altogether. Not sure if that's possible.
• Virtual terminal functionality that would allow launching a child process, while convincing it that it's running inside an actual console window (i.e. it doesn't see streams as redirected).
• Unified way to send interrupt signals. On Windows, the library currently deploys an external process that attaches to the target console and sends an interrupt signal. Would be nice if this could be simplified.

Unfortunately, it would still be troublesome to use these new additions in CliWrap because, as a library, it would need to remain compatible with older targets. So realistically, it will probably continue using its own abstractions/workarounds, except for those that can't be backported by reasonable means (which would only be available for users on . NET vNext).

As for API naming/design suggestions, I'm afraid that my suggestions would just devolve toward mimicking CliWrap, as I think that's the best design for spawning processes there is 😄

Let me know if I fully answered your questions