-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Description
Background and motivation
The Process
API currently provides no way to control the process creation flags used on Windows. This is unfortunate as there are a number of flags that are quite useful, such as CREATE_NEW_PROCESS_GROUP
, CREATE_SUSPENDED
, and DEBUG_PROCESS
.
Of course, you can P/Invoke CreateProcessW
to use these flags and this works for extremely trivial use cases. But as soon as you need anything more than "just run an executable with these flags", things get hairy: You have to reimplement environment block construction, string[]
-> string
command line pasting, and standard I/O piping. Not a fun experience at all.
I propose that ProcessStartInfo
simply gets a Windows-specific CreationFlags
property to set the process creation flags. These would just get OR'd with whichever flags Process
itself needs to set based on other properties (e.g. CREATE_NO_WINDOW
).
The implementation effort here should be extremely minimal while providing huge convenience to people who need to set process creation flags on Windows.
API Proposal
namespace System.Diagnostics.Process;
public sealed partial class ProcessStartInfo
{
[SupportedOSPlatform("windows")]
public uint CreationFlags { get; set; }
}
- I don't think there needs to be any validation of the flags beyond what
CreateProcessW
might do; the assumption would be that anyone using this property knows what they're doing. - I'm agnostic on whether the property should throw
PlatformNotSupportedException
on non-Windows platforms vs just being ignored. CreationFlags
could be strongly typed as an enum, but I'm not sure the BCL should be in the business of exposing such an enum and keeping it up to date with the Win32 API.
API Usage
var info = new ProcessStartInfo(fileName);
foreach (var arg in args)
info.ArgumentList.Add(arg);
info.CreationFlags = 0x4 /* CREATE_SUSPENDED */;
using var proc = new Process
{
StartInfo = info,
};
proc.Start();
// Do some Win32-specific stuff that ultimately causes the process to be woken up.
proc.WaitForExit();
Alternative Designs
Individual properties for each flag is also an option.
Risks
None.