ProcessStartInfo suspendus sur “WaitForExit”? Pourquoi?

Le problème est que si vous rediriger StandardOutput et/ou StandardError la mémoire tampon interne peut devenir complet. Quelle que soit la commande que vous utilisez, il peut être un problème:

• Si vous attendez que le processus de sortie avant de lire StandardOutput le processus peut bloquer à essayer d'écrire, de sorte que le processus ne se termine jamais.
• Si vous lisez de la StandardOutput à l'aide de ReadToEnd puis votre processus peut bloquer si le processus ne se referme jamais StandardOutput (par exemple si elle ne se termine, ou si elle est bloquée par écrit à StandardError).

La solution est d'utiliser asynchrone lit pour s'assurer que le tampon de ne pas obtenir le plein. Pour éviter toute blocages et de recueillir toutes les données de sortie à partir de deux StandardOutput et StandardError vous pouvez faire ceci:

EDIT: Voir les réponses ci-dessous pour savoir comment éviter une ObjectDisposedException si le délai d'attente se produit.

using (Process process = new Process())
{
    process.StartInfo.FileName = filename;
    process.StartInfo.Arguments = arguments;
    process.StartInfo.UseShellExecute = false;
    process.StartInfo.RedirectStandardOutput = true;
    process.StartInfo.RedirectStandardError = true;

    StringBuilder output = new StringBuilder();
    StringBuilder error = new StringBuilder();

    using (AutoResetEvent outputWaitHandle = new AutoResetEvent(false))
    using (AutoResetEvent errorWaitHandle = new AutoResetEvent(false))
    {
        process.OutputDataReceived += (sender, e) => {
            if (e.Data == null)
            {
                outputWaitHandle.Set();
            }
            else
            {
                output.AppendLine(e.Data);
            }
        };
        process.ErrorDataReceived += (sender, e) =>
        {
            if (e.Data == null)
            {
                errorWaitHandle.Set();
            }
            else
            {
                error.AppendLine(e.Data);
            }
        };

        process.Start();

        process.BeginOutputReadLine();
        process.BeginErrorReadLine();

        if (process.WaitForExit(timeout) &&
            outputWaitHandle.WaitOne(timeout) &&
            errorWaitHandle.WaitOne(timeout))
        {
            //Process completed. Check process.ExitCode here.
        }
        else
        {
            //Timed out.
        }
    }
}

Marque Byers réponse est excellente, mais je voudrais juste ajouter les éléments suivants: la OutputDataReceived et ErrorDataReceived délégués doivent être supprimés avant la outputWaitHandle et errorWaitHandle sont disposées. Si le processus se poursuit pour la sortie des données après le délai a été dépassé et puis s'arrête, le outputWaitHandle et errorWaitHandle variables seront accessibles après avoir été éliminés.

(Pour info j'ai dû ajouter cette mise en garde comme une réponse que je n'ai pas de commentaires sur son post.)

C'est un plus moderne awaitable, Task Parallel Library (TPL) en fonction de la solution pour .NET 4.5 et supérieur.

Exemple D'Utilisation

try
{
    var exitCode = await StartProcess(
        "dotnet", 
        "--version", 
        @"C:\",
        10000, 
        Console.Out, 
        Console.Out);
    Console.WriteLine($"Process Exited with Exit Code {exitCode}!");
}
catch (TaskCanceledException)
{
    Console.WriteLine("Process Timed Out!");
}

Mise en œuvre

