Exemplo de espera do net waitforexit

exemplo waitforexit
Obter através da App Store Leia esta publicação em nosso aplicativo!
Como usar Process. WaitForExit.
Estou chamando um aplicativo da 3ª parte que "às vezes" funciona no VB (é um WCF autônomo). Mas às vezes o aplicativo de terceiros pendura para sempre, então adicionei um temporizador de 90 segundos. O problema é, como eu sei se o tempo expirou?
O código parece assim:
O que eu gostaria de fazer é algo assim.
Verifique o valor de retorno do método - msdn. microsoft/en-us/library/ty0d8k56.aspx - se a chamada expirar, ele retornará False.
Houve problemas conhecidos no passado em que os aplicativos congelariam ao usar 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.
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.
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.
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!
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.

Code Ducky.
um blog para codificadores por codificadores.
Trabalhando com processos em.
Os idiomas de scripts e shell são geralmente construídos em torno da capacidade de um processo para iniciar facilmente e trabalhar com os resultados dos outros. Este é o principal modo de processamento em bash, enquanto o ruby ​​suporta pelo menos 5 abordagens integradas com diferentes níveis de flexibilidade e concisão.
Em, isso é uma espécie de operação normalmente é feito através da API System. Diagnostics. Process. O Process API é bastante geral e poderoso, mas pode ser complicado e difícil de usar corretamente nos casos de uso comum que são tratados tão bem pelas linguagens acima. Como um spoiler, acabei envolvendo grande parte dessa complexidade em uma nova biblioteca: MedallionShell. Com o MedallionShell, esse tipo de tarefa é um one-liner:
Mais sobre isso mais tarde, no entanto. Por enquanto, vamos voltar ao Processo. Como um exemplo concreto, recentemente queria que meu aplicativo lancasse uma instância do NodeJS para executar o compilador menos css. Eu precisava escrever na entrada padrão do Node & # 8217; ao capturar o texto de saída padrão, texto de erro padrão e código de saída.
Uma tentativa inicial.
Aqui é o código com que comecei:
Este código é bastante detalhado; infelizmente também é bastante buggy.
Lidando com os argumentos do processo.
Um dos primeiros problemas que notamos com este código é que a propriedade Arguments no ProcessStartInfo é apenas uma string. Se os argumentos que estamos passando são dinâmicos, precisaremos fornecer a lógica de escape adequada antes de concatenar para impedir que coisas como espaços em caminhos de arquivos sejam quebrados. Escapar os argumentos da linha de comando do Windows é estranhamente complexo; Felizmente, o código necessário para implementá-lo está bem documentado nesta publicação do StackOverflow. Assim, a primeira mudança que nós vamos fazer é adicionar lógica de escape:
Lidar com deadlocks.
Um problema menos óbvio é o bloqueio. Os três fluxos de processo (entrada, saída e erro) são finitos em quanto de conteúdo eles podem armazenar. Se o buffer interno for preenchido, então quem estiver escrevendo para o fluxo irá bloquear. Neste código, por exemplo, não lemos os fluxos de saída e erro até que o processo tenha saído. Isso significa que podemos encontrar-nos em um caso em que o Node esgota o buffer de erro. Nesse caso, o Nó bloquearia a gravação em erro padrão, enquanto nosso aplicativo está bloqueado a leitura até o final do padrão. Assim, nós nos encontramos em um impasse!
O Process API fornece um método que parece projetado para lidar com isso: BeginOutput / ErrorReadLine. Com este método, você pode assinar o assíncrono & # 8220; DataReceived & # 8221; eventos em vez de ler os fluxos de saída diretamente. Dessa forma, você pode ouvir ambos os fluxos ao mesmo tempo. Infelizmente, este método não fornece nenhuma maneira de saber quando o último bit de dados foi recebido. Porque tudo é assíncrono, é possível (e eu observei isso) para que os eventos disparem depois que WaitForExit () retornou.
Felizmente, podemos fornecer nossa própria solução alternativa usando Tarefas para ler asíncronamente as transmissões enquanto aguardamos o Nó para sair:
Adicionando um tempo limite.
Outra questão que gostaria de lidar é a de um processo pendurado. Em vez de esperar para que o processo saia, nosso código seria mais robusto se forçássemos um timeout em vez disso:
Async todo o caminho!
Enquanto nós agora estamos usando o IO assíncrono para ler dos fluxos do processo, ainda estamos bloqueando um segmento enquanto aguardamos o processo para concluir. Podemos melhorar a eficiência aqui, indo totalmente assíncrono:
Adaptando-se a volumes de dados maiores.
Outra questão que pode surgir ao tentar generalizar essa abordagem é a do volume de dados. Se estivermos fornecendo uma grande quantidade de dados através do processo, nós provavelmente queremos substituir as chamadas convenientes ReadToEndAsync () com loops de leitura assíncronos que processam cada pedaço de dados conforme ele vem.
Mudando para MedallionShell.
Nós já construímos um código (esperançosamente) correto, robusto e eficiente para trabalhar com um processo. No entanto, espero que este exemplo o tenha convencido de que a API do Processo não é suficiente para o trabalho quando se trata de facilidade de uso. Para esse fim, irei apresentar uma alternativa: a biblioteca MedallionShell (disponível no NuGet). Aqui, a lógica equivalente usando MedallionShell:
Com o MedallionShell, os argumentos são escapados automaticamente, os fluxos de processo são automaticamente armazenados em buffer para evitar o impasse, e tudo está bem envolvido em uma API baseada em tarefas compatível com asínc. Nós não teremos que nos preocupar em chamar Dispose (): por padrão, o Processo é descartado automaticamente após a conclusão do comando.
O MedallionShell também oferece sobrecargas do operador para permitir o redirecionamento semelhante à da entrada padrão e saída padrão. Isso significa que você pode usar & # 8220; & lt; & # 8221; e & # 8220;> & # 8221; para canalizar dados de e para fluxos, arquivos e coleções. Você pode até usar o & # 8220; | & # 8221; para canalizar dados de um objeto Command para outro.
Mike Adelson.
Últimas publicações de Mike Adelson (ver todos)
Implementando Equals () e GetHashCode () em C # 7 - 3 de junho de 2017 Scripting in C # - 3 de maio de 2017 7 maneiras de usar C # 7 throw expressions - 26 de abril de 2017.
Sobre Mike Adelson.
I & # 8217; m engenheiro de software em Applied Predictive Technologies em Washington D. C., onde trabalho em & # 8220; dados grandes & # 8221; análise e desenvolvimento web. No meu tempo livre, eu gosto de ler, trabalhar em vários projetos paralelos e responder perguntas no StackOverflow.
Pós-navegação.
7 pensamentos sobre & ldquo; Trabalhando com processos em & rdquo;
É possível ler e escrever para o mesmo processo dentro do mesmo programa. Eu usei o shell medalhão para ler a saída de um programa de console interativo. Mas quando eu iniciar um segmento diferente para escrever comandos para o programa, o writestream. writeline parece apenas pendurar. Estou tentando controlar pianobar (veja github). Há algum passo ao tentar ler uma linha do processo e responder com uma linha. Isto está me enlouquecendo.
Sim, deve ser possível ler e escrever para um processo dentro do mesmo programa. Certifique-se de que está usando a versão mais recente do MedallionShell e que a entrada padrão do comando está definida como AutoFlush (deve ser o padrão).
Você pode observar WriteLine para pendurar se o processo de destino não for puxar os dados e o buffer interprocesso for preenchido (evitando assim que o preenchimento seja concluído).
É difícil para mim dizer mais sem ver o seu código; considere publicar uma descrição mais detalhada e uma amostra de código como um problema no github / madelson / MedallionShell.
Obrigado Michael. Eu fiz exatamente isso, o problema # 9 #. Liguei a minha pergunta. Claramente, eu estava com muito sono para escrever qualquer coisa. Eu quis dizer que há algum passo que é necessário que eu esteja faltando. Algo óbvio para todos os outros por mim.
É possível aguardar uma string específica no fluxo de saída do comando?
bool found = await cmd. StandardOutput. Expect (searchstring, timeout);
Não há funcionalidades incorporadas para fazer isso. Se a string não abranger uma linha, você poderia fazer:
enquanto ((linha = cmd. StandardOutput. ReadLine ())! = null)
Se a cadeia de pesquisa abranger várias linhas, você pode usar uma técnica de loop semelhante, onde você acompanha os últimos N caracteres onde N é o comprimento da seqüência de pesquisa.

