ProcessStartInfo.RedirectStandardError-Eigenschaft

Ruft einen Wert ab, der angibt, ob die Fehlerausgabe einer Anwendung in den Process.StandardError-Stream geschrieben wird, oder legt diesen fest.

Namespace: System.Diagnostics
Assembly: System (in system.dll)

Syntax

'Declaration
Public Property RedirectStandardError As Boolean
'Usage
Dim instance As ProcessStartInfo
Dim value As Boolean

value = instance.RedirectStandardError

instance.RedirectStandardError = value

public bool RedirectStandardError { get; set; }

public:
property bool RedirectStandardError {
    bool get ();
    void set (bool value);
}

/** @property */
public boolean get_RedirectStandardError ()

/** @property */
public void set_RedirectStandardError (boolean value)

public function get RedirectStandardError () : boolean

public function set RedirectStandardError (value : boolean)

Eigenschaftenwert

true, um die Fehlerausgabe in Process.StandardError zu schreiben, andernfalls false.

Hinweise

Wenn ein Process Text in seinen Standardfehlerstream schreibt, wird dieser Text normalerweise in der Konsole angezeigt. Durch Umleiten des StandardError-Streams können Sie die Fehlerausgabe eines Prozesses bearbeiten oder unterdrücken. Beispielsweise können Sie den Text filtern oder anders formatieren oder die Ausgabe sowohl in die Konsole als auch in eine festgelegte Protokolldatei schreiben.

Der umgeleitete StandardError-Stream kann synchron oder asynchron gelesen werden. Methoden wie Read, ReadLine und ReadToEnd führen synchrone Lesevorgänge im Fehlerausgabestream des Prozesses aus. Diese synchronen Lesevorgänge werden erst beendet, wenn der zugeordnete Process Daten in den StandardError-Stream schreibt oder den Stream schließt.

Im Gegensatz dazu startet BeginErrorReadLine asynchrone Lesevorgänge im StandardError-Stream. Mit dieser Methode wird ein bestimmter Ereignishandler für die Streamausgabe aktiviert und eine unmittelbare Rückgabe an den Aufrufer übergeben, der andere Aufgaben durchführen kann, während die Streamausgabe an den Ereignishandler geleitet wird.

Synchrone Lesevorgänge verursachen eine Abhängigkeit zwischen dem Aufrufer, der aus dem StandardError-Stream liest, und dem untergeordneten Prozess, der in diesen Stream schreibt. Diese Abhängigkeiten können zu Deadlockbedingungen führen. Wenn der Aufrufer aus dem umgeleiteten Stream eines untergeordneten Prozesses liest, ist er vom untergeordneten Element abhängig. Der Aufrufer wartet auf den Lesevorgang, bis das untergeordnete Element in den Stream schreibt oder den Stream schließt. Wenn der untergeordnete Prozess genug Daten schreibt, um seinen umgeleiteten Stream zu füllen, ist er vom übergeordneten Element abhängig. Der untergeordnete Prozess wartet mit dem nächsten Schreibvorgang, bis das übergeordnete Element aus dem gefüllten Stream liest oder den Stream schließt. Die Deadlockbedingung tritt ein, wenn der Aufrufer und der untergeordnete Prozess jeweils auf Beendigung eines Vorgangs warten und ein Fortfahren für beide nicht möglich ist. Sie können Deadlocks vermeiden, indem Sie Abhängigkeiten zwischen dem Aufrufer und dem untergeordnetem Prozess auswerten.

Der folgende C#-Code zeigt beispielsweise, wie aus einem umgeleiteten Stream gelesen und auf das Beenden des untergeordneten Prozesses gewartet wird.

// 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();

Im Codebeispiel wird eine Deadlockbedingung vermieden, indem p.StandardError.ReadToEnd vor p.WaitForExit aufgerufen wird. Eine Deadlockbedingung kann eintreten, wenn der übergeordnete Prozess p.WaitForExit vor p.StandardError.ReadToEnd aufruft und der untergeordnete Prozess genug Text zum Füllen des umgeleiteten Streams schreibt. Der übergeordnete Prozess würde unbegrenzt auf das Beenden des untergeordneten Prozesses warten. Der untergeordnete Prozess würde unbegrenzt warten, bis das übergeordnete Element aus dem vollen StandardError-Stream liest.

