Cette question peut sembler un peu bizarre mais je tente d'exécuter VS2005 à travers un processus et d'exécuter une commande spécifique et je waitforexit (). Je réoriente mon entrée et la sortie avec succès mais de temps en temps je reçois un Window WindowMessage de rapport d'erreur. Le problème est que je remoting, donc quand cette fenêtre de message se produit pendant l'exécution de processus, je vais accrocher à moins que je me connecte dans l'autre machine (remoting) et ferme la fenêtre. Y at il un moyen de programmetiquement tuer cette fenêtre ou éventuellement désactiver le messagewindow de se produire J'ai pensé à courir VS dans une exécution silencieuse (je n'ai pas encore trouvé un moyen de le faire). J'ai aussi essayé de voir s'il ya quelque chose d'être lancé quand cela se produit comparer à quand il ne fait pas. Jeudi, Octobre 25, 2007 8:32 PM Bien, j'ai essayé d'utiliser FindWindow et FindWindowEx avec SendMessage mais je n'arrivais pas à trouver la bonne poignée de fenêtre. Mais comme je sais qu'une boite de Msssage de rapports d'erreurs de Windows apparaîtra, j'ai vérifié si c'était son propre processus (et c'est le cas). Le processus est dwwin. exe (Dr. Watson Win) et tout ce que je devais faire était de me permettre de corriger le problème actuel. Remplacez le bloc de code actuel ci dessous pour l'instruction WaitForExit () que j'avais précédemment. Proc. WaitForExit (60000) une minute Process ProcArray Process. GetProcessesByName (quotdwwinquot) foreach (Process ProcessFound dans ProcArray) J'ai également vérifié si vous pouviez obtenir le Process. MainWindowTitle (), mais il est défini sur quotquot. Donc, c'est un hack et je n'aime vraiment pas l'utiliser, mais ça marche pour l'exécution courante. Lundi 29 octobre 2007 19h26 Non, je peux rediriger les entrées et les sorties sans problème. L'erreur que je reçois est le rapport général d'erreur de fenêtres et malheureusement, il est en japonais donc je ne sais pas ce que l'erreur exacte est, mais c'est l'erreur générale. Je n'ai pas le code en face de moi, mais j'ai mis en place delegatesthreads à lire redirigé l'erreur et la sortie après que je quitte le processus entier. Je ne peux pas trouver quelque chose et je suis capable d'exécuter le même processus sur mon propre ordinateur, mais je ne suis pas en mesure de faire une commande particulière par le biais de la télécommande. Je vais l'essayer demain en télécommande sur une machine non japonaise au travail et je publierai mes résultats de toute façon. Vendredi 26 octobre 2007 02h34 Vous utilisez la console quotcmdquot. Si oui, vous devez taper exit aussi. Si vous avez une idée de combien de temps votre processus va prendre, alors vous pouvez utiliser bool exitted process. WaitForExit (timeInMilliSeconds) if (exitted) Le processus a quitté avant la période d'expiration. Else Message d'erreur d'impression Cela peut ne pas être lié à ce que vous faites, mais j'ai eu une expérience où le processus ne serait pas la sortie si j'ai redirigé sa sortie. Essayez de désactiver la redirection de sortie et de voir si le processus se termine. Essayez le, ça pourrait marcher. Vendredi 26 octobre 2007 11:58 Je voudrais essayer, mais c'est trop d'un hack. J'ai trop de commandes différentes qui prennent différentes quantités de temps (30 secondes à 25 minutes), donc il n'y a pas de réglage en temps réel que je pourrais placer sans détruire ma performance. Cette fonction a fonctionné correctement pour plusieurs commandes au cours des 6 derniers mois et maintenant, il décide de sortir sur moi. Je l'ai essayé sur un ordinateur différent sans aucun problème (qui est vraiment messing avec moi). Je sais que ce n'est pas la redirection outputerror car une nouvelle fenêtre est en cours de création sur le serveur que je remoting à. Dès que je ferme cette fenêtre, mon processus sort comme prévu et la sortie correcte est affichée du côté utilisateur. Merci de votre aide, mais je suis vraiment frustré par ce problème. Friday, October 26, 2007 3:01 PM Sans connaître le détail du message étaient juste deviner le problème. Est ce que vous avez installé 3.5 bêta ou Visual Studio 2008 bêta à tous Comment utilisez vous Process pour démarrer le programme, Process. Start (quotfile. exequot), ou utilisez ProcessStartInfo vendredi 26 octobre 2007 15:21 Non, j'ai 2003 et 2005 installés. Proc new Process () procSI new ProcessStartInfo () J'ai ensuite mis en place un nouveau thread pour les deux StandardError et StandardOutput puis écrire mes commandes et if (redirection standard) Start thread pour st. Out Si (redirection d'erreur standard) Démarrer le thread pour st. Erreur Proc. WaitForExit () lt c'est là que la fenêtre Generic Windows Error Reporting se produit. J'ai traduit ce que je pouvais de la fenêtre qui apparaît. Microsoft Visual Studio 2005 Parce que le problème se produit, il met fin à Microsoft Visual Studio 2005. Nous appliquant des inconvénients, il n'ya aucune excuse. Merci encore pour tout votre temps. J'ai créé StreamWriter sIn avant de créer l'objet processus proc. Je puis rediriger l'entrée après la commande proc. Start (), alors comment ne pas posséder ce Regardless, je peux faire le changement pour déplacer le sIn. Close () après l'appel WaitForExit pour voir si cela apporte des modifications. Le Proc était un type, il aurait dû être proc. Encore une fois, ce n'est pas un message d'erreur, donc il n'y a pas de trace de pile. Ma redirection StandardError est vide et la redirection Standard OUtput contient ce que j'attendais, mais rien ne signale qu'une erreur s'est produite. C'est pourquoi tout fonctionne toujours après avoir fermé la fenêtre Rapport d'erreurs Windows. Je vais poster ce qui se passe après avoir déplacé la ligne sIn. Close () sous la ligne WaitForExit (). Vendredi 26 octobre 2007 16:59 Peter Ritchie a écrit: Vous ne voulez pas fermer l'objet sIn jusqu'à ce que l'application a quitté si youre redirection. On ne devrait pas fermer aucun de ces flux à tous. L'objet Process leur appartient et c'est lui qui est responsable du nettoyage après lui même. On devrait au mieux appeler Process. Dispose () après avoir terminé avec l'objet Process. Vous n'avez certainement pas besoin (c'est à dire redondant) mais il ne devrait pas causer un problème après que le processus a quitté. Process. Close est la méthode recommandée pour fermer les flux standardinput et standardoutput (et standarderror). Vendredi 26 octobre 2007 17:03 Je serais surpised si la méthode Dispose n'a pas appelé Close, au moins dans le cadre de son fonctionnement. Je voudrais favoriser l'utilisation du fait que, puisque Process implémente IDisposable (indirectement par l'extension du composant qui l'implémente), on devrait invoquer Dispose et laisser cela au bon nettoyage. Je ne recommanderais pas invoquant Process. Close au lieu de, ni en plus, Process. Dispose. Oui, Éliminer les appels Fermer. Ma première recommandation est d'utiliser un bloc d'utilisation, mon deuxième est d'appeler Close quand vous savez quand vous avez fait avec elle. Dans les objets qui implémentent une méthode quotClosequot en dépit d'être IDisposable, il est beaucoup plus clair d'utiliser la méthode quotClosequot. De plus, sans utiliser un bloc d'utilisation, vous n'avez aucun moyen de définir la variable et l'appel à Dispose l'objet peut être utilisé après l'appel à Dispose. Si vous utilisez Close youve, disposez de toutes vos ressources managées, mais l'objet peut encore être utilisé (c'est à dire qu'il n'a pas été marqué comme quotdisposedquot et vous pouvez l'utiliser pour exécuter une autre application sans allouer un nouvel objet Process qui jetterait un ObjectDisposedException ). Vendredi 26 octobre 2007 18h09 Donc, si la première recommandation est d'utiliser un bloc d'utilisation, alors le mieux serait d'appeler Dispose. Pas Fermer, quand, comme vous l'avez dit, vous savez que vous avez fait avec l'objet. En appelant seulement Close sur quelque chose qui implémente IDisposable, le développeur est potentiellement une erreur. Si Dispose effectue un nettoyage supplémentaire au delà de la simple délégation à Fermer, le programmeur se configure lui même pour un bogue en appelant simplement Fermer. Il peut y avoir un cas pour appeler Close, mais seulement si youre pas fait avec l'objet, comme vous l'avez indiqué au bas de votre dernière réponse. Mais lorsque vous avez terminé, appelez Dispose. Alors, si la première recommandation est d'utiliser un bloc d'utilisation, alors le mieux serait d'appeler Dispose. Pas Fermer, quand, comme vous l'avez dit, vous savez que vous avez fait avec l'objet. En appelant seulement Close sur quelque chose qui implémente IDisposable, le développeur est potentiellement une erreur. Si Dispose effectue un nettoyage supplémentaire au delà de la simple délégation à Fermer, le programmeur se configure lui même pour un bogue en appelant simplement Fermer. Il peut y avoir un cas pour appeler Close, mais seulement si youre pas fait avec l'objet, comme vous l'avez indiqué au bas de votre dernière réponse. Mais lorsque vous avez terminé, appelez Dispose. En fait, son équivalent quotmorequot: DisposableClass obj nouveau DisposableClass () IDisposable jetable obj comme IDisposable si (jetable null) Mais oui, thats ce que une instruction using est quotamentalement équivalent à, mais je ne suis pas d'accord appelant explicitement Dispose en présence d'une méthode quotClosequot devrait Être le premier choix en raison de l'absence de portée avec l'appel Dispose. Par exemple, ce qui suit: using (Process process new Process ()) J'ai eu le service en cours d'exécution, mais je l'ai arrêté car il avait couru pendant 2 heures et n'a jamais eu le point d'arrêt qu'il aurait dû frapper dans les 10 minutes client. J'ai décommented la ligne sIn. Close () juste maintenant et relancé le service et le client et tout fonctionne comme il a fait auparavant. Je peux frapper le point d'arrêt après le WaitForExit () et je termine, avec le message de rapport d'erreur de Windows toujours (comme c'était avant). Donc, dans mon cas, j'ai besoin de fermer le flux d'entrée pour pouvoir quitter le processus comme prévu. Existe t il d'autres idées que je peux recommander la ligne sIn. Close () si vous souhaitez vérifier quelque chose. Jeudi, Octobre 26, 2007 7:19 Anthony Maimone a écrit: J'ai eu le service en cours d'exécution, mais je l'ai arrêté parce qu'il avait couru pendant 2 heures et n'a jamais eu le point d'arrêt qu'il aurait dû frapper dans les 10 minutes de commencer mon client . J'ai décommented la ligne sIn. Close () juste maintenant et relancé le service et le client et tout fonctionne comme il a fait auparavant. Je peux frapper le point d'arrêt après le WaitForExit () et je termine, avec le message de rapport d'erreur de Windows toujours (comme c'était avant). Donc, dans mon cas, j'ai besoin de fermer le flux d'entrée pour pouvoir quitter le processus comme prévu. Existe t il d'autres idées que je peux recommander la ligne sIn. Close () si vous souhaitez vérifier quelque chose. Il serait utile de voir les détails d'exception lorsque vous obtenez l'erreur (comme la pile d'appels). Si vous n'appelez pas Dispose sur un objet qui implémente (directement ou indirectement) IDisposable, alors vous êtes juste demander un bogue. Je ne veux pas discuter sur ce sans fin cependant. Vous pouvez continuer à le faire de la façon dont vous le faites, et le bâton mal avec le mien. Tant que nous n'avons pas à maintenir les uns les autres code, bien. Et d'ailleurs, un bloc quotusingquot ne vous protège pas non plus. Rien ne vous empêche de déclarer la variable en dehors du bloc (si je me souviens bien), de sorte qu'il peut encore être dans la portée après la fin du bloc. Vous devez être diligent en écrivant le code correct. Si vous le déclarez dans l'instruction quotusingquot, c'est une façon. Mais de rejeter en utilisant l'approche tryfinally juste parce qu'il laisse la variable dans la portée n'est pas vraiment le point. Il doit toujours être Dispose () d quelque part. J'ai écrit le service, mais je l'ai arrêté parce qu'il avait fonctionné pendant 2 heures et n'avait jamais le point d'arrêt qu'il aurait dû frapper dans les 10 minutes de Moi commençant mon client. J'ai décommented la ligne sIn. Close () juste maintenant et relancé le service et le client et tout fonctionne comme il a fait auparavant. Je peux frapper le point d'arrêt après le WaitForExit () et je termine, avec le message de rapport d'erreur de Windows toujours (comme c'était avant). Donc, dans mon cas, j'ai besoin de fermer le flux d'entrée pour pouvoir quitter le processus comme prévu. Existe t il d'autres idées que je peux recommander la ligne sIn. Close () si vous souhaitez vérifier quelque chose. Il serait utile de voir les détails d'exception lorsque vous obtenez l'erreur (comme la pile d'appels). Comment utilisez vous l'entrée standard et la sortie standard Utilisez vous des méthodes ReadLine Encore une fois, ce n'est pas une exception qui est lancée, donc je ne vois aucun détail d'exception. Je n'allez pas directement au bloc catch dans mon code, je reprends DIRECTEMENT après l'appel WaitForExit (). La fenêtre que je reçois est la même que vous obtenez lorsque n'importe quel produit Microsoft se ferme inopinément et MS veut des informations sur le Crash. Encore une fois, il n'y a pas de détails d'exception. Cependant, dans l'un des journaux du système, je reçois un message (traduit du japonais) erreur quotDevenv. exe application se produisent, 8.0.50727.762 version des erreurs survenues msvcr80.dll module, version 8.0.50727.762, les erreurs se sont produites adresse 0x00039001. Pour plus d'informations, go. microsoftfwlinkevents. asp le Helo et Support Center s'il vous plaît refer. quot je redirige l'entrée standard pour passer dans les différentes commandes en parce que j'avais du mal à les faire fonctionner comment je voulais former le StartInfo. Je redirige les flux de sortie et d'erreur pour vérifier ce qu'ils contiennent après la fin du processus. Cela me permettra de vérifier tout ce que je voudrais dans les deux flux une fois que nous avons terminé. Je n'autorise pas non plus que les threads de sortie ou de redirection d'erreur se joignent jusqu'à ce que le processus ait passé l'appel WaitForExit. Je suis complètement perplexe. Vendredi 26 octobre 2007 19:53 Peter, mon point est: Si vous n'avez pas appeler Dispose sur un objet qui implémente (directement ou indirectement) IDisposable, alors vous êtes juste demander un bogue. Je ne veux pas discuter sur ce sans fin cependant. Vous pouvez continuer à le faire de la façon dont vous le faites, et le bâton mal avec le mien. Tant que nous n'avons pas à maintenir les uns les autres code, bien. Je ne suis pas d'accord. Ce n'est pas un quotbugquot de ne pas appeler Dispose. Vos ressources ne seront pas libérées immédiatement, mais le GC les libérera s'il a besoin de la mémoire (en supposant que le modèle Dispose est correctement implémenté et qu'un finalizer existe). Si la classe que vous utilisez implémente une méthode quotClosequot qui ne fait pas toutes les mêmes choses que quotDisposequot, Close doit être documentée comme telle ou theres un bogue dans la classe. Ive jamais rencontré une classe d'infrastructure qui implémente IDisposable et une méthode Close () qui a introduit un quotleakquot lorsque Close a été appelée sans appeler Dispose. Le modèle écrasant pour DisposeClose est que Dispose appelle Close ainsi que le paramètre quotdisposedquot (utilisé pour lancer ObjectDisposedException). En fait, cela est détaillé dans le cadre Référence générale: quotOccasionally un nom de domaine spécifique est plus approprié que Dispose. Par exemple, une encapsulation de fichier peut vouloir utiliser le nom de la méthode Fermer. Dans ce cas, appliquez Dispose en privé et créez une méthode Close publique qui appelle Dispose. L'exemple de code suivant illustre ce modèle. Vous pouvez remplacer Close par un nom de méthode approprié à votre domain. quot de Mise en œuvre Finalize et Dispose pour nettoyer les ressources non gérées Ainsi que quotFor certaines classes d'objets, tels que les fichiers ou les objets de connexion de base de données, une méthode Close représente mieux l'opération logique qui Doit être exécutée lorsque le consommateur d'objets est fini avec l'objet. dans Improving Managed Code Performance (bien qu'il indique également quotIn cas bien écrits, les deux sont fonctionnellement équivalent. quot il implique que l'utilisation de Close est plus clair avec quotbetter representaquot.) Et d'ailleurs, un bloc quotusingquot ne vous protège pas non plus. Rien ne vous empêche de déclarer la variable en dehors du bloc (si je me souviens bien), de sorte qu'il peut encore être dans la portée après la fin du bloc. Vous devez être diligent en écrivant le code correct. Si vous le déclarez dans l'instruction quotusingquot, c'est une façon. Mais de rejeter en utilisant l'approche tryfinally juste parce qu'il laisse la variable dans la portée n'est pas vraiment le point. Il doit toujours être Dispose () d quelque part. Oui, theres toutes sortes de façons, vous pouvez tirer vous même dans le pied, mais ce n'est pas un scénario, nous avons discuté. Personnellement, je abattre tout code que j'ai examiné comme ça. Ce serait sur ma liste non recommandée. Vendredi 26 octobre 2007 19:54 Encore une fois, ce n'est pas une exception qui est lancée, donc je ne vois pas de détails d'exception. Je n'allez pas directement au bloc catch dans mon code, je reprends DIRECTEMENT après l'appel WaitForExit (). La fenêtre que je reçois est la même que vous obtenez lorsque n'importe quel produit Microsoft se ferme inopinément et MS veut des informations sur le Crash. Encore une fois, il n'y a pas de détails d'exception. Cependant, dans l'un des journaux du système, je reçois un message (traduit du japonais) erreur quotDevenv. exe application se produisent, 8.0.50727.762 version des erreurs survenues msvcr80.dll module, version 8.0.50727.762, les erreurs se sont produites adresse 0x00039001. Pour plus d'informations, go. microsoftfwlinkevents. asp le Helo et Support Center s'il vous plaît refer. quot J'ai supposé que votre application générait le message (auquel cas vous devriez toujours obtenir une exception et une trace de pile) il n'était pas clair que vous reprendre après l'appel À WaitForExit (). Il me semble que l'application que vous exécutez se termine de façon anormale. Êtes vous en cours devenv. exe Je ne sais pas ce que vous pouvez faire dans votre application pour empêcher une autre application de se terminer anormalement. Anthony Maimone a écrit: Je redirige l'entrée standard pour passer dans les différentes commandes en parce que j'avais du mal à les faire fonctionner comment je voulais former le StartInfo. Je redirige les flux de sortie et d'erreur pour vérifier ce qu'ils contiennent après la fin du processus. Cela me permettra de vérifier tout ce que je voudrais dans les deux flux une fois que nous avons terminé. Je n'autorise pas non plus que les threads de sortie ou de redirection d'erreur se joignent jusqu'à ce que le processus ait passé l'appel WaitForExit. Je suis complètement perplexe. Vous pouvez obtenir une impasse si vous bloquez sur la lecture et la sortie standard des applications qui serait débloquer si vous avez fermé le flux, je crois. La seule chose que je peux penser est la création d'une application qui s'exécute sur le serveur et les fenêtres de surveillance comming forme les processus que vous contrôlez à distance et puis trouver les bons boutons et les appuyer par programmeticaly en envoyant un message à la pompe de message de la fenêtre de dialogue . Cette alos se passe avec Excel, Word et autres applications qui peuvent être utilisés avec autimation MSFT n'a pas conçu ces applications pour être exécuté sans interaction avec l'utilisateur de sorte que de temps en temps vous obtiendrez des fenêtres sur les erreurs. Avez vous envisagé d'utiliser MSBuid qui est plus approprié pour les compilations par lots, il semble aussi que dans les serveurs de construction TFS 2008 sera facile à construire. Samedi 27 octobre 2007 11:07 Bien, j'ai essayé d'utiliser FindWindow et FindWindowEx avec SendMessage mais je n'ai pas pu trouver le handle de fenêtre correct. Mais comme je sais qu'une boite de Msssage de rapports d'erreurs de Windows apparaîtra, j'ai vérifié si c'était son propre processus (et c'est le cas). Le processus est dwwin. exe (Dr. Watson Win) et tout ce que je devais faire était de me permettre de corriger le problème actuel. Remplacez le bloc de code actuel ci dessous pour l'instruction WaitForExit () que j'avais précédemment. Proc. WaitForExit (60000) une minute Process ProcArray Process. GetProcessesByName (quotdwwinquot) foreach (Process ProcessFound dans ProcArray) J'ai également vérifié si vous pouviez obtenir le Process. MainWindowTitle (), mais il est défini sur quotquot. Donc, c'est un hack et je n'aime vraiment pas l'utiliser, mais ça marche pour l'exécution courante. Monday, October 29, 2007 7:26 PMLets lire ce que MSDN dit à ce sujet: La surcharge WaitForExit () () () est utilisée pour rendre le thread actuel attente jusqu'à ce que le processus associé se termine. Cette méthode demande au composant Process d'attendre une quantité infinie de temps pour que le processus quitte. Cela peut provoquer une application pour cesser de répondre. Par exemple, si vous appelez CloseMainWindow pour un processus qui a une interface utilisateur, la demande au système d'exploitation de terminer le processus associé peut ne pas être gérée si le processus est écrit pour ne jamais entrer sa boucle de message. Cette surcharge garantit que tous les traitements sont terminés, y compris la gestion des événements asynchrones pour la sortie standard redirigée. Vous devez utiliser cette surcharge après un appel à la surcharge WaitForExit (Int32) lorsque la sortie standard a été redirigée vers les gestionnaires d'événements asynchrones. C'est bien sûr pour. Ce qui vous fait penser qu'il n'attend pas que le processus Note se termine Quels sont les signes de cela Quelle est la preuve Vendredi, Février 20, 2009 8:13 PM Je ne sais pas si cela a changé récemment, mais de retour dans les applications jour sur la fenêtre Mobile n'a jamais vraiment fermé lorsque vous avez frappé le X pour les fermer, ils auraient juste de minimiser et de continuer à courir en arrière plan (ce n'était pas un bug, c'était une fonctionnalité, car la prochaine fois que vous démarrez l'application, il serait démarré très vite, yah Je sais, fou, mais vrai) de sorte que pourrait être pourquoi WaitForExit est peut être se comporter étrangement et attendre le démarrage de l'application au lieu de la sortie. Mais encore une fois c'est juste la spéculation basée sur le savoir des anciennes versions de Windows Mobile. Vendredi 20 février 2009 23h03 J'aimerais aborder cette question. Im sur Windows Mobile 6 Standard et Im essayant de frayer une instance de navigateur. J'aimerais attendre que l'utilisateur ferme le navigateur. Mais WaitForExit retourne extrêmement rapide. Voici le code: Process p nouveau Process () p. StartInfo. Arguments quotexample sitequot p. StartInfo. Verb quotOpenquot p. StartInfo. UseShellExecute faux p. StartInfo. FileName quotIExplore. exequot p. Start () p. WaitForExit () MessageBox. Show (quotNow le navigateur doit être closedquot) Quelle devrait être la bonne façon d 'obtenir les résultats attendus lundi, 08 juin 2009 22h45 Où symbole est. symbole. AlexB Tuesday, June 09, 2009 21:58 Im voyant le même problème, mais sur XP. Je pense que la preuve peut être vu dans n'importe quel débogueur (comme je le vois), ou dans n'importe quelle application de console (pas nécessairement sur Mobile), sauf que vous n'avez pas alors obtenir un objet de processus que vous pouvez utilisation. Si vous essayez Dim myProc As New Process () myProc Process. Start (quotiexplorequot, quotfinance. yahooqhpsquot symbole) myProc. WaitForExit () Il retourne toujours immédiatement. Mercredi, 02 septembre 2009 20h48 Le problème est que vous ne démarrez pas une nouvelle instance de iexplore. exe. Vous créez simplement une nouvelle fenêtre sur le processus existant. Ma conjecture est iexplore. exe commence, voit une instance précédente et communique avec l'instance précédente de sorte qu'elle ouvre la nouvelle fenêtre, et alors cette instance que vous avez commencée les sorties immédiatement. Donc, le comportement est correct et à prévoir. Blog. voidnish mercredi, 02 septembre 2009 20:52 Microsoft mène actuellement un sondage en ligne pour comprendre votre opinion sur le site Web Msdn. Si vous choisissez de participer, le sondage en ligne vous sera présenté lorsque vous quitterez le site Web Msdn. Voudriez vous participer
No comments:
Post a Comment