Gets or sets a value that indicates whether the error output of an application is written to the Process.StandardError stream.
Documentation for this section has not yet been entered.
When a System.Diagnostics.Process writes text to its standard error stream, that text is typically displayed on the console. By redirecting the Process.StandardError stream, you can manipulate or suppress the error output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file.
You must set ProcessStartInfo.UseShellExecute to false if you want to set ProcessStartInfo.RedirectStandardError to true. Otherwise, reading from the Process.StandardError stream throws an exception.
The redirected Process.StandardError stream can be read synchronously or asynchronously. Methods such as System.IO.StreamReader.Read, System.IO.StreamReader.ReadLine and System.IO.StreamReader.ReadToEnd perform synchronous read operations on the error output stream of the process. These synchronous read operations do not complete until the associated System.Diagnostics.Process writes to its Process.StandardError stream, or closes the stream.
In contrast, Process.BeginErrorReadLine starts asynchronous read operations on the Process.StandardError stream. This method enables a designated event handler for the stream output and immediately returns to the caller, which can perform other work while the stream output is directed to the event handler.
The application that is processing the asynchronous output should call the Process.WaitForExit method to ensure that the output buffer has been flushed.
Synchronous read operations introduce a dependency between the caller reading from the Process.StandardError stream and the child process writing to that stream. These dependencies can cause deadlock conditions. When the caller reads from the redirected stream of a child process, it is dependent on the child. The caller waits for the read operation until the child writes to the stream or closes the stream. When the child process writes enough data to fill its redirected stream, it is dependent on the parent. The child process waits for the next write operation until the parent reads from the full stream or closes the stream. The deadlock condition results when the caller and child process wait for each other to complete an operation, and neither can continue. You can avoid deadlocks by evaluating dependencies between the caller and child process.
For example, the following C# code shows how to read from a redirected stream and wait for the child process to exit.
Example
// Start the child process. Process p = new Process(); // Redirect the error stream of the child process. p.StartInfo.UseShellExecute = false; p.StartInfo.RedirectStandardError = true; p.StartInfo.FileName = "Write500Lines.exe"; p.Start(); // Do not wait for the child process to exit before // reading to the end of its redirected error stream. // p.WaitForExit(); // Read the error stream first and then wait. string error = p.StandardError.ReadToEnd(); p.WaitForExit();
The code example avoids a deadlock condition by calling p.StandardError.ReadToEnd before p.WaitForExit. A deadlock condition can result if the parent process calls p.WaitForExit before p.StandardError.ReadToEnd and the child process writes enough text to fill the redirected stream. The parent process would wait indefinitely for the child process to exit. The child process would wait indefinitely for the parent to read from the full Process.StandardError stream.
There is a similar issue when you read all text from both the standard output and standard error streams. For example, the following C# code performs a read operation on both streams.
Example
// Do not perform a synchronous read to the end of both // redirected streams. // string output = p.StandardOutput.ReadToEnd(); // string error = p.StandardError.ReadToEnd(); // p.WaitForExit(); // Use asynchronous read operations on at least one of the streams. p.BeginOutputReadLine(); string error = p.StandardError.ReadToEnd(); p.WaitForExit();
The code example avoids the deadlock condition by performing asynchronous read operations on the Process.StandardOutput stream. A deadlock condition results if the parent process calls p.StandardOutput.ReadToEnd followed by p.StandardError.ReadToEnd and the child process writes enough text to fill its error stream. The parent process would wait indefinitely for the child process to close its Process.StandardOutput stream. The child process would wait indefinitely for the parent to read from the full Process.StandardError stream.
You can use asynchronous read operations to avoid these dependencies and their deadlock potential. Alternately, you can avoid the deadlock condition by creating two threads and reading the output of each stream on a separate thread.