[C#][Taches de fond] Méthode?

Version imprimable

28/01/2008, 17h29
bakonu

[C#][Taches de fond] Méthode?

Bonjour,

Voilà, j'aimerais faire un petit programme sans fenetres (utilisant eventuellement des messages box), qui puisse etre capable de lister la liste des processus windows en execution afin d'y effectuer des contrôles.

Je vois deux possibilités. Et je ne sais pas si la 2ème solution est réalisable.

1. Faire un Timer qui va me lister les processus toutes les secondes : ca ne me semble pas très propre comme méthode, même si ca suffirait pour les contrôles que je veux faire.

2. Si il existe un evenement permettant de gerer les changements dans la liste des processus, ca serait parfait.

Dans les deux cas, je n'ai aucune idée de comment faire une appli en tâche de fond sans que ca soit un service système ou une appli fenêtrée(s).

Si quelqu'un pouvait juste m'éclairer là dessus, et me dire par la même occasion si la 2ème solution est envisageable, ca serait sympa.
28/01/2008, 17h35
ced600

Pourquoi ne pas faire un service windows ?
C'est totallement adapté à ce genre d'application.

Tu peux mettre une application en caché (une propriété de form je crois), mais alors je ne pense pas que tu auras la possibilité d'utiliser des messages box.

Avec un service windows tu peux avoir un interfaçage avec le bureau mais c'est déconseillé.
28/01/2008, 17h39
mrrenard

pour l'apparition des processus tu es obligé de faire un truc lourding avec ta première solution. Sinon faut aller chercher du coté des API win32 y'a peut-être une solution, mais là y'a du boulot et puis c'est moche. Utilisé les API c'est le moyen le plus sur que sont appli ne soit pas portable.
28/01/2008, 17h50
ced600

Citation:

Envoyé par mrrenard

pour l'apparition des processus tu es obligé de faire un truc lourding avec ta première solution. Sinon faut aller chercher du coté des API win32 y'a peut-être une solution, mais là y'a du boulot et puis c'est moche. Utilisé les API c'est le moyen le plus sur que sont appli ne soit pas portable.

+1
Même avec mono, ton appli ne tournera pas sous linux :aie:
28/01/2008, 18h09
Guulh

En même temps, faire une appli de gestion des processus portable, j'y crois moyen, étant donné que les process windows sont sensiblement différents de ceux de Linux :)
Et

Citation:

comment faire une appli en tâche de fond

C'est quoi pour toi une appli en tâche de fond ? Toutes les applis le sont, somewhere :) Tu veux dire sans bouton dans la barre de tâches, mais une icone dans la barre de notification ?
29/01/2008, 09h33
bakonu

En fait, mon appli serait liée à une base de données centrale.

Et le but de cette appli, est de pouvoir empêcher l'utilisateur windows d'utiliser certains programmes (donc terminer le processus s'il est lancé) si certaines conditions dans la base de données ne sont pas remplies.

Je ne peux pas utiliser les services windows, car alerter l'utilisateur, quand il est bloqué, est très important.

Je précise que l'appli ne viserait que Windows xp et éventuellement vista. En tout cas, ca resterait une application Windows, pas besoin de portabilité vers Linux.

Par tâche de fond, je voulais dire que l'utilisateur ne voit pas du tout l'existence du programme (démarré à l'ouverture de session Windows), excepté les éventuels messages d'alertes.
29/01/2008, 09h45
ced600

Bon moi je fais du VBS en plus du C#.
Si je devais faire ce que tu souhaites faire, je ferais un script qui fais ce travail, et que j'affecterais ce script à l'ouverture de la session.
Ainsi tout se ferais en background, et tu pourrais faire des pop up d'alerte utilisateur.
Bon bien sur, il est visible dans le gestionnaire des processus, mais les applications c# aussi :aie:

Je crois que tu peux faire du script en C#.
29/01/2008, 10h58
bakonu

oui, si je peux executer du VBS avec C#, je fais mes popup en VBS (mon niveau en VBS est trop faible pour faire la totalité de l'appli en VBS).

Celà me permettrait de mettre mon appli en service système.
Cependant, il resterait le problème de la connexion utilisateurs, j'ai absolument besoin qu'une session soit ouverte pour que le controle ait de la valeur.
29/01/2008, 11h04
Bluedeep

Citation:

Envoyé par mrrenard

Utilisé les API c'est le moyen le plus sur que sont appli ne soit pas portable.

SI la portabilité fait partie de son cahier des charges, c'est un problème; si ce n'est pas le cas, il n'y a absolument pas lieu de s'en préoccuper.
29/01/2008, 11h05
ced600

Citation:

Envoyé par bakonu

oui, si je peux executer du VBS avec C#, je fais mes popup en VBS (mon niveau en VBS est trop faible pour faire la totalité de l'appli en VBS).

Celà me permettrait de mettre mon appli en service système.
Cependant, il resterait le problème de la connexion utilisateurs, j'ai absolument besoin qu'une session soit ouverte pour que le controle ait de la valeur.

Bon 2 ou 3 choses :
1) Le service est le seule type d'application qui peut se lancer au démarrage de windows sans ouverture de session.

2) Avec un script tu peux le placer de telle manière qu'il s'executé à l'ouverture de la session d'un utilisateur, mais pas avant.

3) Une application ne se lancera que juste après l'ouverture d'une session utilisateur si tu place le racourcis dans "Tous les programmes\Démarrage".

Ensuite quand je parle de script en C#, je parle de script en langage C#, si tu ne connais pas assez le VBS.
Mais bon dans le forum VBS il y a plein de sujet qui traite de ceci :

Citation:

Voilà, j'aimerais faire un petit programme sans fenetres (utilisant eventuellement des messages box), qui puisse etre capable de lister la liste des processus windows en execution afin d'y effectuer des contrôles.

Ce n'est pas très compliqué, on s'appuis sur les objets WMI.
29/01/2008, 11h06
Bluedeep

Citation:

Envoyé par bakonu

E
Et le but de cette appli, est de pouvoir empêcher l'utilisateur windows d'utiliser certains programmes (donc terminer le processus s'il est lancé) si certaines conditions dans la base de données ne sont pas remplies.

Il ne serait pas plus simple de bloquer le lancement de ces programmes (via une modification des droits utilisateurs sur les fichiers en question) et de n'établir ces droits que lorsque les conditions sont remplies ?

Es tu sur que tu ne prends pas le problème par le mauvais bout ?
29/01/2008, 11h09
Bluedeep

Citation:

Envoyé par ced600

1) Le service est le seule type d'application qui peut se lancer au démarrage de windows sans ouverture de session.

Je ne suis pas certain à 100% mais il me semble que tu peux mettre des applications en "RunOnce" (ou kekchoz comme ça :D ) lancées à l'initialisation du système. (je n'ai pas accès à me Registry là où je suis, donc je ne peux pas vérifier la clef à utiliser pou cela, mais je suis presque convaincu que cela existe). Déjà les drivers n'initialisent hors session et ne sont pas des services.
29/01/2008, 11h16
ced600

