Outputdatareceived waitforexit

Exemplo de uso.

Resolvi assim:

Eu redirecionava a entrada, a saída e o erro e administrai a leitura dos fluxos de saída e erro. Esta solução funciona para o SDK 7- 8.1, tanto para o Windows 7 como para o Windows 8.

Eu tentei fazer uma aula que resolva seu problema usando a leitura de fluxo assíncrono, levando em conta Mark Byers, Rob, Stevejay responde. Ao fazê-lo, percebi que existe um erro relacionado à leitura assíncrona do fluxo de saída do processo.

Você não pode fazer isso:

Você receberá System. InvalidOperationException: StandardOut não foi redirecionado ou o processo ainda não começou.

Então, você deve iniciar a saída assíncrona lida após o processo ser iniciado:

Fazendo isso, faça uma condição de corrida porque o fluxo de saída pode receber dados antes de configurá-lo como assíncrono:

Então algumas pessoas podem dizer que você só precisa ler o fluxo antes de configurá-lo como assíncrono. Mas o mesmo problema ocorre. Haverá uma condição de corrida entre a leitura síncrona e configurará o fluxo em modo assíncrono.

Não há como conseguir uma leitura assíncrona segura de um fluxo de saída de um processo na forma real "Processo" e "ProcessStartInfo" foi projetado.

Você provavelmente está melhor usando a leitura assíncrona, como sugerido por outros usuários para o seu caso. Mas você deve estar ciente de que você pode perder algumas informações devido à condição de corrida.

Nenhuma das respostas acima está fazendo o trabalho.

A solução Rob trava e a solução 'Mark Byers' obtém a exceção descarta. (Eu tentei as "soluções" das outras respostas).

Então eu decidi sugerir outra solução:

Este código é depurado e funciona perfeitamente.

Introdução.

A resposta atualmente aceita não funciona (lança exceção) e há muitas soluções alternativas, mas nenhum código completo. Isso é, obviamente, desperdiçando muito tempo das pessoas porque esta é uma questão popular.

Combinando a resposta de Mark Byers e a resposta de Karol Tyl, escrevi um código completo baseado em como eu quero usar o método Process. Start.

Eu usei-o para criar um diálogo de progresso em torno dos comandos git. É assim que eu usei isso:

Em teoria, você também pode combinar stdout e stderr, mas não testei isso.

As outras soluções (incluindo o EM0) ainda estão bloqueadas para o meu aplicativo, devido a tempos de espera internos e ao uso de StandardOutput e StandardError pela aplicação gerada. Aqui está o que funcionou para mim:

Editar: inicialização adicionada de StartInfo para codificar a amostra.

Este post talvez esteja desactualizado, mas descobri a principal causa por que normalmente ele trava é devido ao excesso de pilha para o redirectStandardoutput ou se você tem redirectStandarderror.

Como os dados de saída ou os dados de erro são grandes, isso causará um tempo de espera, pois ele ainda está processando por tempo indefinido.

para resolver esse problema:

Eu acho que isso é uma abordagem simples e melhor (não precisamos do AutoResetEvent):

Eu estava tendo o mesmo problema, mas a razão era diferente. No entanto, isso aconteceria no Windows 8, mas não no Windows 7. A seguinte linha parece ter causado o problema.

A solução era NÃO desativar UseShellExecute. Agora recebi uma janela popup do Shell, que é indesejável, mas muito melhor do que o programa esperando que nada de particular aconteça. Então eu adicionei o seguinte trabalho para isso:

Agora, o único problema que me incomoda é o porquê isso está acontecendo no Windows 8, em primeiro lugar.

Eu sei que isso é velho, mas, depois de ler toda essa página, nenhuma das soluções estava funcionando para mim, embora eu não tentei Muhammad Rehan porque o código era um pouco difícil de seguir, embora eu acho que ele estava no caminho certo . Quando eu digo que não funcionou, isso não é inteiramente verdade, às vezes funcionaria bem, acho que é algo a ver com a duração da saída antes de uma marca EOF.

De qualquer forma, a solução que funcionou para mim era usar diferentes threads para ler o StandardOutput e StandardError e escrever as mensagens.

Espero que isso ajude alguém, que pensou que isso poderia ser tão difícil!

Depois de ler todos os posts aqui, resolvi a solução consolidada de Marko Avlijaš. No entanto, não resolveu todos os meus problemas.

