Version imprimable
salut,
J essaie de creer une application C# qui s execute tout les x temps.
Celle ci est charger tout les x temps de scruter le contenu d un repertoire, pour recuperer les nouveaux fichers.
ou meme est t il possible de creer une application qui scrute en continue.
Merci d avance pour votre aide.
Arioule
As tu déjà entendu parlé des timers ?
C'est ce qu'il te faut.
Je te laisse chercher sur les tutoriaux et sur :google: des exemples et des explications sur leurs utilisations.
Sinon tu peux utiliser les taches planifiées de windows pour exécuter par exemple toutes les heures ton programme de surveillance.
Bonjour,
Tu as plusieurs possibilités :
_ Utiliser un programme qui fait un seul tour (scruter...) et utiliser les tâches planifiées
_ Tu peux utiliser une méthode avec un timer qui la déclenche toutes les 10mins...
_ Ou utiliser une boucle "infinie" avec un thread qui se met en pause 10min à la fin du traitement
Tu as aussi un composant tout prêt pour faire ce que tu veux : le FileSystemWatcher. Il t'informe de ce qui se passe sur un répertoire, création / suppression de fichier etc... Tu peux le configurer (je crois que c'est pas simple à configurer).
L'idéal serait de créer un service qui utilise un FileSystemWatcher ;)
je suis pas sure que FileSystemWatcher fonctionne en mode service.
Il ne faut pas oublié qu'une grande majorité des "composants" qu'ils soient fenetrés ou pas d'ailleurs ne fonctionnent plus dès lors que l'on travail dans un service.
En effet, en mode service, il n'y a pas vraiment de thread principal, il n'est donc pas assigné à pomper la file de message windows, car de toute facon il n'y a pas de file de message pour les services. Or la grande majorité de ces composants est fondé sur l'interception des messages en provenances de windows.
Ainsi System.Windows.Form.Timer utilise un message en provenance de cette file pour savoir qu'il est arrivé à terme et qu'il doit lancer son évenement.
Pour faire simple on peut dire qu'une grande majorité lance une ressources asynchrones dans le systeme d'exploitation et demande à celui-ci d'envoyer un message indiquant la fin de la tache à l'application. Ca marche c'est sure... mais pas en dehors d'une application.
(certes réellement c'est plus complexe que cela, mais ca peut se résumer de la sorte)
Soit il est "joueur" et essaie FileSystemWatcher en mode service... soit il n'est pas "joueur", ou aime pas se prendre pour un apprenti sorcier et fait un thread qui scrute le repertoire toutes les N secondes ou minutes.
Pour les FileSystemWatcher dans un service : y a pas de blème ! Ca fonctionne sans problème.
Pour ce qui est de la configuration et l'utilisation des FileSystemWatcher, c'est vrai que ce n'est pas facile. Le mieux est de créer une appli qui log dans un fichier tous les événements avec les données des paramètres. Ainsi il est plus facile de déterminer de quels événements on a besoin et comment les utiliser. Par exemple, lors de création d'un nouveau fichier il y a plusieurs événements qui se déclenchent (Change, Create, ...). La propriété NotifiFilter doit être aussi correctement définie. Moi je l'ai définie comme ça :
Mais c'est un beau petit job. Bon amusement !!Code:Watcher.NotifyFilter = NotifyFilters.DirectoryName | NotifyFilters.LastWrite | NotifyFilters.FileName;
Intéressant ce que tu dis cinemania :
Serais tu en train de dire que faire du multithreading en tant que service windows ce n'est pas gagné ?
je comptais prochainement lancer plusieurs thread d'une application encapsulé dans un service windows, c'est peut être peine perdu alors ?
Ayant ce genre de problematiques j'utilise le scheduler de windows en mode advanced. Mais vue qu'il ne me suffit pas je développe une sorte de programme pilote qui tourne en permanence et qui lance via des Process mes différentes applications, el tout avec des timers. Cela marche module un prob de sécurité que je suis entrain d'investiguer
ced600 tout dépend comment tu concoit le MultiThreading en mode service.
En réalité le mode service, est surtout fait pour ca, mais le probleme est que dès lors que quelqu'un pense à threading, il pense :
System.Windows.Form.Timer
or comme expliqué un peu auparavant... ca ne marchera pas, car pas de boucle de messages windows (pas de cadre Application)
et oui ce cadre tu ne peux pas le lancer dans le Onstart car ca bloquerais ton Onstart et windows jugerais que ton service a planté et le killerais de force.
et en supposant que tu mette un Application.Run quelque part et qu'il est exécuter, ca bloquerait un thread pour rien, car un service windows ne recoit pas de message windows, par la file des SendMessage/PostMessage de l'API win32.
En revanche des timer existent qui eux fonctionnent... System.Threading.Timer, mais si tu l'utilise tu va au devant de sévères déconvenues si tu tiens absolument à ce que l'interval défini soit respecté, genre si ton évent doit etre exécuté tous les 1 secondes exactement... j'ai déjà expliqué dans un autre post pourquoi ce modele de timer n'était pas précis.
Il existe un troisième modele de Timer vivement conseillé, meme par la msdn car plus précis, permettant un interval inférieur à celui d'un System.Windows.Form.Timer, et qui fonctionne en mode service.
Sinon pour les barbares comme moi, rien ne t'interdit de faire ton propre système de timer "précis" avec des threads.
j'ai un thread d'horloge, des sleeps, des mécanismes pour s'assurer qu'il est toujours synchrone à la milliseconde près, et il balance chaque tache dans des threads de pool ou des threads créés si besoin est, pour ne pas être perturbé (d'autant qu'il se resynchronise avant chaque mise en sommeil)
mais tout le monde n'a pas besoin d'un scheduler ultraprécis et synchrone à la milliseconde près.
C'est à dire ??Citation:
Envoyé par cinemania
tout simplement : System.Timers.TimerCitation:
Envoyé par UNi[FR]
autre namespace, autre mentalité, autre fonctionnement.
de là a dire que c'est le messie ya qu'un pas... enfin je me risquerais pas non plus à crier victoire, car je ne l'ai jamais testé, et ne connais pas le revers de la médaille (yen a toujours un.)
System.Threading.Timer ne marche pas si mal que cela, j'en utilise tout plein dans mes services.
Bo c'est vrais que je ne suis pas à la seconde près, mais je dirais qu'il est précis à 5 seconde près.
Bon c'est super génant dans le cas du multithreading lorsque les threads dépendent les unes des autres.
Cela dépend donc de ce que l'on veut faire.
System.Windows.Form.Timer -> cela marche peut être si tu autorises ton service à interagir avec le bureau, puisqu'alors tu peux avoir l'affichage d'une application lance par le service. Maisc'est déconseillé par MS et des règles de sécurité peuvent supplanter cette option.
oups je ne suis pas encore réveillé, ce n'est pas System.Threading.Timer que j'utilise mais System.Timers.Timer, s'il est si précis que cela, mes fluctuation de 5 secondes ne serais dût alors qu'à l'exécution du code qui est dans ma fonction appelé par le timer. Pas top, j'ai dût dev comme un barbare :mrgreen: .
msdn le conseil, maintenant, d'après eux il est précis, mais comme d'après eux comme pour threading.timer, il utilise les threads comme base, je suis pas convaincu que ton code soit la cause de ces dérives de 5s.
pour moi une dérive de 5s dans un sens ou dans l'autre est inacceptable, car une dérive par ci c'est bien mais donc tes opérations suivantes sont décalée de 5s, puis une seconde derive....
a la fin un truc qu'est cencé s'exécuter à minuit s'exécute à 23h... (plus la durée est longue, plus la dérive constatée peut etre longue, avec System.Threading.Timer, ou un Thread.Sleep())
Maintenant ced600 ce que tu peux faire c'est au lieu de faire l'opération directement dans l'event du Timer tu peux faire que l'event du timer, lance un thread de la pool sur ton opération à exécuter.
Si tu constate encore des variations c'est qu'il n'est certes plus précis que System.Threading.Timer, mais pas plus "fiable".
Note: en réalité, on fait appel a l'ordonnanceur, qui lui ne compte pas en temps mais en quantum. le quantum est une unité pour les durées allouées à chaque thread. le problème c'est que ce n'est pas fiable, car parfois, le quantum temps attribué à un thread est dépassé par celui là... ce thread n'est pas systematiquement interrompu pour autant (pour peu qu'il soit en priorité TimeCritical par exemple) or l'ordonnanceur ne va pas changer l'ordre de réveil de ton thread pour autant. ensuite un quantum temps de Nms peut se finir à N/2ms... pour peu que tu sorte d'une fonction système et que l'ordonnanceur juge qu'il vaut mieux passer à quelqu'un d'autre...
résultat, tu as des fluctuations assez impressionnantes parfois.
Sur un sleep de 1mn j'ai constaté jusque 8s d'écart, et plus souvent négatif que positif (donc le sleep durait plus souvent 0mn52s que 1mn8s)
pour mon systeme qui nécessite d'etre appelé à interval FIXE de 1mn c'est pas jouable, car des trucs qui doivent s'opérer à 10h du mat peuvent se retrouver a 9h12 pour peu que le service ai tourné suffisamment longtemps et du coup plus rien ne fonctionne comme prévu. j'ai constaté sur 24h plus d'une heure complète de dérive du systeme avec les sleep et les Threading.Timer sans mettre au point un thread d'horloge "fiable"
Nop je n'etais pas réveillé ce matin, le timer ne se décale pas.
Toutes les 30 secondes il fait ce que je lui demande et pas une seconde après pas une seconde avant.
Dans certain cas précis j'arrête le timer puis je fait des opérations (2 minutes environs d'opération) et je le relance.