Eu tenho um programa que freqüentemente usa um programa externo e lê suas saídas. Isso funciona muito bem, usando seu processo usual de redirecionamento de saída, mas um argumento específico, por algum motivo, trava quando eu tento lê-lo, nenhuma mensagem de erro - nenhuma exceção, ele simplesmente pára quando ele atinge essa linha. Naturalmente, eu uso uma função centralizada para chamar e ler a saída do programa, que é esta: a linha que trava é resultado proc. StandardOutput. ReadToEnd (). Mas novamente, não todas as vezes, somente quando enviado um argumento específico (servidor inicial). Todos os outros argumentos funcionam bem - lê o valor e o retorna. Também é estranho do jeito que ele trava. Ele não congela ou comete um erro ou qualquer coisa, ele simplesmente pára de processar. Como se fosse um comando de retorno, exceto que ele nem sequer retornava à função de chamada, ele simplesmente pára tudo com a interface ainda está funcionando. Qualquer um experimentou isso antes Alguém tem alguma ideia do que eu deveria tentar Im assumindo que é algo inesperado dentro do fluxo em si, mas existe uma maneira de lidar com isso para que ele lira de qualquer maneira, perguntou o 23 de agosto 11 às 11:19 Executar no console o mesmo Programa com os mesmos parâmetros. Ele está solicitando a interação do usuário, como inserir senha ou congestão após advertências, pode ser a causa. Por exemplo, pgAdmin (administração de banco de dados de pós-publicação) trava solicitando senha para bancos de dados que não estão em seu arquivo de configuração. Mas isso só pode ser visto a partir do console ndash profimedica 31 de agosto 16 às 5:55 Soluções propostas com BeginOutputReadLine () são uma boa maneira, mas em situações como essa, não é aplicável, porque o processo (certamente com o uso de WaitForExit ()) Sai antes da saída assíncrona concluída completamente. Então, eu tentei implementá-lo de forma síncrona e descobriu que a solução é usar o método Peek () da classe StreamReader. Eu adicionei check para Peek () gt -1 para garantir que não seja o fim do stream como no artigo MSDN descrito e, finalmente, ele funciona e parar de suspender Aqui está o código: respondido 29 de abril 13 às 10:50 Eu apenas implementei isso Mudança e meu processo ainda está pendurado no processo. StandardError. ReadLine (). Ndash ganders 6 de junho 13 às 20:38 ganders pode ser seu processo. StandardError. ReadLine () retorna null ndash Fedor 6 de junho 13 às 21:33 I39ll tentar esse cheque e informá-lo. Ndash ganders 7 de junho 13 às 12:18 Eu reparei, mas eu implementei algo que alguém respondeu de uma pergunta diferente, aqui é o link para a resposta que usei: stackoverflowquestions139593hellip ndash ganders 25 de junho 13 às 12:21 Obrigado por responder . Tenho medo de que isso não funcionasse, ele ainda estava pendurado logo que chegou a 39StandardError. ReadToEnd () 39. Eu até tentei usar 39BeginErrorReadLine () 39, mas também pendurado. A única coisa que DID funcionou foi adicionar um tempo limite para 39WaitForExit39. Uma vez que este argumento específico que trava sempre dá um resultado quase que imediato, expirai em cerca de 3 segundos e tudo funciona bem. Não é muito elegante, mas funciona. Obrigado novamente por ajudar. Ndash Elad Avron 25 de agosto 11 às 8:17 Eu tive o mesmo problema de impasse. Este trecho de código funcionou para mim. Respondeu Feb 3 15 às 12:19 E quanto a algo como: respondeu 25 de novembro 15 às 7:12 Eu tive o mesmo tipo de problema que o erro estava pendurado. Com base na sua resposta a Daniel Hilgarth, nem tentei usar esses códigos, embora eu pense que eles teriam funcionado para mim. Uma vez que eu quero poder fazer uma saída ainda mais fantástica, finalmente eu decidi que eu faria isso com as duas saídas sendo feitas em uma linha de fundo. Isso funcionou para mim e me permitiu não ter que usar um tempo limite para a leitura. Respondeu Apr 4 13 às 9:57 Algo que é elegante e trabalhou para mim é: Esta resposta eu encontrei aqui e o truque é usar Flush () e Close () na entrada padrão. Respondeu 18 de março 15 às 9:39 A solução de respostas aceitas não funcionou para mim. Eu tive que usar tarefas para evitar o impasse: Com uma função GetStreamOutput da seguinte maneira: respondeu 10 de julho 15 às 15:59 Apenas no caso de alguém se tropeçar com esta pergunta enquanto estiver usando Windows Forms e TextBox (ou RichTextBox) para mostrar o Erros e saídas do processo retorna em tempo real (como eles são escritos para process. StandardOutput process. StandardError). Você precisa usar OutputDataReceived () ErrorDataReceived () para ler ambos os fluxos sem deadlocks, não há nenhuma maneira (tanto quanto eu sei) para evitar deadlocks de outra forma, mesmo a resposta do Fedors, que agora contém a tag Answer e a maioria gosta Até à data, não faz o truque para mim. No entanto, quando você usa o RichTextBox (ou TextBox) para enviar os dados, outro problema que você encontra é como realmente gravar os dados na caixa de texto em tempo real (uma vez que ele chega). Você recebe o acesso aos dados dentro de um dos segmentos de fundo OutputDataReceived () ErrorDataReceived () e você só pode anexar o texto () do thread principal. O que eu tentei pela primeira vez era chamar processo. Iniciar () de uma linha de fundo e, em seguida, chamar BeginInvoke () gt AppendText () em OutputDataReceived () ErrorDataReceived () threads enquanto o thread principal era process. WaitForExit (). No entanto, isso levou a minha forma a congelar e finalmente pendurar por toda a eternidade. Depois de alguns dias de tentativa, acabei com a solução abaixo, que parece funcionar muito bem. Em breve, você precisa adicionar as mensagens para uma coleção simultânea dentro dos segmentos OutputDataReceived () ErrorDataReceived () enquanto o tópico principal deve tentar constantemente extrair as mensagens dessa coleção e anexá-las à caixa de texto: a única desvantagem dessa abordagem é o fato Que você pode perder mensagens em um caso bastante raro, quando o processo começa a escrevê-las entre process. Start () e process. BeginErrorReadLine () process. BeginOutputReadLine (). Mantenha isso em mente. A única maneira de evitar isso é ler os fluxos completos e (ou) obter acesso a eles somente quando o processo terminar. Respondeu 24 de maio 16 em 13: 21Elina: obrigado pela sua resposta. Há algumas notas na parte inferior deste MSDN doc (msdn. microsoften-uslibraryhellip) que alertam sobre potenciais bloqueios se você ler ao final de ambos os fluxos stdout e stderr redirecionados de forma síncrona. É difícil dizer se sua solução é suscetível a esse problema. Além disso, parece que você está enviando o process39 stdoutstderr output novamente na entrada. Por quê. ) Ndash Matthew Piatt 26 de setembro 16 às 4:42 Esta é uma solução baseada em TPL (Task Parallel Library) mais moderna e esperada para. NET 4.5 e acima. Exemplo de uso Implementação respondida 5 de outubro 16 às 10:54 Eu acho que isso é uma abordagem simples e melhor (não precisamos de AutoResetEvent): respondido 14 de junho 12 às 14:29 Verdadeiro, mas não deveria estar fazendo. FileName Path quotggsci. exequot quot lt Obeycommand. txtquot para simplificar o seu código também Ou talvez algo equivalente a quotggsci. exequot do quot do comando quotecho se você realmente não quiser usar um arquivo obeycommand. txt separado. Ndash Amit Naidu Jun 4 13 at 22:03 Sua solução não precisa de AutoResetEvent, mas você pesquisa. Quando você faz uma pesquisa em vez de usar o evento (quando está disponível), você está usando a CPU sem motivo e isso indica que você é um programador ruim. Sua solução é realmente ruim quando comparada com a outra usando AutoResetEvent. (Mas não te dou -1 porque voce tentou ajudar). Ndash Eric Ouellet Nov 7 14 às 18:38 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. Respondeu 13 de janeiro 15 às 10:35 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 bug 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 depois que o processo for 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 você Configure-o para 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 obter uma leitura assíncrona segura de um fluxo de saída de um processo da maneira atual Process 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.
No comments:
Post a Comment