Em nosso ambiente, temos um Serviço do Windows que está programado para executar centenas de diferentes. bat. cmd. exe. etc arquivos que se acumularam ao longo dos anos e foram escritas por muitas pessoas diferentes e em diferentes estilos. Não temos controle sobre a redação dos programas e programas; scripts, somos apenas responsáveis ​​pelo agendamento, execução e relatórios sobre o sucesso / falha.

Então eu tentei praticamente todas as sugestões aqui com diferentes níveis de sucesso. A resposta de Marko foi quase perfeita, mas quando executado como um serviço, ele nem sempre captou stdout. Nunca cheguei ao fundo do porquê não.

Como usar System. Diagnostics. Process corretamente.

Eu vi muitas perguntas no stackoverflow e em outros lugares sobre a execução de um processo e a captura da saída. Usar o System. Diagnostics. Process corretamente não é fácil e, na maioria das vezes, ele está errado.

Alguns erros comuns com System. Diagnostics. Process:

Não capturar os dois fluxos de saída (erro e saída) Não redirecionar a entrada pode fazer com que os aplicativos travem Não fechar entrada redirecionada pode fazer com que os aplicativos travem Não chamar BeginOutputReadLine / BeginErrorReadLine ao usar eventos Usar OutputDataReceived / ErrorDataReceived sem aguardar null Não verificar null em OutputDataReceived / ErrorDataReceived handlers Esquecendo de setar EnableRaisingEvents = true; ao usar o evento Exitado, esquecer as configurações de ErrorDialog, CreateNoWindow ou UseShellExecute Manipulação incorreta dos leitores de fluxo StandardOutput ou StandardError.

Então, com isso disse, aqui estão algumas diretrizes básicas:

Use os eventos OutputDataReceived / ErrorDataRecieved NOT, StandardOutput ou StandardError. Isso irá poupar-lhe muita dor de cabeça e gerenciamento de threads desnecessário. Sempre capture todas as saídas E entradas, se você não planeja fornecer entrada, feche o fluxo imediatamente. Seu processo não é feito até que ele tenha saído E você leu todos os dados. OutputDataReceived CAN AND SERÁ disparado após uma chamada para WaitForExit () retorna. Você precisará de alças de espera para cada fluxo de saída e defina o controle de espera depois de receber os dados de recebimento (nulo).

Herança Múltipla.

Derivado de muitas coisas.

Process. WaitForExit e. Exited event aren & # 8217; t working?

. NET System. Diagnostics. Process Class & # 8211; Parte 1.

Process. WaitForExit e. Exited event aren & # 8217; t working? Eu pensei que tinha achado que isso era o caso - mas foi minha culpa, provavelmente o mesmo para você também. Eu examinarei o que encontrei ao explorar e resolver esse problema.

Resposta curta: Se você estiver redirecionando StandardOutput e / ou StandardError, use melhor os métodos assíncronos Process. BeginErrorReadLine () e. BeginOutputReadLine () ANTES de chamar. WaitForExit () e capture a saída enganchando os eventos Process. ErrorDataReceived e. OutputDataReceived.

A resposta longa começa comigo usando o Visual Studio diffmerge. exe na pasta Common7 / IDE para comparar arquivos de texto no modo de lote. Estou apresentando um teste de regressão em um processo de lote iniciado por compilação. Eu precisava de uma ferramenta que cuspiria um arquivo de diferença de texto ao comparar dois arquivos (não um arquivo de resultado de mesclagem). O WinMerge e a Beyond Compare estão à minha disposição, mas eles não parecem produzir nada além de resultados mesclados (o que normalmente é o que eu quero, mas não desta vez).

Minha estrutura de regressão chamará diffmerge. exe e armazenará o arquivo diff resultante para posterior revisão. Eu codifiquei meu ProcessStartInfo…

Seguiu-se com o início do processo e aguardando que o processo terminasse ... e esperando ... espere esperando ....

Isso me fez ler o MSDN e aprofundar o uso da classe Process. Eu descobri algumas informações interessantes, provavelmente deveria ter sido óbvio.

Primeiro, descobri que, às vezes, executar meu processo filho do diffmerge com diferentes argumentos funcionava, às vezes não, tornando o problema misterioso.

Em segundo lugar, descobri que funcionava bem quando eu não redirecionava a saída.

Então, obviamente, eu estava perdendo alguma coisa. Eu precisava ler os documentos da Process API e, assim, encontrei este nugget: Artigo do MSDN.