public static async Task<int> StartProcess(
string filename,
string arguments,
string workingDirectory= null,
int? timeout = null,
TextWriter outputTextWriter = null,
TextWriter errorTextWriter = null)
{
using (var process = new Process()
{
StartInfo = new ProcessStartInfo()
{
CreateNoWindow = true,
Arguments = arguments,
FileName = filename,
RedirectStandardOutput = outputTextWriter != null,
RedirectStandardError = errorTextWriter != null,
UseShellExecute = false,
WorkingDirectory = workingDirectory
}
})
{
process.Start();
var cancellationTokenSource = timeout.HasValue ?
new CancellationTokenSource(timeout.Value) :
new CancellationTokenSource();
var tasks = new List<Task>(3) { process.WaitForExitAsync(cancellationTokenSource.Token) };
if (outputTextWriter != null)
{
tasks.Add(ReadAsync(
x =>
{
process.OutputDataReceived += x;
process.BeginOutputReadLine();
},
x => process.OutputDataReceived -= x,
outputTextWriter,
cancellationTokenSource.Token));
}
if (errorTextWriter != null)
{
tasks.Add(ReadAsync(
x =>
{
process.ErrorDataReceived += x;
process.BeginErrorReadLine();
},
x => process.ErrorDataReceived -= x,
errorTextWriter,
cancellationTokenSource.Token));
}
await Task.WhenAll(tasks);
return process.ExitCode;
}
}
///<summary>
///Waits asynchronously for the process to exit.
///</summary>
///<param name="process">The process to wait for cancellation.</param>
///<param name="cancellationToken">A cancellation token. If invoked, the task will return
///immediately as cancelled.</param>
///<returns>A Task representing waiting for the process to end.</returns>
public static Task WaitForExitAsync(
this Process process,
CancellationToken cancellationToken = default(CancellationToken))
{
process.EnableRaisingEvents = true;
var taskCompletionSource = new TaskCompletionSource<object>();
EventHandler handler = null;
handler = (sender, args) =>
{
process.Exited -= handler;
taskCompletionSource.TrySetResult(null);
};
process.Exited += handler;
if (cancellationToken != default(CancellationToken))
{
cancellationToken.Register(
() =>
{
process.Exited -= handler;
taskCompletionSource.TrySetCanceled();
});
}
return taskCompletionSource.Task;
}
///<summary>
///Reads the data from the specified data recieved event and writes it to the
///<paramref name="textWriter"/>.
///</summary>
///<param name="addHandler">Adds the event handler.</param>
///<param name="removeHandler">Removes the event handler.</param>
///<param name="textWriter">The text writer.</param>
///<param name="cancellationToken">The cancellation token.</param>
///<returns>A task representing the asynchronous operation.</returns>
public static Task ReadAsync(
this Action<DataReceivedEventHandler> addHandler,
Action<DataReceivedEventHandler> removeHandler,
TextWriter textWriter,
CancellationToken cancellationToken = default(CancellationToken))
{
var taskCompletionSource = new TaskCompletionSource<object>();
DataReceivedEventHandler handler = null;
handler = new DataReceivedEventHandler(
(sender, e) =>
{
if (e.Data == null)
{
removeHandler(handler);
taskCompletionSource.TrySetResult(null);
}
else
{
textWriter.WriteLine(e.Data);
}
});
addHandler(handler);
if (cancellationToken != default(CancellationToken))
{
cancellationToken.Register(
() =>
{
removeHandler(handler);
taskCompletionSource.TrySetCanceled();
});
}
return taskCompletionSource.Task;
}

Nous avons ce problème aussi bien (ou une variante).

Essayez ce qui suit:

1) Ajouter un délai d'attente de p.WaitForExit(nnnn); où nnnn est en millisecondes.

2) Mettre le ReadToEnd appel avant que le WaitForExit appel. Cette est ce que nous avons vu MME recommander.

Je l'ai résolu de cette façon:

            Process proc = new Process();
proc.StartInfo.FileName = batchFile;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.RedirectStandardError = true;
proc.StartInfo.RedirectStandardInput = true;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;      
proc.Start();
StreamWriter streamWriter = proc.StandardInput;
StreamReader outputReader = proc.StandardOutput;
StreamReader errorReader = proc.StandardError;
while (!outputReader.EndOfStream)
{
string text = outputReader.ReadLine();                    
streamWriter.WriteLine(text);
}
while (!errorReader.EndOfStream)
{                   
string text = errorReader.ReadLine();
streamWriter.WriteLine(text);
}
streamWriter.Close();
proc.WaitForExit();

J'ai redirigé la fois d'entrée, de sortie et d'erreur et manipulés lecture à partir de la sortie d'erreur et de flux.
Cette solution fonctionne pour SDK 7 - 8.1, à la fois pour Windows 7 et Windows 8

J'ai essayé de faire une classe qui permettrait de résoudre votre problème à l'aide asynchrone flux en lecture, en tenant compte de la Marque Byers, Rob, stevejay réponses. Ce faisant, j'ai réalisé qu'il y est un bug lié au processus asynchrone flux de sortie en lecture.

J'ai signalé ce bug chez Microsoft: https://connect.microsoft.com/VisualStudio/feedback/details/3119134

Résumé:

Vous ne pouvez pas le faire:

processus.BeginOutputReadLine(); process.Start();

Vous recevrez Système.InvalidOperationException : StandardOut a
pas été réexpédiés ou le processus n'a pas encore commencé.

============================================================================================================================

Alors vous devez commencer asynchrone sortie lire après le processus est
commencé:

processus.Start(); process.BeginOutputReadLine();

Faire, faire une course en l'état car le flux de sortie peut recevoir
les données avant de vous le mettre en asynchrone:

process.Start(); 
//Here the operating system could give the cpu to another thread.  
//For example, the newly created thread (Process) and it could start writing to the output
//immediately before next line would execute. 
//That create a race condition.
process.BeginOutputReadLine();

============================================================================================================================