exemplo waitforexit
Eu trabalhei no projeto da minha empresa. Eu notei esse problema, quando liguei de um Exe para Outre Exe. Durante o arrastar, o formulário no segundo Exe mostrará várias formas. Estou usando WaitforExit ().
resolva-o.
Movido por edhickey quarta-feira, 27 de julho de 2018 2:44 PM (De: 3.0 / 3.5 Fundação Workflow do Windows)
Esta é exatamente a causa do problema. Se WaitForExit é chamado a partir do tópico do formulário, ele impedirá que o formulário seja redesenhado novamente. Arrastar algo na frente de uma janela bloqueada deixa um traço da janela arrastada.
Proposto como resposta por ahmedilyas Moderador quinta-feira, 28 de julho de 2018 10:34 Marcado como resposta por Jackie-Sun Moderador segunda-feira, 08 de agosto de 2018 às 6:50.
O código seria melhor e também seria melhor se você puder nos dizer exatamente o que você está tentando alcançar.
WaitForExit () simplesmente espera (bloqueia seu código durante esse período) para que um processo saia antes de continuar com a execução do seu código de chamada.
C # MVP (2007-2018) MS Vendor - MS Todo o caminho! Seguidor desde 1995 MS Super Evangelist | Moderador do Fórum MSDN.
Proposto como resposta por ahmedilyas Moderador quinta-feira, 28 de julho de 2018 10:33 Marcado como resposta por Jackie-Sun Moderador segunda-feira, 8 de agosto de 2018 às 6:50.
Todas as respostas.
O código seria melhor e também seria melhor se você puder nos dizer exatamente o que você está tentando alcançar.
WaitForExit () simplesmente espera (bloqueia seu código durante esse período) para que um processo saia antes de continuar com a execução do seu código de chamada.
C # MVP (2007-2018) MS Vendor - MS Todo o caminho! Seguidor desde 1995 MS Super Evangelist | Moderador do Fórum MSDN.
Proposto como resposta por ahmedilyas Moderador quinta-feira, 28 de julho de 2018 10:33 Marcado como resposta por Jackie-Sun Moderador segunda-feira, 8 de agosto de 2018 às 6:50.
Eu tinha verificado. Tem problema no waitforexit () only. i percebi esse problema quando mover o segundo formulário exe.
Editado por RAJ KUMAR. R quinta-feira, 28 de julho de 2018 às 10:09.
Qual é exatamente o problema? você leu minha resposta? você também leu o link que eu forneci?
WaitForExit () é um método de bloqueio de thread que fará exatamente exatamente isso - espere que um processo saia antes de continuar com seu código. NÃO fará o seu formulário ocultar ou minimizar, a menos que você diga ao seu código para fazer isso antes de chamar WaitForExit ()
C # MVP (2007-2018) MS Vendor - MS Todo o caminho! Seguidor desde 1995 MS Super Evangelist | Moderador do Fórum MSDN.
Tudo está funcionando bem. Mas quando eu mudo o formulário, ele mostra uma forma múltipla.
Esta é exatamente a causa do problema. Se WaitForExit é chamado a partir do tópico do formulário, ele impedirá que o formulário seja redesenhado novamente. Arrastar algo na frente de uma janela bloqueada deixa um traço da janela arrastada.
Proposto como resposta por ahmedilyas Moderador quinta-feira, 28 de julho de 2018 10:34 Marcado como resposta por Jackie-Sun Moderador segunda-feira, 08 de agosto de 2018 às 6:50.
Quando você diz que mostra vários formulários - você está falando sobre várias instâncias dos formulários ou apenas o desenho / renderização?
se é o desenho / renderização, sim, como já foi dito - é porque está aguardando que o processo saia / termine antes de continuar e seja threadblocking para que você veja o & quot; problema & quot; você está a descrever. Não há "correcção" para isso, uma vez que não é um bug ou um problema, mas apenas o que você está usando e como você o está usando.
Existe uma razão pela qual você está usando WaitForExit ()? Você deve mostrar seu formulário quando você está usando WaitForExit ()? Por que você não esconde ou minimiza o formulário antes de chamar WaitForExit (), então, restaure-o depois da palavra?
C # MVP (2007-2018) MS Vendor - MS Todo o caminho! Seguidor desde 1995 MS Super Evangelist | Moderador do Fórum MSDN.
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ê deixar o site Msdn.