Depois de encontrar e ler esse artigo do MSDN, entendi. O meu exemplo de código acima funcionará se o buffer StdOut ou StdError não preencher. No entanto, o que eu estava vendo foi o buffer StdOut sendo preenchido, o processo filho foi bloqueado na próxima gravação StdOut / StdError, o processo pai estava aguardando infinitamente no processo filho para sair antes de ler o buffer StdOut / StdError. Para mim, parecia que o método WaitForExit e / ou o evento Exited estão quebrados / não apanhando o processo filho que sai, no entanto, era meu código que estava quebrado.

Eu modifiquei o código para usar os métodos assíncronos e, de repente, meus problemas desapareceram. Não há mais bloqueio, tudo funcionou conforme o esperado.

Eu usei StringBuilders como buffers para armazenar os dados recebidos nos eventos.

Na parte 2, me deparo com um problema com as implementações de ReadLine do Processo StdOut / StdError em torno de minhas necessidades específicas, discuto como resolvi esse problema.

processstartinfo pendurado em waitforexit porque.

Eu realmente tenho o próximo código:

info = new System. Diagnostics. ProcessStartInfo ("TheProgram. exe", String. Join ("", args)); info. CreateNoWindow = true; info. WindowStyle = System. Diagnostics. ProcessWindowStyle. Hidden; info. RedirectStandardOutput = true; info. UseShellExecute = false; System. Diagnostics. Process = System. Diagnostics. Process. Start (info); p. WaitForExit (); Console. WriteLine (p. StandardOutput. ReadToEnd ()); // precisa do conteúdo do StandardOutput.

Eu entendo que a saída do método que estou começando é redonda de 7MB de duração. Executá-lo dentro do console do Windows funciona de alta qualidade. Infelizmente, programaticamente, isso trava indefinidamente no WaitForExit. Observe, além disso, que o código não seja compatível com saídas menores (como 3KB).

É imaginável que o StandardOutput interior em ProcessStartInfo não pode armazenar 7MB? Se sim, o que devo fazer como substituto? Caso contrário, o que estou falhando?

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

O problema é que, para aqueles que redirecionam StandardOutput e / ou StandardError, o buffer interno pode se tornar completo. Qualquer ordem que você empregue, pode haver um problema:

Se você esperar que o processo saia antes de ler StandardOutput, o processo pode bloquear a tentativa de gravar nele, de modo que o processo nunca termine. Se você lê o StandardOutput usando o ReadToEnd, seu processo pode bloquear se o processo nunca fecha o StandardOutput (por exemplo, se ele nunca termina ou se está bloqueado a escrever para o StandardError).

A resposta é usar leituras assíncronas para ter certeza de que o buffer não está cheio. Para evitar quaisquer impasses e acumular todas as saídas de cada StandardOutput e StandardError, faça o seguinte:

EDIT: Veja as soluções abaixo para lidar com o tempo limite e evite as exceções & lt; robust & gt; ObjectDisposeException.

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

A documentação para Process. StandardOutput diz para aprender mais cedo do que você espera diferentemente você vai impasse, trecho copiado abaixo:

// Iniciar o processo filho. Processo p = novo Processo (); // Redirecione o fluxo de saída do processo filho. p. StartInfo. UseShellExecute = false; p. StartInfo. RedirectStandardOutput = true; p. StartInfo. FileName = "Write500Lines. exe"; p. Start (); // Não espere que o processo filho saia antes de // ler até o final do seu fluxo redirecionado. // p. WaitForExit (); // Leia o fluxo de saída primeiro e aguarde. string output = p. StandardOutput. ReadToEnd (); p. WaitForExit ();

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

A resolução de Mark Byers é muito boa, mas eu simplesmente adicionaria o seguinte: os delegados OutputDataReceived e ErrorDataReceived querem se livrar antes que o outputWaitHandle e errorWaitHandle sejam descartados. Se o método continuar a produzir conhecimento após o tempo limite ter sido excedido após o que termina, as variáveis ​​outputWaitHandle e errorWaitHandle provavelmente serão acessadas após serem descartadas.

(Para sua conveniência, acrescentei esta advertência como uma solução, pois não pude tocar em sua apresentação.)

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

A desvantagem com ObjectDisposedException não processada ocorre enquanto o método é expirado. Nesse caso, as partes opostas da situação:

se (process. WaitForExit (timeout) && outputWaitHandle. WaitOne (tempo limite) && errorWaitHandle. WaitOne (tempo limite))

