Exportieren (0) Drucken
Alle erweitern
Dieser Artikel wurde maschinell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

ProcessStartInfo.RedirectStandardOutput-Eigenschaft

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

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

public bool RedirectStandardOutput { get; set; }

Eigenschaftswert

Typ: System.Boolean
true , wenn die Ausgabe in Process.StandardOutput geschrieben werden soll; andernfalls false. Die Standardeinstellung ist false.

Wenn ein Process Text in seinen Standardstream schreibt, wird dieser Text meist an der Konsole angezeigt. Durch Umleiten des StandardOutput-Streams können Sie die Ausgabe 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.

HinweisHinweis

Sie müssen UseShellExecute auf false festlegen, wenn Sie RedirectStandardOutput auf true festlegen möchten. Andernfalls löst das Lesen aus dem StandardOutput-Stream eine Ausnahme aus.

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

Im Gegensatz dazu startet BeginOutputReadLine asynchrone Lesevorgänge im StandardOutput-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.

HinweisHinweis

Die Anwendung, die die asynchrone Ausgabe verarbeitet, sollte die WaitForExit-Methode aufrufen, um sicherzustellen, dass der Ausgabepuffer geleert wurde.

Synchrone Lesevorgänge verursachen eine Abhängigkeit zwischen dem Aufrufer, der aus dem StandardOutput-Stream liest, und dem untergeordneten Prozess, der in diesen Stream schreibt. Diese Abhängigkeiten können Deadlockbedingungen verursachen. Wenn der Aufrufer aus dem umgeleiteten Stream eines untergeordneten Prozesses liest, ist er vom untergeordneten Element abhängig. Der Aufrufer wartet mit dem 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 den gesamten Stream gelesen hat oder den Stream schließt. Die Deadlockbedingung tritt ein, wenn der Aufrufer und der untergeordnete Prozess darauf warten, dass der jeweils andere Prozess einen Vorgang beendet 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 veranschaulicht 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 output stream of the child process.
 p.StartInfo.UseShellExecute = false;
 p.StartInfo.RedirectStandardOutput = 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 stream.
 // p.WaitForExit();
 // Read the output stream first and then wait.
 string output = p.StandardOutput.ReadToEnd();
 p.WaitForExit();

Im Codebeispiel wird eine Deadlockbedingung vermieden, indem p.StandardOutput.ReadToEnd vor p.WaitForExit aufgerufen wird. Eine Deadlockbedingung kann eintreten, wenn der übergeordnete Prozess p.WaitForExit vor p.StandardOutput.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 StandardOutput-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.


Process compiler = new Process();
compiler.StartInfo.FileName = "csc.exe";
compiler.StartInfo.Arguments = "/r:System.dll /out:sample.exe stdstr.cs";
compiler.StartInfo.UseShellExecute = false;
compiler.StartInfo.RedirectStandardOutput = true;
compiler.Start();    

Console.WriteLine(compiler.StandardOutput.ReadToEnd());

compiler.WaitForExit();


.NET Framework

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

.NET Framework Client Profile

Unterstützt in: 4, 3.5 SP1

Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core-Rolle wird nicht unterstützt), Windows Server 2008 R2 (Server Core-Rolle wird mit SP1 oder höher unterstützt; Itanium wird nicht unterstützt)

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

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2015 Microsoft