RunOnce dans la BDR ?
Bah c'est exactement pareil que "Tous les programmes\Démarrage".
E fait je me suis planter dans "Tous les programmes\Démarrage", ce n'est pas un raccourci qui est lancé, mais en fait, lorsque tu met ton raccourci dans ce repertoire, une clé dans RunOnce est créée.
Donc au démarrage de la session.

Qaund aux drivers, je n'y pensais pas, mais entre un drivers et une service windows, pour surveiller la liste des processus, je préfère le service windows :aie:
29/01/2008, 11h31
Bluedeep

Citation:

Envoyé par ced600

Qaund aux drivers, je n'y pensais pas, mais entre un drivers et une service windows, pour surveiller la liste des processus, je préfère le service windows :aie:

Sauf que en mode drivers, il doit pouvoir justement interagir sur leur démarrage; mais, encore une fois, je pense qu'il ne prend peut être pas le problème par le bon bout.
Ce n'est d'ailleurs pas inhabituel ici (sur ce forum), quand il y a une demande technique un peu "bizarre", si on creuse, on s'aperçoit qu'en reprenant depuis le début, c'est à dire depuis le besoin, on arrive souvent vers des solutions très éloignées de la demande initiale (et plus propres ...).
29/01/2008, 12h03
ced600

Citation:

Voilà, j'aimerais faire un petit programme sans fenetres (utilisant eventuellement des messages box), qui puisse etre capable de lister la liste des processus windows en execution afin d'y effectuer des contrôles.