não é feito. Eu resolvi esse lado negativo da seguinte maneira:

1 de janeiro de 1970 & middot;

Nós temos esse fator de forma inteligente (ou uma versão).

1) Adicione um tempo limite para p. WaitForExit (nnnn); o lugar nnnn está em milissegundos.

2) Coloque o nome ReadToEnd mais cedo que a chamada WaitForExit. Isto é o que vimos no conselho da MS.

1 de janeiro de 1970 & middot;

Uma palavra de advertência com a resolução de Mark Byers:

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

Rob falou de volta e me armazenou algumas horas extras de testes. Leia o buffer de saída / erros mais cedo do que pronto:

// Leia o fluxo de saída primeiro e depois wait. string output = p. StandardOutput. ReadToEnd (); p. WaitForExit ();

1 de janeiro de 1970 & middot;

Eu resolvi desta forma:

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; enquanto (! outputReader. EndOfStream) enquanto (! errorReader. EndOfStream) streamWriter. Close (); proc. WaitForExit ();

Eu redirecionasse cada entrada, saída e erro e tratava o estudo de saída e fluxos de erro. Esta resposta funciona para o SDK 7- eight.1, tanto para o Windows 7 como para o Windows 8.

1 de janeiro de 1970 & middot;

Eu fator que é um método discreto e mais alto (nós não estamos procurando AutoResetEvent):

7 de novembro de 2016 e middot;

7 de novembro de 2016 e middot;

Eu já tive uma questão semelhante, no entanto, o raciocínio era diferente. Por outro lado, ocorreria no Windows 8, mas agora não está no Windows 7. A seguinte linha acabou por ter levado ao problema.

A resposta foi uma vez para NÃO desativar o UseShellExecute. Agora recebi uma janela popup do Shell, que é indesejável, no entanto, é significativamente melhor do que esse sistema, esperando que nada seja explícito. Então eu adicionei o próximo trabalho para isso:

Agora, o que me incomoda é o motivo pelo qual isso está acontecendo abaixo do Windows oito na posição principal.

7 de novembro de 2016 e middot;

Isso publica, talvez antigo, no entanto, eu considerei o princípio, porque ele regularmente pendura é devido ao excesso de pilha para a saída redirectStandardout ou no caso de você ter redirecionadoStandarderror.

Como as informações de saída ou os dados de erro são enormes, isso levará a um tempo de espera porque ele continua a ser processado por período indefinido.

Obtener la salida de un command de consola.

Para solucionar esse problema, realmente precisamos do código-fonte para reproduzir o problema, para que possamos investigar o problema em casa. Não é necessário enviar a fonte completa do seu projeto. Nós só precisamos de uma amostra mais simples para reproduzir o problema. Você pode remover qualquer informação confidencial ou lógica de negócios dele.

A leitura do StandardOutput é realmente complicada. O problema é que você também precisa ler o fluxo de erros ao mesmo tempo. Se você não lê constantemente de ambos, um dos buffers pode ficar cheio e o processo parecerá pendurado, pois espera que você leia. É por isso que você não pode chamar ReadToEnd nos fluxos.

Eu realmente resolvi isso uma vez para o caso geral e eu me chuto toda vez que penso sobre isso, porque eu não pensei em manter uma cópia desse código para mim. Acabei tendo dois threads de leitor processando os fluxos de saída e erro que passariam os resultados de volta ao thread principal.

Se você ainda precisar de ajuda, posso tentar resolver isso amanhã.

Eu escrevi um exemplo de código para mostrar como você pode ler a saída de outro processo de linha de comando:

static void Main (string [] args)

String exeFileName = & quot; output. exe & quot; ;

ProcessStartInfo info = new ProcessStartInfo (exeFileName);

// Redirecionar a saída padrão do processo.

informações. RedirectStandardOutput = true;

informações. RedirectStandardError = true;

// Defina UseShellExecute como falso para redirecionamento.

informações. UseShellExecute = false;

Process proc = new Process ();

proc. StartInfo = info;

// Defina nosso manipulador de eventos para ler de forma assíncrona a saída de classificação.

proc. OutputDataReceived + = new DataReceivedEventHandler (proc_OutputDataReceived);

proc. ErrorDataReceived + = new DataReceivedEventHandler (proc_ErrorDataReceived);

// Inicia a leitura assíncrona do fluxo de saída de classificação. Note esta linha!

