A hypothetical redesign of System.Diagnostics.Process to avoid confusion over properties that are valid only when you are the one who called Start
Summary
A blog post proposing a redesign of the System.Diagnostics.Process class in .NET to separate properties valid only for started processes into a new class, aiming to reduce API confusion.
<p>Some time ago, I noted that <a title="How can my process read its own standard output?" href="https://devblogs.microsoft.com/oldnewthing/20251205-00/?p=111843"> the <code>Process.<wbr />StandardOutput</code> property is an attractive nuisance</a> because it is valid only on <code>Process</code> objects that you called <code>Start</code> on. You can’t just grab any old <code>Process</code> object and try to access its standard handles.</p>
<p>Others in the comments had their ideas on how to remove the confusion. Here’s mine. The principle is that the properties and methods of the <code>Process</code> object should be valid for all instances of the <code>Process</code> class. If a property or method is valid only conditionally, then either move it to a place that is accessible only if the condition is met, or get rid of it entirely if it adds no value.</p>
<p>The standard handles are the three properties that make sense only for <code>Process</code> objects that were created by the static <code>Start</code> method. There are also four methods related to those standard handles, as well as two events. Move them all to a new class, call it <code>Process<!-- -->StartResult</code>:</p>
<pre>class Process<!-- -->StartResult
{
public Process Process { get; }
public System.IO.StreamWriter StandardInput { get; }
public System.IO.StreamWriter StandardOutput { get; }
public System.IO.StreamWriter StandardError { get; }
public void BeginOutputReadLine();
public void CancelOutputReadLine();
public event DataReceivedEventHandler? OutputDataReceived;
public void BeginErrorReadLine();
public void CancelErrorReadLine();
public event DataReceivedEventHandler? ErrorDataReceived;
}
</pre>
<p>Change the signature of all the overloads of the <code>Start</code> method so that they return a <code>Process<!-- -->StartResult</code> instead of a <code>Process</code>. Now it is impossible to do anything with the standard handles from a process you didn’t start: If you didn’t start the process, then you don’t have a <code>Process<!-- -->StartResult</code>. This removes the confusion that existed in the original attempt to have a process read from its own standard output.</p>
<p>This follows <a title="How do I design a class so that methods must be called in a certain order?" href="https://devblogs.microsoft.com/oldnewthing/20190318-00/?p=102324"> a principle I wrote about earlier</a>: To force the developer to do things in a certain order, make the second step dependent on something produced by the first step. In this case, we want to force the developer to call <code>Start</code> before they use the standard handles, so we put the members related to the standard handles on a thing that you can obtain only by calling <code>Start</code>.</p>
<p>Next, remove the <code>StartInfo</code> property entirely. It serves two purposes:</p>
<ul>
<li>Prior to calling the <code>Start</code> method, it provides a convenient pre-made <code>Process<!-- -->StartInfo</code>.</li>
<li>After calling the <code>Start</code> method, it holds a copy of the parameters that you passed to the <code>Start</code> method.</li>
</ul>
<p>The first purpose is just to cover for people who are too lazy to write the <code>new</code> keyword. So don’t be lazy. Write <code>new Process<!-- -->StartInfo()</code>.</p>
<p>The second purpose doesn’t tell you anything you don’t already know, since you are the one who passed the parameters to the <code>Start</code> method in the first place. If they are so important to you, you can save them yourself.</p>
<p>Removing the <code>StartInfo</code> avoids confusion over whether the properties in it describe the process you want to start, or whether they describe a process that has already started. (And often, it describes neither!)</p>
<p>I think that takes care of the largest source of confusion over the proper use of the <code>Process</code> class.</p>
<p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260525-00/?p=112351">A hypothetical redesign of <CODE>System.<WBR>Diagnostics.<WBR>Process</CODE> to avoid confusion over properties that are valid only when you are the one who called <CODE>Start</CODE></a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
View Cached Full Text
Cached at: 05/26/26, 08:50 AM
# A hypothetical redesign of System.Diagnostics.Process to avoid confusion over properties that are valid only when you are the one who called Start - The Old New Thing
Source: [https://devblogs.microsoft.com/oldnewthing/20260525-00?p=112351](https://devblogs.microsoft.com/oldnewthing/20260525-00?p=112351)
Some time ago, I noted that[the`Process\.StandardOutput`property is an attractive nuisance](https://devblogs.microsoft.com/oldnewthing/20251205-00/?p=111843)because it is valid only on`Process`objects that you called`Start`on\. You can’t just grab any old`Process`object and try to access its standard handles\.
Others in the comments had their ideas on how to remove the confusion\. Here’s mine\. The principle is that the properties and methods of the`Process`object should be valid for all instances of the`Process`class\. If a property or method is valid only conditionally, then either move it to a place that is accessible only if the condition is met, or get rid of it entirely if it adds no value\.
The standard handles are the three properties that make sense only for`Process`objects that were created by the static`Start`method\. There are also four methods related to those standard handles, as well as two events\. Move them all to a new class, call it`ProcessStartResult`:
```
class ProcessStartResult
{
public Process Process { get; }
public System.IO.StreamWriter StandardInput { get; }
public System.IO.StreamWriter StandardOutput { get; }
public System.IO.StreamWriter StandardError { get; }
public void BeginOutputReadLine();
public void CancelOutputReadLine();
public event DataReceivedEventHandler? OutputDataReceived;
public void BeginErrorReadLine();
public void CancelErrorReadLine();
public event DataReceivedEventHandler? ErrorDataReceived;
}
```
Change the signature of all the overloads of the`Start`method so that they return a`ProcessStartResult`instead of a`Process`\. Now it is impossible to do anything with the standard handles from a process you didn’t start: If you didn’t start the process, then you don’t have a`ProcessStartResult`\. This removes the confusion that existed in the original attempt to have a process read from its own standard output\.
This follows[a principle I wrote about earlier](https://devblogs.microsoft.com/oldnewthing/20190318-00/?p=102324): To force the developer to do things in a certain order, make the second step dependent on something produced by the first step\. In this case, we want to force the developer to call`Start`before they use the standard handles, so we put the members related to the standard handles on a thing that you can obtain only by calling`Start`\.
Next, remove the`StartInfo`property entirely\. It serves two purposes:
- Prior to calling the`Start`method, it provides a convenient pre\-made`ProcessStartInfo`\.
- After calling the`Start`method, it holds a copy of the parameters that you passed to the`Start`method\.
The first purpose is just to cover for people who are too lazy to write the`new`keyword\. So don’t be lazy\. Write`new ProcessStartInfo\(\)`\.
The second purpose doesn’t tell you anything you don’t already know, since you are the one who passed the parameters to the`Start`method in the first place\. If they are so important to you, you can save them yourself\.
Removing the`StartInfo`avoids confusion over whether the properties in it describe the process you want to start, or whether they describe a process that has already started\. \(And often, it describes neither\!\)
I think that takes care of the largest source of confusion over the proper use of the`Process`class\.
### Category
### Topics
## Author
Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.
Similar Articles
Additional notes on controlling which handles are inherited by CreateProcess
Raymond Chen describes a technique using a helper process to precisely control which handles are inherited by a new process, avoiding accidental inheritance from other components in the same process.
Understanding the rationale behind a rule when trying to circumvent it
This article from Microsoft's Old New Thing blog explains the rationale behind best practices for Windows kernel callback functions, particularly why blocking or waiting on work items defeats their purpose, using a cautionary tale about drivers causing system hangs.
Why not have changes in API behavior depend on the SDK you link against?
The article examines the pitfalls of altering API behavior depending on the linked SDK version, using Windows' CoInitializeSecurity as a case study. It discusses issues with DLL version mismatches and tail call optimization that complicate this approach.
Writing a Debugger from Scratch
This article kicks off a series on building a debugger from scratch in Rust, starting with attaching to a Windows process using OS debugging APIs.
Improving C# Memory Safety
Microsoft announces a redesign of C#'s unsafe keyword in C# 16 to enforce memory safety contracts, making unsafe operations visible and compiler-enforced, with preview in .NET 11 and production in .NET 12.