C'est pas bizzare cela, mois j'ai fait un programme du même genre que celui-ci :aie:
Mais c'était un service windows.

Un outil de supervision qui détecte la présence d'un processu et de ses composants et les relance si non trouvés et alerte l'équipe de supervision.
29/01/2008, 12h05
Bluedeep

Citation:

Envoyé par ced600

C'est pas bizzare cela, mois j'ai fait un programme du même genre que celui-ci :aie:

Reprend le "pourquoi" de sa demande :

Citation:

En fait, mon appli serait liée à une base de données centrale.

Et le but de cette appli, est de pouvoir empêcher l'utilisateur windows d'utiliser certains programmes (donc terminer le processus s'il est lancé) si certaines conditions dans la base de données ne sont pas remplies.

et tu verras peut être mieux le "pourquoi" de ma remarque.
29/01/2008, 12h11
ced600

Citation:

Envoyé par Bluedeep

Reprend le "pourquoi" de sa demande :

et tu verras peut être mieux le "pourquoi" de ma remarque.

En effet.
29/01/2008, 13h52
bakonu

Bon, déjà, changement de plan de la part de ma hierarchie, on touche plus au processus, lol

Je dois effectuer mes controle sur ma base toujours, mais la solution adoptée sera un simple messagebox d'alerte à afficher toutes les 5 minutes jusqu'à résolution du problème.

Je pense le mettre en service système si je peux afficher une messagebox.

Merci, pour votre investissement dans ce problème.
29/01/2008, 14h06
ced600

Si par "service système" tu parles de service windows, non tu ne peux pas afficher de message box.
En fait il y a un moyen, il faut cocher l'option "autoriser le service à intéragir avec le bureau" mais :
1) Déconseillé par windows car c'est un trou de sécurité.
2) Cela fonctionne sous XP mais pas toujours sous Windows 2003 server. En effet cela dépend de certaines règles de sécurité qui prédomine sur l'option.
29/01/2008, 14h17
Bluedeep

Citation:

Envoyé par ced600

Si par "service système" tu parles de service windows, non tu ne peux pas afficher de message box.

Si, sans problème; il faut juste mettre le flag SERVICE_NOTIFICATION à l'appel de la méthode Show

Citation:

En fait il y a un moyen, il faut cocher l'option "autoriser le service à intéragir avec le bureau" mais :
1) Déconseillé par windows car c'est un trou de sécurité.
2) Cela fonctionne sous XP mais pas toujours sous Windows 2003 server. En effet cela dépend de certaines règles de sécurité qui prédomine sur l'option.

De toute manière ce n'est pas nécessaire pour un MessageBox
29/01/2008, 14h20
ced600

Citation:

Envoyé par Bluedeep

Si, sans problème; il faut juste mettre le flag SERVICE_NOTIFICATION à l'appel de la méthode Show

De toute manière ce n'est pas nécessaire pour un MessageBox

Je ne connaissais pas 8O

Cela ne marche que pour les message box ? pas moyen de lancer une application windows et de voir sa form apparaitre à partir d'un service ?
29/01/2008, 14h24
Bluedeep

Citation:

Envoyé par ced600

Je ne connaissais pas 8O

Cela ne marche que pour les message box ? pas moyen de lancer une application windows et de voir sa form apparaitre à partir d'un service ?

Je n'ai jamais essayé d'afficher une forme autre qu'une MessageBox dans un service; je pense que avec l'option "autoriser le service à interagir avec le bureau" ce doit être parfaitement possible. (peut être même sans, franchement j'en sais rien).
29/01/2008, 14h33
ced600

Citation:

Je n'ai jamais essayé d'afficher une forme autre qu'une MessageBox dans un service; je pense que avec l'option "autoriser le service à interagir avec le bureau" ce doit être parfaitement possible. (peut être même sans, franchement j'en sais rien).

Nan nan ça j'ai essayé, j'ai eu besoin de le faire.
Cela ne marche qu'avec l'option et encore pas tout le temps, comme je l'ai dit certaine règle de sécurité l'empêche. Et en plus cela te le lance sur la console 0. Ce qui n'est pas top, lorsque l'appli est lancé sur un serveur et que les équipes en charge du serveur se connecte dessus avec le bureau à distance.