Verifier si une instance de l'application existe

Bonjour

Je recherche la meilleure et plus simple maniere de verifier si une instance d'APP .NET est déja chargée

J'avoue qu'en cherchant sur Google j'e trouverais sans doute une reponse a cette question mais je me permet ce post car j'aime vraiment tout sur developez (ses membres, sa structure, sa presentation,etc.) SAUF le systeme de recherche :calim2::aie:

Il est généralement plus facile de trouvez des sujet sur developpez via google que par la recherche interne du site et je trouve cela tres dommage !!

Je vais d'ailleurs retapper sur le clou dans un autre post car dans le meme contexte je me documente aussi sur des idées d'execution de Splash screen !

Salut,

J'en connais personnellemennt deux:
- soit utiliser la classe Process afin de savoir si le process en cours est déjà est déjà lançé.
- soit en dérivant de Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase (assembly du runtime VB). Le plus de cette méthode c'est que c'est mieux intégré au système, et qu'il est possible d'avoir un event lors du "relancement" de l'application pour savoir ce qu'il faut faire (par exemple comme dans word).

Bon courage,

Citation:

---

Envoyé par cybermaxs

Salut,

Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase (assembly du runtime VB).
Bon courage,

---

Merci mais sans chercher trop loin tu me parle d'un runtime VB alors que je suis avec .NET et cSharp, donc je me demande si c'est une bonne voie ?

J'ai aussi pensé au Mutex ?

Oui je te parles de runtime VB. Le plus surprenant c'est que j'ai enendu parler de ça dans un livre sur WPF... Il est facilement possible de l'intégrer en prérequis d'un installeur. Ton appli ne subira pas de pertes de perfs non plus.

Il existe aussi le Mutex, c'est vrai. Mais un peu comme le Process, c'est une méthode simple mais qui ne permet pas de logique : ça marche ou pas. Après cela dépend des besoins. Si comme dans un Word, tu dois afficher le document sur lequel tu clic, en réutilisant l'instance Word existante, il vaut mieux utiliser la méthode du runtime VB.
Il est aussi possible de faire çà avec du Remoting, ou via un service WCF auto-hébergé, mais oublions vite, car c'est lourd ...

Bonjour,

J'utilise perso le Mutex et ça fonctionne très bien donc je ne vois pas le problème...

Citation:

---

Envoyé par sisqo60

J'utilise perso le Mutex et ça fonctionne très bien donc je ne vois pas le problème...

---

Process offre un peu plus de possibilité

Par contre l'idée de l'event de cybermaxs me plait !
Cependant le fait que l'on doive utiliser une dll VB m'a completement refroidi
J'ai pas bien analysé ce truc mais il y a quelque chose que n'ai n'ai pas encore capté a ce sujet :roll:

Un bon lien valant mieux qu'un long discours...

Par contre, comme évoqué plus haut, j'ai rencontré cette classe pour la première fois dans un livre sur WPF il y a peu. Après quelques recherches, il semble que le runtine VB ne soit pas requis. Il faut juste une référence à Microsoft.VisualBasic.dll, qui est incluse depuis .Net 2.

Citation:

---

Envoyé par cybermaxs

Il est aussi possible de faire çà avec du Remoting, ou via un service WCF auto-hébergé, mais oublions vite, car c'est lourd ...

---

Justement, je crois que WindowsFormsApplicationBase utilise le remoting... une fois je suis tombé sur une erreur bizarre en utilisant cette classe, et le message d'erreur semblait lié au remoting

C'est vrai que cette classe est bien pratique, et je ne vois vraiment pas pourquoi ils l'ont mise dans un assembly spécifique à VB.NET alors qu'elle serait tout aussi utile en C#... :? (je me pose d'ailleurs la même question pour pas mal d'autres classes de l'assembly Microsoft.VisualBasic...)

Evidemment, ça empêche pas de l'utiliser en C#, mais ça me fait toujours grincer des dents de référencer un assembly qui s'appelle Microsoft.VisualBasic :aie:

