dotnet / dotnet/dotnet-api-docs

Documentation missing for ProcessStartInfo.RedirectStandardOutput

Aperta Adatta ai principianti
#1,122 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub
area-System.Diagnostics.Process cross-platform dotnet-api/prod example-request Pri2 waiting-on-feedback
Lingua principale
C#
Stelle
949
Fork
1.7k
Merge medio
2g 19h
PR unite (30g)
52

Descrizione

This issue is created in reference to my corefx issue [here](https://github.com/dotnet/corefx/issues/21119) and SO issue [here](https://stackoverflow.com/questions/44467762/disposing-contents-of-stdout/44580472), which did not receive an answer in days. I then decided to experiment on my own. A copy is given below.

I'm not sure if the dotnet team has access to the docs [here](https://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.redirectstandardoutput(v=vs.110).aspx), but since it applies to .NET Core as well, it could be updated to clarify my use case below and potentially mention the 64k buffer size.

**QUESTION**
I am writing an application to manage processes and handle failovers. This program is written in C# for .NET Core and will run on Ubuntu Server 16.04 x64.

I have this code to create processes and track them, with exit events and such

```c#
ProcessStartInfo psi = new ProcessStartInfo
{
WorkingDirectory = "/home/xyzserver/someprocess",
FileName = "mono",
Arguments = "someprocess.exe",
RedirectStandardOutput = true
};

_proc = Process.Start(psi);
_proc.EnableRaisingEvents = true;
_proc.Exited += ProcOnExited;
```

I understand from the docs [here](https://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput(v=vs.110).aspx) that calls to Console.WriteLine will block if the _proc.StandardOutput stream is full. I want to prevent this behavior and dispose all the output from the managed application, since it will also write to a physical log on its own.

In addition, I would like to avoid storing any of the output in any unused stream buffers since they will never be used. A preferred solution will not UseShellExecute.

I have considered adding these 2 lines in the hope that any received data will be disposed, but am unsure about correctness.

```c#
_proc.OutputDataReceived += (sender, eventArgs) => {};
_proc.BeginOutputReadLine();
```

**SOLUTION**
I manually ran the test on .NET Core using 3 programs:

```
1. An HTTP server to track the *TextOutputter* program.
2. A TextOutputter program that prints 1000 characters and makes an HTTP request every second.
3. a ProgramRunner that runs one instance of TextOutputter.
```

Without the 2 lines, the buffer fills upto 64k and stalls. With the 2 lines, there is no stalling.

---
#### Document Details

⚠ *Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.*

* ID: 3991f67b-8387-5ae5-2f0a-782466233ed6
* Version Independent ID: 843917c4-f01e-5baa-454c-52a8d011bd89
* Content: [ProcessStartInfo.RedirectStandardOutput Property (System.Diagnostics)](https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.processstartinfo.redirectstandardoutput?view=netframework-4.7.2#System_Diagnostics_ProcessStartInfo_RedirectStandardOutput)
* Content Source: [xml/System.Diagnostics/ProcessStartInfo.xml](https://github.com/dotnet/dotnet-api-docs/blob/master/xml/System.Diagnostics/ProcessStartInfo.xml)
* Product: **dotnet-api**
* GitHub Login: @dotnet-bot
* Microsoft Alias: **dotnetcontent**

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia da xml/System.Diagnostics/ProcessStartInfo.xml e dalla pagina API collegata RedirectStandardOutput. Esamina le indicazioni esistenti insieme all'esempio C# e ai risultati degli esperimenti dell'issue, quindi aggiorna la documentazione per spiegare il comportamento rilevante nella gestione dell'output e la considerazione relativa al buffer. Il lavoro è completato quando la pagina della proprietà tratta chiaramente questo caso d'uso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
csharp
Ambito
documentation
Tipo di issue
Documentazione
Difficoltà
2/5
Tempo stimato
1-3 ore
Stato di attività
Ferma
Chiarezza
Specificata chiaramente
Idoneità per principianti
62/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.