Au début de mon application, je lance un processus, et en cas d'arrêt de mon
application (normale ou anormale, je voudrais arrêter le processus que j'ai
lancé et être sûr qu'il sera arrêté.
1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est
arrêté ? Sinon, est-on sûr qu'il va être arrêté ?
2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas
dire que que le processus a été arrêté, mais que le message de fermeture a
été envoyé.
Faut-il appeler la méthode Process.Kill() juste après pour être sûr ? Ou y a
t-il un autre moyen ?
3) La méthode Process.Close() libère toutes les ressources. Lesquelles ?
Et que fait la méthode Process.Dispose() alors ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
adebaene
ShadowFil a écrit :
Bonjour,
Au début de mon application, je lance un processus, et en cas d'arrêt de mon application (normale ou anormale, je voudrais arrêter le processus que j'ai lancé et être sûr qu'il sera arrêté.
1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est arrêté ? Sinon, est-on sûr qu'il va être arrêté ?
C'est indiqué dans la doc : Si Kill échoue, elle lève une exception. Si tu veux être sûr d'attendre que le processus soit effectivement terminé, attends sur le processus après ton appel à Kill (WaitForExit).
2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas dire que que le processus a été arrêté, mais que le message de fe rmeture a été envoyé. Faut-il appeler la méthode Process.Kill() juste après pour être s ûr ? Ou y a t-il un autre moyen ?
Si tu ne contrôles pas le processus cible, il se peut en effet qu'il ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel cas la seule solution est de le tuer. Si tu codes toi-même le processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT (où l'équivalent .NET)
3) La méthode Process.Close() libère toutes les ressources. Lesquelle s ?
Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Arnaud MVP - VC
ShadowFil a écrit :
Bonjour,
Au début de mon application, je lance un processus, et en cas d'arrêt de mon
application (normale ou anormale, je voudrais arrêter le processus que j'ai
lancé et être sûr qu'il sera arrêté.
1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est
arrêté ? Sinon, est-on sûr qu'il va être arrêté ?
C'est indiqué dans la doc : Si Kill échoue, elle lève une exception.
Si tu veux être sûr d'attendre que le processus soit effectivement
terminé, attends sur le processus après ton appel à Kill
(WaitForExit).
2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas
dire que que le processus a été arrêté, mais que le message de fe rmeture a
été envoyé.
Faut-il appeler la méthode Process.Kill() juste après pour être s ûr ? Ou y a
t-il un autre moyen ?
Si tu ne contrôles pas le processus cible, il se peut en effet qu'il
ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel
cas la seule solution est de le tuer. Si tu codes toi-même le
processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT
(où l'équivalent .NET)
3) La méthode Process.Close() libère toutes les ressources. Lesquelle s ?
Si par exemple le processus référencé par ton objet Process est
terminé mais que ton objet Process existe encore, le système garde en
mémoire une "trace" de ce processus terminé, par exemple pour que tu
puisse interroger les propriétés ExitTime et ExitCode. Ce sont les
ressources systèmes correspondantes à ces "traces" qui sont
libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il
est vrai que comme Process implémente IDisposable, la présence d'une
méthode Close peut sembler un peu redondante et pas très logique...
La seule raison que j'y vois, c'est qu'après avoir appelé Close, il
est possible de réutiliser l'objet Process courant en mettant à jour
StartInfo et en appelant Start. Mais franchement, je trouve plus
naturel d'utiliser un autre objet Process si on veut manipuler un
nouveau processus...
En clair, à mon avis le mieux est d'utiliser Dispose.
Au début de mon application, je lance un processus, et en cas d'arrêt de mon application (normale ou anormale, je voudrais arrêter le processus que j'ai lancé et être sûr qu'il sera arrêté.
1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est arrêté ? Sinon, est-on sûr qu'il va être arrêté ?
C'est indiqué dans la doc : Si Kill échoue, elle lève une exception. Si tu veux être sûr d'attendre que le processus soit effectivement terminé, attends sur le processus après ton appel à Kill (WaitForExit).
2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas dire que que le processus a été arrêté, mais que le message de fe rmeture a été envoyé. Faut-il appeler la méthode Process.Kill() juste après pour être s ûr ? Ou y a t-il un autre moyen ?
Si tu ne contrôles pas le processus cible, il se peut en effet qu'il ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel cas la seule solution est de le tuer. Si tu codes toi-même le processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT (où l'équivalent .NET)
3) La méthode Process.Close() libère toutes les ressources. Lesquelle s ?
Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Arnaud MVP - VC
ShadowFil
> > Au début de mon application, je lance un processus, et en cas d'arrêt de
mon
> application (normale ou anormale, je voudrais arrêter le processus que j'ai > lancé et être sûr qu'il sera arrêté. > > 1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est > arrêté ? Sinon, est-on sûr qu'il va être arrêté ? C'est indiqué dans la doc : Si Kill échoue, elle lève une exception. Si tu veux être sûr d'attendre que le processus soit effectivement terminé, attends sur le processus après ton appel à Kill (WaitForExit).
Effectivement, la description des exception peut aider à trouver l'information qui manque.
> 2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas > dire que que le processus a été arrêté, mais que le message de fermeture a > été envoyé. > Faut-il appeler la méthode Process.Kill() juste après pour être sûr ? Ou y a > t-il un autre moyen ? Si tu ne contrôles pas le processus cible, il se peut en effet qu'il ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel cas la seule solution est de le tuer. Si tu codes toi-même le processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT (où l'équivalent .NET)
J'ai trouvé le code suivant dans un programme qui, à mon avis, ne marche pas toujours. Mais je voudrais avoir un autre avis :
Car quand la méthode CloseMainWindow() retourne true, on sait que le message de fermeture a été envoyé, mais on ne sait pas si le processus a réussi à se terminé. Donc, faire un Kill() juste après permet d'être sûr que le process sera arrêté, mais par contre, on ne laisse pas le temps à l'application de s'arrêter normalement avec le message de fermeture envoyé.
> 3) La méthode Process.Close() libère toutes les ressources. Lesquelles ? Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
> Et que fait la méthode Process.Dispose() alors ? La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(), les 2 méthodes sont équivalentes, synonymes.
Donc, le plus simple, c'est de ne jamais utiliser une méthode Close() et de plutôt utiliser directement la méthode Dispose() lorsqu'elle est présente.
C'est vrai qu'une méthode Close() est assez curieux dans un objet Process qui n'a pas de méthode Open() !
> > Au début de mon application, je lance un processus, et en cas d'arrêt de
mon
> application (normale ou anormale, je voudrais arrêter le processus que j'ai
> lancé et être sûr qu'il sera arrêté.
>
> 1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est
> arrêté ? Sinon, est-on sûr qu'il va être arrêté ?
C'est indiqué dans la doc : Si Kill échoue, elle lève une exception.
Si tu veux être sûr d'attendre que le processus soit effectivement
terminé, attends sur le processus après ton appel à Kill
(WaitForExit).
Effectivement, la description des exception peut aider à trouver
l'information qui manque.
> 2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas
> dire que que le processus a été arrêté, mais que le message de fermeture a
> été envoyé.
> Faut-il appeler la méthode Process.Kill() juste après pour être sûr ? Ou y a
> t-il un autre moyen ?
Si tu ne contrôles pas le processus cible, il se peut en effet qu'il
ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel
cas la seule solution est de le tuer. Si tu codes toi-même le
processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT
(où l'équivalent .NET)
J'ai trouvé le code suivant dans un programme qui, à mon avis, ne marche pas
toujours. Mais je voudrais avoir un autre avis :
Car quand la méthode CloseMainWindow() retourne true, on sait que le message
de fermeture a été envoyé, mais on ne sait pas si le processus a réussi à se
terminé. Donc, faire un Kill() juste après permet d'être sûr que le process
sera arrêté, mais par contre, on ne laisse pas le temps à l'application de
s'arrêter normalement avec le message de fermeture envoyé.
> 3) La méthode Process.Close() libère toutes les ressources. Lesquelles ?
Si par exemple le processus référencé par ton objet Process est
terminé mais que ton objet Process existe encore, le système garde en
mémoire une "trace" de ce processus terminé, par exemple pour que tu
puisse interroger les propriétés ExitTime et ExitCode. Ce sont les
ressources systèmes correspondantes à ces "traces" qui sont
libérées quant tu appelles Close.
> Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il
est vrai que comme Process implémente IDisposable, la présence d'une
méthode Close peut sembler un peu redondante et pas très logique...
La seule raison que j'y vois, c'est qu'après avoir appelé Close, il
est possible de réutiliser l'objet Process courant en mettant à jour
StartInfo et en appelant Start. Mais franchement, je trouve plus
naturel d'utiliser un autre objet Process si on veut manipuler un
nouveau processus...
En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(), les 2
méthodes sont équivalentes, synonymes.
Donc, le plus simple, c'est de ne jamais utiliser une méthode Close() et de
plutôt utiliser directement la méthode Dispose() lorsqu'elle est présente.
C'est vrai qu'une méthode Close() est assez curieux dans un objet Process
qui n'a pas de méthode Open() !
> > Au début de mon application, je lance un processus, et en cas d'arrêt de
mon
> application (normale ou anormale, je voudrais arrêter le processus que j'ai > lancé et être sûr qu'il sera arrêté. > > 1) Lorsque la méthode Process.Kill() retourne, est-ce que le processus est > arrêté ? Sinon, est-on sûr qu'il va être arrêté ? C'est indiqué dans la doc : Si Kill échoue, elle lève une exception. Si tu veux être sûr d'attendre que le processus soit effectivement terminé, attends sur le processus après ton appel à Kill (WaitForExit).
Effectivement, la description des exception peut aider à trouver l'information qui manque.
> 2) Lorsque la méthode Process.CloseMainWindow() retourne, ça ne veut pas > dire que que le processus a été arrêté, mais que le message de fermeture a > été envoyé. > Faut-il appeler la méthode Process.Kill() juste après pour être sûr ? Ou y a > t-il un autre moyen ? Si tu ne contrôles pas le processus cible, il se peut en effet qu'il ait été codé pour ne pas tenir compte des demandes d'arrêt, auquel cas la seule solution est de le tuer. Si tu codes toi-même le processus cible, tu sais s'il est conçu ou pas pour gérer WM_QUIT (où l'équivalent .NET)
J'ai trouvé le code suivant dans un programme qui, à mon avis, ne marche pas toujours. Mais je voudrais avoir un autre avis :
Car quand la méthode CloseMainWindow() retourne true, on sait que le message de fermeture a été envoyé, mais on ne sait pas si le processus a réussi à se terminé. Donc, faire un Kill() juste après permet d'être sûr que le process sera arrêté, mais par contre, on ne laisse pas le temps à l'application de s'arrêter normalement avec le message de fermeture envoyé.
> 3) La méthode Process.Close() libère toutes les ressources. Lesquelles ? Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
> Et que fait la méthode Process.Dispose() alors ? La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(), les 2 méthodes sont équivalentes, synonymes.
Donc, le plus simple, c'est de ne jamais utiliser une méthode Close() et de plutôt utiliser directement la méthode Dispose() lorsqu'elle est présente.
C'est vrai qu'une méthode Close() est assez curieux dans un objet Process qui n'a pas de méthode Open() !
Arnaud Debaene
ShadowFil wrote:
J'ai trouvé le code suivant dans un programme qui, à mon avis, ne marche pas toujours. Mais je voudrais avoir un autre avis :
Car quand la méthode CloseMainWindow() retourne true, on sait que le message de fermeture a été envoyé, mais on ne sait pas si le processus a réussi à se terminé. Donc, faire un Kill() juste après permet d'être sûr que le process sera arrêté, mais par contre, on ne laisse pas le temps à l'application de s'arrêter normalement avec le message de fermeture envoyé.
Effectivement, mieux vaut laisser un petit temps raisonnable à l'application pour se terminer, avant de la tuer de force. Quelque chose du genre : myProcess.CloseMainWindow() if (myProcess.WaitForExit(1000)=úlse) { myProcess.Kill(); myProcess.WaitForExit(); } myProcess.Close();
Bien sûr, rajouter la gestion des exceptions dans un code de production.
3) La méthode Process.Close() libère toutes les ressources. Lesquelles ?
Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(), les 2 méthodes sont équivalentes, synonymes.
Je n'ai pas dit que Close appelait dispose, j'ai dit qu'elle faisait un travail de nettoyage similaire. Si tu veux voire le détail, utilises ILDASM, .NET Reflector ou un outil du même genre pour voire le code de ces 2 méthodes.
Appeler Close ne provoque pas l'appel de Component.Dispose, et l'objet est toujours réutilisable après un Close, alors qu'il ne l'est pas (bien entendu) après un Dispose.
C'est vrai qu'une méthode Close() est assez curieux dans un objet Process qui n'a pas de méthode Open() !
Oui, à mon avis c'est une conception douteuse.... pas fausse mais douteuse ;-)
Arnaud MVP - VC
ShadowFil wrote:
J'ai trouvé le code suivant dans un programme qui, à mon avis, ne
marche pas toujours. Mais je voudrais avoir un autre avis :
Car quand la méthode CloseMainWindow() retourne true, on sait que le
message de fermeture a été envoyé, mais on ne sait pas si le
processus a réussi à se terminé. Donc, faire un Kill() juste après
permet d'être sûr que le process sera arrêté, mais par contre, on ne
laisse pas le temps à l'application de s'arrêter normalement avec le
message de fermeture envoyé.
Effectivement, mieux vaut laisser un petit temps raisonnable à l'application
pour se terminer, avant de la tuer de force. Quelque chose du genre :
myProcess.CloseMainWindow()
if (myProcess.WaitForExit(1000)=úlse)
{
myProcess.Kill();
myProcess.WaitForExit();
}
myProcess.Close();
Bien sûr, rajouter la gestion des exceptions dans un code de production.
3) La méthode Process.Close() libère toutes les ressources.
Lesquelles ?
Si par exemple le processus référencé par ton objet Process est
terminé mais que ton objet Process existe encore, le système garde en
mémoire une "trace" de ce processus terminé, par exemple pour que tu
puisse interroger les propriétés ExitTime et ExitCode. Ce sont les
ressources systèmes correspondantes à ces "traces" qui sont
libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose().
Il
est vrai que comme Process implémente IDisposable, la présence d'une
méthode Close peut sembler un peu redondante et pas très logique...
La seule raison que j'y vois, c'est qu'après avoir appelé Close, il
est possible de réutiliser l'objet Process courant en mettant à jour
StartInfo et en appelant Start. Mais franchement, je trouve plus
naturel d'utiliser un autre objet Process si on veut manipuler un
nouveau processus...
En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(),
les 2 méthodes sont équivalentes, synonymes.
Je n'ai pas dit que Close appelait dispose, j'ai dit qu'elle faisait un
travail de nettoyage similaire. Si tu veux voire le détail, utilises ILDASM,
.NET Reflector ou un outil du même genre pour voire le code de ces 2
méthodes.
Appeler Close ne provoque pas l'appel de Component.Dispose, et l'objet est
toujours réutilisable après un Close, alors qu'il ne l'est pas (bien
entendu) après un Dispose.
C'est vrai qu'une méthode Close() est assez curieux dans un objet
Process
qui n'a pas de méthode Open() !
Oui, à mon avis c'est une conception douteuse.... pas fausse mais douteuse
;-)
Car quand la méthode CloseMainWindow() retourne true, on sait que le message de fermeture a été envoyé, mais on ne sait pas si le processus a réussi à se terminé. Donc, faire un Kill() juste après permet d'être sûr que le process sera arrêté, mais par contre, on ne laisse pas le temps à l'application de s'arrêter normalement avec le message de fermeture envoyé.
Effectivement, mieux vaut laisser un petit temps raisonnable à l'application pour se terminer, avant de la tuer de force. Quelque chose du genre : myProcess.CloseMainWindow() if (myProcess.WaitForExit(1000)=úlse) { myProcess.Kill(); myProcess.WaitForExit(); } myProcess.Close();
Bien sûr, rajouter la gestion des exceptions dans un code de production.
3) La méthode Process.Close() libère toutes les ressources. Lesquelles ?
Si par exemple le processus référencé par ton objet Process est terminé mais que ton objet Process existe encore, le système garde en mémoire une "trace" de ce processus terminé, par exemple pour que tu puisse interroger les propriétés ExitTime et ExitCode. Ce sont les ressources systèmes correspondantes à ces "traces" qui sont libérées quant tu appelles Close.
Et que fait la méthode Process.Dispose() alors ?
La même chose que Close, et en plus il appelle Component.Dispose(). Il est vrai que comme Process implémente IDisposable, la présence d'une méthode Close peut sembler un peu redondante et pas très logique... La seule raison que j'y vois, c'est qu'après avoir appelé Close, il est possible de réutiliser l'objet Process courant en mettant à jour StartInfo et en appelant Start. Mais franchement, je trouve plus naturel d'utiliser un autre objet Process si on veut manipuler un nouveau processus... En clair, à mon avis le mieux est d'utiliser Dispose.
Si Close() appelle Dispose() qui appelle forcément base.Dispose(), les 2 méthodes sont équivalentes, synonymes.
Je n'ai pas dit que Close appelait dispose, j'ai dit qu'elle faisait un travail de nettoyage similaire. Si tu veux voire le détail, utilises ILDASM, .NET Reflector ou un outil du même genre pour voire le code de ces 2 méthodes.
Appeler Close ne provoque pas l'appel de Component.Dispose, et l'objet est toujours réutilisable après un Close, alors qu'il ne l'est pas (bien entendu) après un Dispose.
C'est vrai qu'une méthode Close() est assez curieux dans un objet Process qui n'a pas de méthode Open() !
Oui, à mon avis c'est une conception douteuse.... pas fausse mais douteuse ;-)