Alors certaines personnes pourraient dire que vous avez juste à lire le flux
avant de vous le mettre en asynchrone. Mais le même problème se produit. Il y
sera une condition de concurrence entre la lecture synchrone et définir les
flux de données en mode asynchrone.

============================================================================================================================

Il n'existe aucun moyen pour réaliser la sécurité asynchrone lecture d'un flux de sortie
d'un processus à la manière de "Processus" et "ProcessStartInfo" a
été conçu.

Vous êtes probablement mieux à l'aide de lecture asynchrone comme suggéré par d'autres utilisateurs de votre cas. Mais vous devez être conscient que vous pourriez manquer des informations en raison de la condition de course.

Introduction

Actuellement accepté de répondre ne fonctionne pas (throws exception) et il y a aussi beaucoup de solutions de contournement, mais pas de code complet. C'est évidemment de perdre beaucoup de temps, car c'est une question populaire.

Combinant la Marque Byers réponse et Karol Tyl réponse, j'ai écrit plein de code basé sur la façon dont je veux utiliser le Processus.Méthode de démarrage.

Utilisation

Je l'ai utilisé pour créer la boîte de dialogue de progression autour de commandes git. C'est de cette façon que j'ai utilisé:

    private bool Run(string fullCommand)
{
Error = "";
int timeout = 5000;
var result = ProcessNoBS.Start(
filename: @"C:\Program Files\Git\cmd\git.exe",
arguments: fullCommand,
timeoutInMs: timeout,
workingDir: @"C:\test");
if (result.hasTimedOut)
{
Error = String.Format("Timeout ({0} sec)", timeout/1000);
return false;
}
if (result.ExitCode != 0)
{
Error = (String.IsNullOrWhiteSpace(result.stderr)) 
? result.stdout : result.stderr;
return false;
}
return true;
}

En théorie, vous pouvez également combiner stdout et stderr, mais je n'ai pas testé.

Code

public struct ProcessResult
{
public string stdout;
public string stderr;
public bool hasTimedOut;
private int? exitCode;
public ProcessResult(bool hasTimedOut = true)
{
this.hasTimedOut = hasTimedOut;
stdout = null;
stderr = null;
exitCode = null;
}
public int ExitCode
{
get 
{
if (hasTimedOut)
throw new InvalidOperationException(
"There was no exit code - process has timed out.");
return (int)exitCode;
}
set
{
exitCode = value;
}
}
}
public class ProcessNoBS
{
public static ProcessResult Start(string filename, string arguments,
string workingDir = null, int timeoutInMs = 5000,
bool combineStdoutAndStderr = false)
{
using (AutoResetEvent outputWaitHandle = new AutoResetEvent(false))
using (AutoResetEvent errorWaitHandle = new AutoResetEvent(false))
{
using (var process = new Process())
{
var info = new ProcessStartInfo();
info.CreateNoWindow = true;
info.FileName = filename;
info.Arguments = arguments;
info.UseShellExecute = false;
info.RedirectStandardOutput = true;
info.RedirectStandardError = true;
if (workingDir != null)
info.WorkingDirectory = workingDir;
process.StartInfo = info;
StringBuilder stdout = new StringBuilder();
StringBuilder stderr = combineStdoutAndStderr
? stdout : new StringBuilder();
var result = new ProcessResult();
try
{
process.OutputDataReceived += (sender, e) =>
{
if (e.Data == null)
outputWaitHandle.Set();
else
stdout.AppendLine(e.Data);
};
process.ErrorDataReceived += (sender, e) =>
{
if (e.Data == null)
errorWaitHandle.Set();
else
stderr.AppendLine(e.Data);
};
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
if (process.WaitForExit(timeoutInMs))
result.ExitCode = process.ExitCode;
//else process has timed out 
//but that's already default ProcessResult
result.stdout = stdout.ToString();
if (combineStdoutAndStderr)
result.stderr = null;
else
result.stderr = stderr.ToString();
return result;
}
finally
{
outputWaitHandle.WaitOne(timeoutInMs);
errorWaitHandle.WaitOne(timeoutInMs);
}
}
}
}
}

Après la lecture de tous les posts ici, je me suis installé sur les états solution de Marko Avlijaš.
Cependant, il n'a pas de résoudre tous mes problèmes.

Dans notre environnement, nous avons un Service Windows qui est planifiée pour s'exécuter à des centaines de .chauve-souris .cmd .exe,... etc. les fichiers qui ont accumulé au fil des ans et ont été écrits par de nombreuses personnes différentes et dans des styles différents. Nous n'avons aucun contrôle sur l'écriture des programmes & des scripts, nous sommes responsable de la planification, l'exécution, et des rapports sur les succès/échec.