Citation:

---

Envoyé par tomlev

Evidemment, ça empêche pas de l'utiliser en C#, mais ça me fait toujours grincer des dents de référencer un assembly qui s'appelle Microsoft.VisualBasic :aie:

---

tu m'étonnes ! sans lancer de polémique, ça me donne l'impression de reculer d'un cran ou deux.

A mon avis, l'isolation par Mutex est la plus sécurisée, c'est un appel système fort (c'est blocant), donc ca garanti bien une seule instance. Je pense que c'est la "bonne pratique".

Cette solution marche sous Citrix & MS server, sans probleme sur de la multisession (l'astuce optimale étant de concaténer dynamiquement le numéro de session avec le nom du mutex afin de le rendre vraiment unique). Tu peux aussi mettre un Mutex au niveau système, pour qu'il n'y ai qu'une seule instance sur toute les sessions // à vérifier pour les droits & co


La solution de lister les process, est beaucoup moins certaine (probleme d'appel concurrent :) ) et pas vraiment élégante. Je ne vois pas dans quel cas, elle peut servir, ou être plus souple, mais c'est une solution envisageable, sans doute pas la "best practice" en tout cas.

A+

Citation:

---

Envoyé par alavoler

A mon avis, l'isolation par Mutex est la plus sécurisée, c'est un appel système fort (c'est blocant), donc ca garanti bien une seule instance. Je pense que c'est la "bonne pratique".

---

Peut-être, mais ça ne fournit aucun moyen d'activer l'instance existante de l'application et de lui transmettre des paramètres...

WindowsFormsApplicationBase se base sur des évènements nommés (EventWaitHandle), ce qui est tout aussi fiable que d'utiliser un Mutex, et gère l'appel à l'instance existante.

@cybermaxs : tu dis que tu avais vu ça dans un bouquin sur WPF, mais je ne vois pas comment on pourrait utiliser ça autrement qu'en WinForms (puisqu'il faut spécifier une Form principale). Le bouquin expliquait comment faire ?

Citation:

---

Envoyé par tomlev

Peut-être, mais ça ne fournit aucun moyen d'activer l'instance existante de l'application et de lui transmettre des paramètres...

WindowsFormsApplicationBase se base sur des évènements nommés (EventWaitHandle), ce qui est tout aussi fiable que d'utiliser un Mutex, et gère l'appel à l'instance existante.

---

+1

Merci a tous !
Voici un sujet fort utile et intéressant :)

Citation:

---

@cybermaxs : tu dis que tu avais vu ça dans un bouquin sur WPF, mais je ne vois pas comment on pourrait utiliser ça autrement qu'en WinForms (puisqu'il faut spécifier une Form principale). Le bouquin expliquait comment faire ?

---

Oui. L'idée est de surcharger OnStartup de WindowsFormsApplicationBase pour appeler une classe dérivée de Application, dans laquelle tu affectes le formulaire principal.

tomlev
Hum j'ai sans doute pas tout suivi le file de la discution

Mais à vue de nez y a 2 besoins bien distinct:
- Ne lancer qu'une seule fois l'application (au sens utilisateur // car techniquement ce ne sera pas réellement le cas)
- Communiquer avec une application

Le premier: on isole l'application avec un Mutex
Le deuxième: en local, on utilise généralement l'IPC // canal nommé, pour communiquer entre 2 applications, c'est rapide et fiable. Après tu peux tjs utiliser une autre methode avec les Event ou autre...

Bon jvais relire le post histoire de pas etre à coté de la plaque

Citation:

---

Envoyé par cybermaxs

Oui. L'idée est de surcharger OnStartup de WindowsFormsApplicationBase pour appeler une classe dérivée de Application, dans laquelle tu affectes le formulaire principal.

---

Ah ok !
En fait, après un petit coup de Reflector, il semblerait que ce soit plutôt OnRun (c'est la méthode qui lance la Form de démarrage)
Merci pour l'info, je crois que je vais me créer une petite classe WpfApplicationBase ;)