Es gibt ein ähnliches Problem, wenn Sie sämtlichen Text sowohl aus der Standardausgabe als auch aus Standardfehlerstreams lesen. Der folgende C#-Code führt z. B. einen Lesevorgang in beiden Streams aus.

 // 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();

Im Codebeispiel wird die Deadlockbedingung vermieden, indem asynchrone Lesevorgänge im StandardOutput-Stream ausgeführt werden. Eine Deadlockbedingung tritt ein, wenn der übergeordnete Prozess p.StandardOutput.ReadToEnd vor p.StandardError.ReadToEnd aufruft und der untergeordnete Prozess genug Text zum Füllen des Fehlerstreams schreibt. Der übergeordnete Prozess würde unbegrenzt warten, damit der untergeordnete Prozess seinen StandardOutput-Stream schließt. Der untergeordnete Prozess würde unbegrenzt warten, bis das übergeordnete Element aus dem vollen StandardError-Stream liest.

Sie können asynchrone Lesevorgänge verwenden, um diese Abhängigkeiten und ihr Deadlockpotenzial zu vermeiden. Die Deadlockbedingung kann auch vermieden werden, indem zwei Threads erstellt werden und die Ausgabe der einzelnen Streams in separaten Threads gelesen wird.

Beispiel

Im folgenden Beispiel wird eine Netzwerkressource durch Verwendung des net use-Befehls zusammen mit einem vom Benutzer angegebenen Argument zugeordnet. Dann wird der Standardfehlerstream des net-Befehls gelesen und in die Konsole geschrieben.

Dim myProcess As New Process()
Dim myProcessStartInfo As New ProcessStartInfo("net ", "use " + args(1))

myProcessStartInfo.UseShellExecute = False
myProcessStartInfo.RedirectStandardError = True
myProcess.StartInfo = myProcessStartInfo
myProcess.Start()

Dim myStreamReader As StreamReader = myProcess.StandardError
' Read the standard error of net.exe and write it on to console.
Console.WriteLine(myStreamReader.ReadLine())
myProcess.Close()

Process myProcess = new Process();
ProcessStartInfo myProcessStartInfo = new ProcessStartInfo("net ","use "+ args[0]);

myProcessStartInfo.UseShellExecute = false;
myProcessStartInfo.RedirectStandardError = true;
myProcess.StartInfo = myProcessStartInfo;
myProcess.Start();

StreamReader myStreamReader = myProcess.StandardError;
// Read the standard error of net.exe and write it on to console.
Console.WriteLine( myStreamReader.ReadLine());
myProcess.Close();

Process^ myProcess = gcnew Process;
ProcessStartInfo^ myProcessStartInfo = gcnew ProcessStartInfo( "net ",String::Concat( "use ", args[ 0 ] ) );

myProcessStartInfo->UseShellExecute = false;
myProcessStartInfo->RedirectStandardError = true;
myProcess->StartInfo = myProcessStartInfo;
myProcess->Start();

StreamReader^ myStreamReader = myProcess->StandardError;
// Read the standard error of net.exe and write it on to console.
Console::WriteLine( myStreamReader->ReadLine() );
myProcess->Close();

Plattformen

Windows 98, Windows 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile für Pocket PC, Windows Mobile für Smartphone, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition

.NET Framework unterstützt nicht alle Versionen sämtlicher Plattformen. Eine Liste der unterstützten Versionen finden Sie unter Systemanforderungen.

Versionsinformationen

.NET Framework

Unterstützt in: 2.0, 1.1, 1.0

Siehe auch

Referenz

ProcessStartInfo-Klasse
ProcessStartInfo-Member
System.Diagnostics-Namespace
UseShellExecute
Process.StandardError-Eigenschaft