Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen.
Übersetzung
Original
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Process.StandardError-Eigenschaft

Ruft einen Stream ab, mit dem die Fehlerausgabe der Anwendung gelesen wird.

Namespace:  System.Diagnostics
Assembly:  System (in System.dll)
[BrowsableAttribute(false)]
public StreamReader StandardError { get; }

Eigenschaftswert

Typ: System.IO.StreamReader
Ein StreamReader zum Lesen des Standardfehlerstreams der Anwendung.
Ausnahme Bedingung
InvalidOperationException

Der StandardError-Stream wurde nicht für die Umleitung definiert. Stellen Sie sicher, dass ProcessStartInfo.RedirectStandardError auf true und ProcessStartInfo.UseShellExecute auf false festgelegt ist.

- oder -

Der StandardError-Stream ist mit BeginErrorReadLine für asynchrone Lesevorgänge geöffnet worden.

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.

Hinweis Hinweis

Zum Verwenden von StandardError müssen Sie ProcessStartInfo.UseShellExecute auf false und ProcessStartInfo.RedirectStandardError auf true festlegen. Andernfalls löst das Lesen aus dem StandardError-Stream eine Ausnahme aus.

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.

HinweisHinweis

Sie können keine asynchronen und synchronen Lesevorgänge in einem umgeleiteten Stream kombinieren. Wenn der umgeleitete Stream eines Process im asynchronen oder synchronen Modus geöffnet wird, müssen alle weiteren Lesevorgänge in diesem Stream in demselben Modus ausgeführt werden. Rufen Sie z. B. nach BeginErrorReadLine nicht ReadLine für den StandardError-Stream auf oder umgekehrt. Sie können jedoch zwei verschiedene Streams in unterschiedlichen Modi lesen. Beispielsweise können Sie BeginOutputReadLine aufrufen und dann ReadLine für den StandardError-Stream aufrufen.

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.


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


.NET Framework

Unterstützt in: 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Unterstützt in: 4, 3.5 SP1
  • LinkDemand  

    für volle Vertrauenswürdigkeit für den unmittelbaren Aufrufer. Dieser Member kann nicht von teilweise vertrauenswürdigem Code verwendet werden.

Windows 7, Windows Vista SP1 oder höher, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core wird nicht unterstützt), Windows Server 2008 R2 (Server Core wird mit SP1 oder höher unterstützt), Windows Server 2003 SP2

.NET Framework unterstützt nicht alle Versionen sämtlicher Plattformen. Eine Liste der unterstützten Versionen finden Sie unter Systemanforderungen für .NET Framework.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Community-Inhalt Hinzufügen
Anmerkungen FAQ