Donc j'ai essayé à peu près toutes les suggestions ici avec différents niveaux de succès. Marko réponse était presque parfait, mais lorsqu'il est exécuté en tant que service, il n'a pas toujours de saisir la sortie standard stdout. Je n'ai jamais pu le bas de la pourquoi pas.

La seule solution que nous avons trouvé qui fonctionne dans TOUS nos cas, est-ce : http://csharptest.net/319/using-the-processrunner-class/index.html

J'chose que ce qui est simple et la meilleure approche (nous n'avons pas besoin AutoResetEvent):

public static string GGSCIShell(string Path, string Command)
{
using (Process process = new Process())
{
process.StartInfo.WorkingDirectory = Path;
process.StartInfo.FileName = Path + @"\ggsci.exe";
process.StartInfo.CreateNoWindow = true;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardInput = true;
process.StartInfo.UseShellExecute = false;
StringBuilder output = new StringBuilder();
process.OutputDataReceived += (sender, e) =>
{
if (e.Data != null)
{
output.AppendLine(e.Data);
}
};
process.Start();
process.StandardInput.WriteLine(Command);
process.BeginOutputReadLine();
int timeoutParts = 10;
int timeoutPart = (int)TIMEOUT / timeoutParts;
do
{
Thread.Sleep(500);//sometimes halv scond is enough to empty output buff (therefore "exit" will be accepted without "timeoutPart" waiting)
process.StandardInput.WriteLine("exit");
timeoutParts--;
}
while (!process.WaitForExit(timeoutPart) && timeoutParts > 0);
if (timeoutParts <= 0)
{
output.AppendLine("------ GGSCIShell TIMEOUT: " + TIMEOUT + "ms ------");
}
string result = output.ToString();
return result;
}
}

Nous rappelons l'exemple de code posté ici le redirecteur et l'autre programme de la redirection. Si c'était moi, alors je serais probablement écrire un test redirigé programme qui peut être utilisé pour reproduire le problème.

Je l'ai fait. Pour les données de test, j'ai utilisé le ECMA-334 Langage C# Specificationv PDF; il est d'environ 5 MO. Ce qui suit est la partie importante.

StreamReader stream = null;
try { stream = new StreamReader(Path); }
catch (Exception ex)
{
Console.Error.WriteLine("Input open error: " + ex.Message);
return;
}
Console.SetIn(stream);
int datasize = 0;
try
{
string record = Console.ReadLine();
while (record != null)
{
datasize += record.Length + 2;
record = Console.ReadLine();
Console.WriteLine(record);
}
}
catch (Exception ex)
{
Console.Error.WriteLine($"Error: {ex.Message}");
return;
}

La données. datasize valeur ne correspond pas à la taille réelle du fichier, mais qui n'a pas d'importance. Il n'est pas clair si un fichier PDF utilise toujours les deux CR et LF à la fin des lignes, mais qui n'a pas d'importance pour cela. Vous pouvez utiliser tout autre fichier texte afin de le tester.

À l'aide de l'exemple de code de redirection se bloque quand j'écris de la grande quantité de données, mais pas quand j'écris une petite quantité.

J'ai essayé beaucoup de quelque sorte de tracer l'exécution de ce code et je ne pouvais pas. J'ai commenté les lignes du programme de redirection personnes handicapées de la création d'une console pour la redirection de programme pour essayer d'obtenir une seconde fenêtre de la console, mais je ne pouvais pas.

Puis j'ai trouvé Comment faire pour démarrer une application console dans une nouvelle fenêtre, le parent de la fenêtre ou sans fenêtre. Donc, apparemment, nous ne pouvons pas (facilement) ont une console séparée lorsqu'un programme console démarre un autre programme de console sans ShellExecute et depuis ShellExecute ne prend pas en charge la redirection de nous devons partager une console, même si l'on précise pas de fenêtre pour les autres processus.

Je suppose que si la redirection de programme remplit un tampon quelque part, alors il faut attendre pour que les données puissent être lues et si aucune donnée n'est lu que par le redirecteur c'est une impasse.

La solution est de ne pas utiliser ReadToEnd et à lire les données tandis que les données est en train d'être écrit, mais il n'est pas nécessaire d'utiliser des lectures asynchrones. La solution peut être assez simple. Les ouvrages suivants, pour moi le 5 MB PDF.

ProcessStartInfo info = new ProcessStartInfo(TheProgram);
info.CreateNoWindow = true;
info.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
info.RedirectStandardOutput = true;
info.UseShellExecute = false;
Process p = Process.Start(info);
string record = p.StandardOutput.ReadLine();
while (record != null)
{
Console.WriteLine(record);
record = p.StandardOutput.ReadLine();
}
p.WaitForExit();

Une autre possibilité est d'utiliser un programme graphique pour faire de la redirection. Le code précédent fonctionne dans une application WPF à l'exception évidente des modifications.