static void proc_ErrorDataReceived (remetente do objeto, DataReceivedEventArgs e)

Console. WriteLine (& quot; Erro: & quot; e e. Dados);

static void proc_OutputDataReceived (remetente do objeto, DataReceivedEventArgs e)

Console. WriteLine (& quot; Dados de saída: & quot ;, e. Data);

Espero que isto ajude!

Bem, isso certamente é mais fácil do que a forma como eu costumava fazê-lo.

Eu realmente resolvi isso uma vez para o caso geral e eu me chuto toda vez que penso sobre isso, porque eu não pensei em manter uma cópia desse código para mim. Acabei tendo dois threads de leitor processando os fluxos de saída e erro que passariam os resultados de volta ao thread principal.

O problema é que, de acordo com a documentação do MSDN (e com os meus próprios testes, que suportaram isso), "Any instance members [da classe Process] não tem garantia de segurança para thread." Portanto, sua solução multi-threading deve, em teoria, não funcionar. Certamente não é recomendado pela MS. Obrigado pela sugestão embora.

Eu escrevi um exemplo de código para mostrar como você pode ler a saída de outro processo de linha de comando:

Obrigado por isso. Isso realmente parece funcionar (yay!). mas apenas de forma síncrona. Você pode usar este método para obter de forma confiável toda a saída stdout e stderr de um processo, mas o código precisa esperar até que o processo tenha saído antes de retornar. Tudo bem se você quiser lidar com apenas um processo de cada vez, então este é um bom começo. Infelizmente, minha maior ambição era ser capaz de lidar com vários de uma só vez, o que significaria criar um novo thread que chamava esse código para cada processo. O problema é que, como mencionado acima, os membros da instância da classe Process não são thread-safe, então isso não pode ser feito.

Então, obrigado pela ajuda de todos, e agora sabemos como lidar com esse problema de maneira síncrona. No entanto, se houver uma maneira de fazê-lo de forma assíncrona (isto é, disparar alguns threads que lidam com alguns processos diferentes e, em seguida, retornar imediatamente para manter a interface do usuário responsiva), eu gostaria de saber como fazer isso. . Enquanto isso, porém, vou ter que viver fazendo isso de maneira síncrona.

Na verdade, as duas funções do manipulador de eventos foram chamadas pelos encadeamentos em segundo plano do CLR de forma assíncrona. E, se você quiser ouvir vários processos, por que não usar vários objetos da classe Process? Você pode usar uma função de manipulador de eventos para manipular eventos de fontes de eventos mulitiple.

Feng, esta é uma boa solução se você só precisa da saída & quot; depois & quot; você chamou proc. WaitForExit ().

Eu preciso disso colocar "durante" meu processo de ftp.

Veja abaixo, depois que eu enviar o comando OPEN, preciso verificar para ver o que o.

O código de retorno do servidor era.

Se foi um 220, então eu envio meu nome de usuário e senha e, em seguida, preciso ver se.

Recebi um código de 200 de volta.

E se eu encontrar é que o DataReceivedEventHandler (FTPProcess_OutputDataReceived)

O evento não dispara até depois do WaitForExit, que é tarde demais para as minhas necessidades.

Alguma idéia sobre como obter dados em tempo real do StandardOutput?

//. código do processo de configuração.

configuração bool privada ()

FTPProcess. OutputDataReceived + = new DataReceivedEventHandler (FTPProcess_OutputDataReceived);

FTPProcess. ErrorDataReceived + = new DataReceivedEventHandler (FTPProcess_ErrorDataReceived);

private bool LoginToServer ()

// Enviando comandos para o processo FTP.

FTPStreamWriter. WriteLine (& quot; OPEN & quot; + this ._FtpServerAddress);

bool success = false;

// se nos conectamos com sucesso o servidor ftp.

FTPStreamWriter. WriteLine (& quot; USER & quot; + this. _UserName + & quot; & quot; + esta ._Password);

// se tivermos um login bem-sucedido.

private void FTPProcess_OutputDataReceived (objeto sendProcess, DataReceivedEventArgs output)

if (! string. IsNullOrEmpty (output. Data))

private void FTPProcess_ErrorDataReceived (objeto sendProcess, DataReceivedEventArgs erro)

if (! string. IsNullOrEmpty (error. Data))

O evento Exited é acionado antes do último evento OuputDataReceived. Como resultado, você não sabe quando o último evento OutputDataReceived chegou (suponho que isso também seja verdade para ErrorDataReceived).