exemplo waitforexit
Dentro de um aplicativo que estou escrevendo, preciso fazer o seguinte:
Execute um aplicativo GUI externo (para os propósitos deste exemplo, vamos assumir o seu MS Word). Bloqueie o segmento atual até que o aplicativo GUI externo tenha sido fechado.
Minha primeira tentativa de fazer isso foi fazer uso do objeto System. Diagnostics. Process.
// Inicialize o objeto de processo.
myProcess. StartInfo. FileName = & quot; C: \\ Arquivos de Programas \\ Microsoft Office \\ OFFICE11 \\ Winword. exe & quot ;;
myProcess. StartInfo. WorkingDirectory = & quot; C: \\ Arquivos de Programas \\ Microsoft Office \\ OFFICE11 & quot ;;
// Inicie o processo e aguarde que ele seja fechado.
System. Windows. Forms. MessageBox. Show (& quot; Aplicativo de usuário fechado & quot;);
Quando eu executo o código acima, o MS Word é iniciado como esperado. No entanto, a chamada WaitForExit () não parece estar fazendo seu trabalho quando eu exibir a caixa de mensagem instantaneamente instantaneamente depois que o processo do MS Word for iniciado e não depois que ele for fechado.
Por que a chamada WaitForExit () não aguarda o processo MSWord para terminar? O fato de eu estar lançando um aplicativo GUI em vez de um aplicativo de linha de comando é significativo?
Qualquer ajuda seria muito apreciada.
Todas as respostas.
Depois de alguns testes, concluí que é porque não há um documento de usuário carregado. Se você fizer o parâmetro do nome do arquivo um documento real funciona como esperado:
// Inicie o processo e aguarde que ele seja fechado.
System. Windows. Forms. MessageBox. Show (& quot; Aplicativo de usuário fechado & quot;);
Seja ou não um documento carregado, não deve ser importante? O objeto Processo apenas fornece uma maneira genérica de executar e monitorar processos, não sabe nada sobre os internos do que o Word carregou com segurança?
Em qualquer caso, tentei o código como recomendado e recebo uma exceção "Sem processo associado a este objeto", presumivelmente porque foi passado o nome do arquivo de um documento em vez de um executável.
(Eu também devo mencionar que estou usando apenas o Word como exemplo aqui para resolver esse problema específico e, portanto, não quero ficar muito pendurado no que está acontecendo no Word Word. Eu tentei e não usei WaitForExit () com uma variedade de aplicativos GUI.)
OK, acabei de chegar em casa e tentei isso no meu PC doméstico, e você não saberia que o código funciona! Não tenho certeza por que causa problemas no laptop do meu trabalho.
Em qualquer caso, obrigado por você ajudar a DMan.
Proposta como resposta por Brad Mathews sexta-feira, 19 de dezembro de 2008 12:55.
objProcess As New System. Diagnostics. ProcessStartInfo ("Winword. exe", "quot; / t c: \ mydoc. doc")
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ê deixar o site Msdn.