Esta pergunta pode parecer um pouco estranha, mas estou tentando executar VS2005 através de um processo e executar um comando específico e eu waitforexit (). Estou redirecionando minha entrada e saída com sucesso, mas de vez em quando eu recebo uma Janela de Relatório de Erros WindowMessage. O problema é que eu estou remoting, então, quando esta janela de mensagem ocorrer durante a execução do processo, eu vou pendurar a menos que eu logar na outra máquina (remoting) e fechar a janela. Existe alguma maneira de matar programaticamente essa janela ou, possivelmente, desativar a janela do mensagem, eu pensei em executar o VS em uma execução silenciosa (ainda tenho encontrado uma maneira de fazê-lo). Eu também tentei ver se há algo que está sendo lançado quando isso ocorre, compara-se com quando não. Quinta-feira, 25 de outubro de 2007 8:32 PM Bem, eu tentei usar FindWindow e FindWindowEx junto com SendMessage, mas não consegui encontrar o identificador de janela correto. Mas, como eu sei que uma caixa de Msssage de relatórios de erros do Windows aparecerá, verifiquei se era seu próprio processo (e é). O processo é dwwin. exe (Dr. Watson Win) e tudo o que eu tinha que fazer era isso para me permitir corrigir o problema atual. Substitua o atual bloco de código abaixo para a declaração WaitForExit () que eu tinha anteriormente. Proc. WaitForExit (60000) Processo ProcArray Process Process. GetProcessesByName (quotdwwinquot) foreach (Process ProcessFound no ProcArray) Procuram também verificar se você conseguiu obter o Process. MainWindowTitle (), mas está definido como quotquot. Então, isso é um hack e eu realmente não gosto de usá-lo, mas funciona para a execução atual. Segunda-feira, 29 de outubro de 2007 7:26 PM Não, posso redirecionar entrada e saída sem problema. O erro que recebo é o relatório geral de erros do Windows e, infelizmente, é em japonês, então não sei qual é o erro exato, mas é o erro geral. Eu não tenho o código na minha frente, mas eu configurei delegatesthreads para ler redirecionado o erro e a saída depois de sair do processo inteiro. Eu não posso inventar qualquer coisa e sou capaz de executar o mesmo processo em meu próprio computador, mas não sou capaz de fazer este um comando específico através da comunicação remota. Eu vou tentar isso amanhã remoting em uma máquina não-japonesa no trabalho e vou publicar minhas descobertas, independentemente. Sexta-feira, 26 de outubro de 2007 2:34 AM Você está executando o quotcmdquot do console. Se sim, você deve digitar exit também. Sexta-feira, 26 de outubro de 2007 4:50 Se você tiver uma idéia de quanto tempo seu processo vai levar, então você pode usar bool exitted process. WaitForExit (timeInMilliSeconds) se (saída) Processo sair antes do período de tempo limite. Else Mensagem de erro de impressão Isso pode não estar relacionado ao que você está fazendo, mas tive uma experiência em que o processo não iria sair se eu redirecionasse sua saída. Tente desativar o redirecionamento de saída e veja se o processo é encerrado. Experimente, pode funcionar. Sexta-feira, 26 de outubro de 2007 11:58 AM Gostaria de tentar isso, mas é muito um hack. Eu tenho muitos comandos diferentes que levam diferentes períodos de tempo (30 segundos a 25 minutos), então não há configurações de tempo real que eu poderia colocar sem destruir o meu desempenho. Esta função tem funcionado corretamente para vários comandos nos últimos 6 meses e agora ele decide sair comigo. Eu tentei em um computador diferente sem problemas (o que realmente está me mexendo). Eu sei que não é o redirecionamento do outputerror porque uma nova WINDOW está sendo criada no servidor ao qual eu estou remoting. Assim que eu fechar essa janela, meu processo sai como esperado e a saída correta é exibida no lado do Usuário. Obrigado pela sua ajuda, mas estou ficando realmente frustrado com este problema. Sexta-feira, 26 de outubro de 2007 3:01 PM Sem saber o detalhe da mensagem estavam apenas adivinhando o problema. Você instalou o beta 3.5 beta ou o Visual Studio 2008 beta. Como você está usando o Processo para iniciar o programa, Process. Start (quotfile. exequot), ou você está usando ProcessStartInfo sexta-feira, 26 de outubro de 2007 3:21 PM Não, eu tenho 2003 e 2005 instalados. Proc new Process () procSI novo ProcessStartInfo () Em seguida, configurei um novo tópico para o StandardError e StandardOutput, depois escrevo meus comandos e se (redirecionando o padrão para fora) Inicie o thread para st. Out Se (redirecionamento de erro padrão) Inicie thread para st. Erro Proc. WaitForExit () lt -------- é onde ocorre a janela Generic Windows Error Reporting. Eu traduzi o que pude da Janela que aparece. Microsoft Visual Studio 2005 Porque o problema ocorre, ele termina o Microsoft Visual Studio 2005. Aplicando inconvenientes, não há desculpa. Obrigado novamente por todo o seu tempo. Criei o SQL Server do StreamWriter antes de criar o objeto Process Process. Depois, redirecione a entrada após o comando proc. Start (), então, como eu não possuo isso, eu posso fazer a mudança para mover o sIn. Close () para depois da chamada WaitForExit para ver se isso faz alterações. O Proc era um tipo, deveria ter sido proc. Novamente, não é uma mensagem de erro, portanto, não há rastreamento de pilha. O redirecionamento do meu StandardError está vazio eo redirecionamento de saída padrão contém o que eu esperava, mas nada indicando que ocorreu um erro. É por isso que tudo ainda funciona depois que eu fechar a janela de Relatório de Erros do Windows. Eu publicarei o que acontece depois de eu mover a linha sIn. Close () abaixo da linha WaitForExit (). Sexta-feira, 26 de outubro de 2007 16:59 Peter Ritchie escreveu: Você não deseja fechar o objeto sIn até que o aplicativo tenha saído se você estiver redirecionando. Não é necessário fechar nenhum desses fluxos. O objeto Processo os possui e é o responsável pela limpeza depois de si próprio. Deveria, na melhor das hipóteses, chamar Process. Dispose () depois de terminar o objeto Processo. Você certamente não precisa (ou seja, é redundante), mas não deve causar um problema após o processo ter saído. Process. Close é o método recomendado para fechar os fluxos de entrada padrão e padrão (e padrão). Sexta-feira, 26 de outubro de 2007 5:03 PM Eu ficaria surpreso se o método Dispose não chamasse de Fechar, pelo menos como parte de sua operação. Eu preferiria usar o fato de que, desde que o Processo implementa IDisposable (indiretamente através do componente de extensão que o implementa), um deve invocar Dispose e deixar isso para a limpeza adequada. Eu não recomendo invocar Process. Close em vez de, nem além de, Process. Dispose. Sim, descarte as chamadas Fechar. Minha primeira recomendação é usar um bloco de uso, o meu segundo é chamar Close quando você sabe quando você terminar com ele. Em objetos que implementam um método quotClosequot apesar de ser IDisposable, é muito mais claro usar o método quotClosequot. Além disso, sem utilizar um bloco de uso, você não tem como escopo a variável e a chamada para Dispose - o objeto pode ser usado após a chamada para Dispose. Se você usa Close youve, descartou todos os seus recursos gerenciados, mas o objeto ainda pode ser usado (ou seja, ele não foi sinalizado como quotdisposedquot e você pode usá-lo para executar outro aplicativo sem alocar um novo objeto Process - o que, de outra forma, lançaria ObjectDisposedException ). Sexta-feira, 26 de outubro de 2007 18:09 Então, se a primeira recomendação é usar um bloco de uso, então o próximo melhor seria chamar Dispose. Não próximo, quando, como você disse, você sabe que você está feito com o objeto. Ao ligar apenas Close em algo que implementa IDisposable, o desenvolvedor está cometer um erro. Se Dispose fizer alguma limpeza adicional além de apenas delegar para Fechar, então o programador está configurando-se para um bug, apenas ligando para Fechar. Pode haver um caso para chamar Close, mas somente se você não for feito com o objeto, como você indicou na parte inferior da sua última resposta. Mas quando terminar com isso, chame Dispose. Friday, October 26, 2007 6:20 PM Então, se a primeira recomendação é usar um bloco de uso, então o próximo melhor seria chamar Dispose. Não próximo, quando, como você disse, você sabe que você está feito com o objeto. Ao ligar apenas Close em algo que implementa IDisposable, o desenvolvedor está cometer um erro. Se Dispose fizer alguma limpeza adicional além de apenas delegar para Fechar, então o programador está configurando-se para um bug, apenas ligando para Fechar. Pode haver um caso para chamar Close, mas somente se você não for feito com o objeto, como você indicou na parte inferior da sua última resposta. Mas quando terminar com isso, chame Dispose. Na verdade, é muito mais equivalente a: DisposableClass obj new DisposableClass () IDisposable descartable obj como IDisposable se (nulo descartable) Mas sim, isso é o que uma declaração de uso é quotfunctionally equivalentquot, mas eu não concordo explicitamente chamando Dispose na presença de um método quotClosequot deve Seja a primeira escolha por causa da falta de escopo com a chamada Dispose. Por exemplo, o seguinte: usando (processo processo novo processo ()) eu tive o serviço em execução, mas eu parei porque ele tinha funcionado por 2 horas e nunca tinha o ponto de interrupção que deveria ter atingido dentro de 10 minutos de mim, começando meu cliente. Eu não comentei a linha sIn. Close () agora e reiniciei o serviço e o Cliente e tudo está funcionando como antes. Posso acertar o ponto de interrupção após o WaitForExit () e eu concluir, com a mensagem de relatório de erros do Windows ainda (como era antes). Então, no meu caso, PRECISO fechar o fluxo de entrada para poder sair do processo conforme o esperado. Existem outras idéias que eu posso recomendar a linha sIn. Close () se você quiser verificar algo. Sexta-feira, 26 de outubro de 2007 7:19 PM Anthony Maimone escreveu: Eu tinha o serviço funcionando, mas eu parei porque tinha funcionado por 2 horas e nunca tinha o ponto de interrupção que deveria ter atingido dentro de 10 minutos de mim, começando meu cliente . Eu não comentei a linha sIn. Close () agora e reiniciei o serviço e o Cliente e tudo está funcionando como antes. Posso acertar o ponto de interrupção após o WaitForExit () e eu concluir, com a mensagem de relatório de erros do Windows ainda (como era antes). Então, no meu caso, PRECISO fechar o fluxo de entrada para poder sair do processo conforme o esperado. Existem outras idéias que eu posso recomendar a linha sIn. Close () se você quiser verificar algo. Seria útil ver os detalhes da exceção quando você receber o erro (como a pilha de chamadas). Como você está usando a entrada padrão e a saída padrão Você está usando qualquer método ReadLine Peter, meu ponto é: Se você não convoca Dispose em um objeto que implementa (direta ou indiretamente) IDisposable, então você está apenas perguntando por um bug. Ainda não quero argumentar sobre isso infinitamente. Você pode continuar a fazê-lo do jeito que você faz, e eu vou ficar com o meu. Enquanto não tivermos que manter o código uns dos outros, tudo bem. E, a propósito, um bloco de quotusing não o protege também. Nada impede que você declare a variável fora do bloco (se eu me lembro corretamente), então ainda pode estar no escopo após o fim do bloco. Você precisa ser diligente ao escrever o código correto. Se você declara isso na declaração quotusingquot, isso é um caminho. Mas descartar o uso da abordagem experimental apenas porque deixa a variável no escopo não é realmente o ponto. Ainda precisa ser Dispose () d em algum lugar. Sexta-feira, 26 de outubro de 2007 7:34 PM Peter Ritchie escreveu: Anthony Maimone escreveu: eu tinha o serviço funcionando, mas eu parei porque tinha funcionado por 2 horas e nunca tinha o ponto de interrupção que deveria ter atingido dentro de 10 minutos de Eu começando meu cliente. Eu não comentei a linha sIn. Close () agora e reiniciei o serviço e o Cliente e tudo está funcionando como antes. Posso acertar o ponto de interrupção após o WaitForExit () e eu concluir, com a mensagem de relatório de erros do Windows ainda (como era antes). Então, no meu caso, PRECISO fechar o fluxo de entrada para poder sair do processo conforme o esperado. Existem outras idéias que eu posso recomendar a linha sIn. Close () se você quiser verificar algo. Seria útil ver os detalhes da exceção quando você receber o erro (como a pilha de chamadas). Como você está usando a entrada padrão e a saída padrão Você está usando algum método ReadLine Novamente, isso NÃO é uma Exceção que está sendo jogada, então eu não estou vendo detalhes de exceção. Eu não vou diretamente para o bloco catch no meu código, eu retomo DIRECTAMENTE após a chamada WaitForExit (). A janela que recebo é a mesma que você obtém quando CADA produto da Microsoft fecha inesperadamente e MS quer informações sobre o Crash. Então, novamente, não há detalhes de exceção. No entanto, em um dos logs do sistema, estou recebendo uma mensagem (traduzida do japonês) quotDevenv. exe erros de aplicativo ocorrem, 8.0.50727.762 versão dos erros ocorridos módulo msvcr80.dll, versão 8.0.50727.762, erro ocorreu endereço 0x00039001. Para obter mais informações, go. microsoftfwlinkevents. asp o Helo e o Centro de Suporte, consulte. quot Estou redirecionando a entrada padrão para passar nos diferentes comandos porque eu estava tendo problemas para fazê-los funcionar como eu queria formar o StartInfo. Estou redirecionando os fluxos de Saída e Erro para verificar o que eles têm neles depois que o processo foi encerrado. Isso me permitirá verificar qualquer coisa que eu gostaria em qualquer fluxo, uma vez que terminamos. Eu também não permito que nenhum dos threads de redirecionamento de saída ou erro se junte até que o processo tenha passado a chamada WaitForExit. Estou completamente perplexo. Sexta-feira, 26 de outubro de 2007 7:53 PM Peter, meu objetivo é: se você não convocar Dispose em um objeto que implementa (direta ou indiretamente) IDisposable, então você está apenas pedindo um bug. Ainda não quero argumentar sobre isso infinitamente. Você pode continuar a fazê-lo do jeito que você faz, e eu vou ficar com o meu. Enquanto não tivermos que manter o código uns dos outros, tudo bem. Eu não concordo. Não é um quotbugquot para não chamar Dispose. Seus recursos não serão liberados imediatamente, mas o GC os liberará se precisar da memória (assumindo que o padrão Dispose está corretamente implementado e existe um finalizador). Se a classe que você estiver usando implementa um método quotClosequot que não faz todas as mesmas coisas como quotDisposequot, Close deve ser documentado como tal ou há um bug na classe. Nunca encontrei uma classe de estrutura que implemente IDisposable e um método Close () que introduzisse um quotleakquot quando Close foi chamado sem chamar Dispose. O padrão esmagador para DisposeClose é que Dispose call Close, além de definir um quotdisposedquot flag (usado para jogar ObjectDisposedException). Na verdade, isso é detalhado na Referência Geral do Framework: quotOccasionalmente, um nome específico do domínio é mais apropriado do que Dispose. Por exemplo, um encapsulamento de arquivo pode querer usar o nome do método Fechar. Nesse caso, implemente Dispose em particular e crie um método Public Close que chame Dispose. O exemplo de código a seguir ilustra este padrão. Você pode substituir Close com um nome de método apropriado para o seu domínio. quot de Implementar finalizar e descartar para limpar recursos não gerenciados, bem como quotPara determinadas classes de objetos, como arquivos ou objetos de conexão de banco de dados, um método Close melhor representa a operação lógica que Deve ser executado quando o consumidor dos objetos terminar com o objeto. quot de Melhorar o desempenho do código gerenciado (embora também também detalhe quotIn casos bem escritos, ambos são funcionalmente equivalentes. Isso implica que o uso de Fechar é mais claro com quotbetter representaquot.) E, a propósito, um bloco de quotusing não o protege também. Nada impede que você declare a variável fora do bloco (se eu me lembro corretamente), então ainda pode estar no escopo após o fim do bloco. Você precisa ser diligente ao escrever o código correto. Se você declara isso na declaração quotusingquot, isso é um caminho. Mas descartar o uso da abordagem experimental apenas porque deixa a variável no escopo não é realmente o ponto. Ainda precisa ser Dispose () d em algum lugar. Sim, há todos os tipos de maneiras em que você pode se atirar no pé, mas esse não é um cenário que discutimos. Eu pessoalmente abateria qualquer código que eu analisei assim. Isso seria na minha lista não recomendada. Sexta-feira, 26 de outubro de 2007 7:54 PM Novamente, esta NÃO é uma Exceção que está sendo jogada, então não vejo detalhes de exceção. Eu não vou diretamente para o bloco catch no meu código, eu retomo DIRECTAMENTE após a chamada WaitForExit (). A janela que recebo é a mesma que você obtém quando CADA produto da Microsoft fecha inesperadamente e MS quer informações sobre o Crash. Então, novamente, não há detalhes de exceção. No entanto, em um dos logs do sistema, estou recebendo uma mensagem (traduzida do japonês) quotDevenv. exe erros de aplicativo ocorrem, 8.0.50727.762 versão dos erros ocorridos módulo msvcr80.dll, versão 8.0.50727.762, erro ocorreu endereço 0x00039001. Para obter mais informações, go. microsoftfwlinkevents. asp o Helo e o Centro de Suporte, por favor, consulte. Eu assumi que seu aplicativo estava gerando a mensagem (caso em que você sempre deveria obter uma exceção e um rastreamento de pilha), não era claro que você retomasse após a chamada Para WaitForExit (). Parece-me que a aplicação que você está executando está terminando anormalmente. Você está executando devenv. exe. Eu não sei o que você pode fazer em seu aplicativo para impedir que outro aplicativo termine de forma anormal. Anthony Maimone escreveu: Estou redirecionando a entrada padrão para passar nos diferentes comandos porque eu estava tendo problemas para fazê-los funcionar como eu queria formar o StartInfo. Estou redirecionando os fluxos de Saída e Erro para verificar o que eles têm neles depois que o processo foi encerrado. Isso me permitirá verificar qualquer coisa que eu gostaria em qualquer fluxo, uma vez que terminamos. Eu também não permito que nenhum dos threads de redirecionamento de saída ou erro se junte até que o processo tenha passado a chamada WaitForExit. Estou completamente perplexo. Você pode obter um impasse se você bloquear a leitura e o padrão de saída de aplicativos - o que seria desbloquear se você fechou o fluxo, eu acredito. A única coisa em que posso pensar é criar um aplicativo que está sendo executado no servidor e monitorar o Windows que vem formando os processos que você está controlando remotamente e depois encontrar os botões corretos e pressioná-los, programaticamente, empurrando uma mensagem para a bomba de mensagem da janela de diálogo . Este alos acontece com excel, word e outras aplicações que podem ser usadas com autimation O MSFT não criou esses aplicativos para serem executados sem a interação do usuário, então, de vez em quando, você obterá erros do Windows. Você já considerou usar o MSBuid que é mais apropriado para as compilações em lote, também parece que nos servidores de compilação TFS 2008 será fácil de construir. Sábado, 27 de outubro de 2007 11:07 AM Bem, eu tentei usar FindWindow e FindWindowEx junto com SendMessage, mas não consegui encontrar o identificador de janela correto. Mas, como eu sei que uma caixa de Msssage de relatórios de erros do Windows aparecerá, verifiquei se era seu próprio processo (e é). O processo é dwwin. exe (Dr. Watson Win) e tudo o que eu tinha que fazer era isso para me permitir corrigir o problema atual. Substitua o atual bloco de código abaixo para a declaração WaitForExit () que eu tinha anteriormente. Proc. WaitForExit (60000) Processo ProcArray Process Process. GetProcessesByName (quotdwwinquot) foreach (Process ProcessFound no ProcArray) Procuram também verificar se você conseguiu obter o Process. MainWindowTitle (), mas está definido como quotquot. Então, isso é um hack e eu realmente não gosto de usá-lo, mas funciona para a execução atual. Segunda-feira, 29 de outubro de 2007 7:26 PMLets ler o que o MSDN diz sobre isso: A sobrecarga WaitForExit () () () é usada para fazer o segmento atual aguardar até o processo associado terminar. Este método instrui o componente Processo a aguardar uma quantidade infinita de tempo para que o processo saia. Isso pode fazer com que um aplicativo pare de responder. Por exemplo, se você chamar CloseMainWindow para um processo que tenha uma interface de usuário, a solicitação ao sistema operacional para encerrar o processo associado pode não ser tratada se o processo for gravado para nunca entrar no loop de mensagem. Esta sobrecarga garante que todo o processamento foi concluído, incluindo o tratamento de eventos assíncronos para a saída padrão redirecionada. Você deve usar essa sobrecarga após uma chamada para a sobrecarga WaitForExit (Int32) quando a saída padrão foi redirecionada para manipuladores de eventos assíncronos. Isso é, naturalmente, para. O que faz você pensar que não aguarda que o processo Note termine. Quais são os sinais disso. Qual é a prova sexta-feira, 20 de fevereiro de 2009 8:13 PM Não tenho certeza se isso mudou recentemente, mas de volta no dia aplicações na janela O celular nunca foi realmente fechado quando você bateu o X para fechá-los, eles apenas minimizariam e continuavam funcionando em segundo plano (isso não era um bug, era um recurso, já que na próxima vez que você iniciou o aplicativo, ele começaria muito rápido, yah Eu sei, insano, mas verdadeiro), então, por isso, o WaitForExit talvez esteja se comportando estranhamente e aguardando a inicialização do aplicativo em vez de sair. Mas, novamente, é apenas uma especulação baseada em conhecimentos de versões antigas do Windows Mobile. Sexta-feira, 20 de fevereiro de 2009 11:03 PM Id gostaria de colidir esta questão. Estou no Windows Mobile 6 Standard e estou tentando gerar uma instância de navegador. Gostaria de aguardar até o usuário fechar o navegador. Mas WaitForExit retorna extremamente rápido. Aqui está o código: Processo p novo Processo () p. StartInfo. Argumentos quotexample-sitequot p. StartInfo. Verb quotOpenquot p. StartInfo. UseShellExecute falso p. StartInfo. FileName quotIExplore. exequot p. Start () p. WaitForExit () MessageBox. Show (quotNow o navegador deve ser closedquot) Qual deve ser o caminho certo para obter os resubs esperados Segunda-feira, 08 de junho de 2009 10:45 PM Onde o símbolo é. símbolo. AlexB Terça, 09 de junho de 2009 9:58 PM Estou vendo o mesmo problema, mas no XP. Eu acho que a prova pode ser vista em qualquer depurador (como estou vendo), ou em qualquer aplicativo de console (não necessariamente no celular) quarta-feira, 02 de setembro de 2009 8:35 PM Exceto que você não obtém um objeto de processo que você pode usar. Se você tentar Dim myProc As New Process () myProc Process. Start (quotiexplorequot, quotfinance. yahooqhpsquot symbol) myProc. WaitForExit () Ele ainda retorna imediatamente. Quarta-feira, 02 de setembro de 2009 8:48 PM O problema é que você não está iniciando uma nova instância de iexplore. exe. Você está apenas criando uma nova janela no processo existente. O meu palpite é iexplore. exe começa, vê uma instância anterior e se comunica com a instância anterior para que ela abre a nova janela e, em seguida, a instância que você começou a sair imediatamente. Portanto, o comportamento é correto e esperado. Blog. voidnish quarta-feira, 2 de setembro de 2009 8:52 PM A Microsoft está realizando 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. Você gostaria de participar
No comments:
Post a Comment