comando de cadeia = & quot; output. exe & quot; ;

argumentos de cadeia = "quot; o que quer que seja? ;

proc. OutputDataReceived + = new DataReceivedEventHandler (proc_OutputDataReceived);

proc. ErrorDataReceived + = new DataReceivedEventHandler (proc_ErrorDataReceived);

proc. Exited + = new EventHandler (proc_Exited);

Console. WriteLine (& quot; Exited (Event) & quot;);

Console. WriteLine (& quot; Erro: & quot; e. Data);

Console. WriteLine (& quot; dados de saída: & quot; e. Data);

Portanto, se você capturar que os fluxos estão fechados e capturar o evento de saída, será possível detectar com precisão exit + IO complete.

& lt; Sim, eu sei que este é um tópico antigo & gt;

Verificar se os dados são nulos ou vazios não é o melhor caminho a percorrer. É possível que o programa que você está executando é produzir cordas vazias.

Tanto quanto eu posso dizer, não há maneira certa de saber quando os eventos de IO foram concluídos. Mesmo "elggarc" A resposta acima não garante isso.

A única maneira que encontrei é dormir o seu fio principal por um segundo antes de voltar. Exemplo tomando a resposta de cima:

Editado por pbyrne quinta-feira, 3 de março de 2011 22:34 fixing example.

A documentação diz sobre BeginOutputReadLine:

Inicia operações de leitura assíncrona no fluxo StandardOutput redirecionado do aplicativo.

No entanto, parece que você está tentando redirecionar stderr e stdout. Vai chamar apenas BeginOutputReadLine () também ler mensagem de stderr?

Este é o melhor, depois de uma grande escavação.

public static void Test ()

System. Diagnostics. Process winscp = new System. Diagnostics. Process ();

string result = RunCommand (winscp, & quot; Dir & quot;);

result = RunCommand (winscp, & quot; Dir & quot;);

result = RunCommand (winscp, & quot; Dir & quot;);

result = RunCommand (winscp, & quot; Dir & quot;);

result = RunCommand (winscp, & quot; Dir & quot;);

Tópico threadToKill = null;

Func & lt; System. IO. StreamReader, StringBuilder, string & gt; wrappedAction = (reader, sb) = & gt;

int cnt = reader. Peek ();

char [] buffer = new char [cnt];

int rcnt = reader. Read (buffer, 0, cnt);

StringBuilder sbresult = novo StringBuilder ();

Resultado de IAsyncResult = wrappedAction. BeginInvoke (winscp. StandardOutput, sbresult, null, null);

if (result. AsyncWaitHandle. WaitOne (new TimeSpan (0, 0, timout)))

A Microsoft está conduzindo uma pesquisa on-line para entender sua opinião sobre o site da Msdn. Se você optar por participar, a pesquisa on-line será apresentada quando você sair do site do Msdn.

Processo . Evento OutputDataReceived.

A documentação de referência da API tem uma nova casa. Visite o navegador da API no docs. microsoft para ver a nova experiência.

Ocorre toda vez que um aplicativo grava uma linha em seu fluxo StandardOutput redirecionado.

Assembly: System (no System. dll)

O evento OutputDataReceived indica que o processo associado gravou uma linha, terminando com um caractere de nova linha, para seu fluxo StandardOutput redirecionado.

O evento está habilitado durante operações de leitura assíncronas no StandardOutput. Para iniciar operações de leitura assíncronas, você deve redirecionar o fluxo StandardOutput de um Processo, adicionar seu manipulador de eventos ao evento OutputDataReceived e chamar BeginOutputReadLine. Posteriormente, o evento OutputDataReceived atende cada vez que o processo escreve uma linha para o fluxo de StandardOutput redirecionado, até o processo sair ou chama CancelOutputLit.

O aplicativo que está processando a saída assíncrona deve chamar o método WaitForExit para garantir que o buffer de saída tenha sido liberado.

O exemplo a seguir ilustra como executar operações de leitura assíncronas no fluxo do StandardOutput redirecionado do comando ipconfig.

O exemplo cria um delegado de evento para o manipulador de eventos OutputHandler e o associa ao evento OutputDataReceived. O manipulador de eventos recebe linhas de texto do fluxo de StandardOutput redirecionado, formata o texto e o salva em uma seqüência de saída que é mostrada mais tarde na janela do console do exemplo.

para confiança total para o chamador imediato. Este membro não pode ser usado por código parcialmente confiável.