Discussion :

[vincikito]

Bonjour,

Je doit créer un service Windows qui va, à intervalle régulier va scanner un dossier et lire tous les fichiers .csv qu'il contient pour en injecter le contenu dans une base de données. Pour ce faire, j'ai prévu de faire un boucle infinie avec Thread.Sleep en début de boucle.

Grossièrement le code va ressembler à ça :

While(true)
{
ScanDossier();
Thread.Sleep(300000);
}

Mon problème est que la Fonction "ScanDossier" doit aussi pouvoir être lancer à la demande (soit grace à une combinaison de touche, soit par une commande).
Ceci est il envisageable? si oui comment faut il procéder? si non y a-t il une solution de contournement?

Merci de votre attention.

Cordialement,
Vincent.

PS :Je suis conscient que mon intitulé n'est pas très explicite mais je n'ai pas réussi à expliquer mon problème en quelques mots mieux que ça.

[Babyneedle]

Il existe plusieurs façons d'attaquer ce problème.

Tu pourrais par exemple inclure dans ta boucle infinie une requête sur une table de tâches manuelles.

Pour aller chercher un fichier spécifique, il suffirait de faire un insert dans la table.

Tu pourrais utiliser d'autres supports comme un fichier de configuration ou même un scraper sur une page web.

Ce dont tu parles c'est ce qu'on appelle du 'post processing'. Des scénarios plus complexes pourraient aussi inclure le support d'un message queue comme RabbitMQ par exemple.

Tu pourrais aussi ajouter un self-hosted service qui accepte des requêtes HTTP.

Les possibilités sont infinies.

[giova_fr]

J'imagine que ton service doit se lancer au démarrage de la machine non?
si oui il faudra que tu songe à gérer la concurence entre le service et le ou les sessions ouvertes.

En passant je te déconseille de faire un Thread.Sleep avec une valeur importante, car durant tout ce sleep, tu ne pourra pas interragir avec ton thread.

Comme le disait Babyneedle tu peux eventuellement créer un executable qui se contente d'appeller ta methode, puis de placer cet executable dans une tache planifiée.

Autrement il te faudra déployer un host dans ton service (Avec WCF par exemple). ton host servirait à déclencher la methode, depuis un executable ou une requette http, bref tout est possible (je te rassure ca n'est pas tres sorcier, cherche un tuto sur WCF)

[vincikito]

Merci pour vos réponses à tous les deux. Elles sont très complètes et détaillées même si certains mots me sont inconnus, mais quelque recherche sur le net me permettrons surement de mieux comprendre.

Petite précisions toutefois je suis en framework 2.0 alors pour le WCF c'est cuit!

Je pense que je vais prendre la solution de l'executable qui tourne en backend appelé par une tache planifié. C'est une solution que j'avais envisagé, mais je m'était dit qu'un service windows était surement plus adapter pour un robot comme celui que je doit développer. J'en profite pour vous poser la question : Quels sont les avantages / inconvénients d'utiliser un service windows plutot qu'un executable?

Merci.

[giova_fr]

-Le service windows ne dépend pas des sessions windows (si il est executé en tant que Systeme local), mais si tu fais une tache planifiée pour un executable, tu pourra obtenir le meme résultat.

-il permet plus de libertées qu'une tache planifiée

-il n'offre aucun interface utilisateur (console, fenetre windows), à moins de faire aussi une appli cliente qui communiquera avec lui et fera office d'interface utilisateur.

Je suis un peu surpris que tu ne puisse pas utiliser .NET 3.5 car c'est totalement rétro compatible:
NET 3.5 = NET2.0 + les couches WCF et WPF
il existe meme un patch qui permet d'ajouter le WCF à NET2.0, mais bon c'est un peu obsolete comme solution...

[AngeG]

Pourquoi pas un Scheduler lancé par un windows service, c'est simple à mettre en œuvre et configurable à souhait.

[vincikito]

Je suis un peu surpris que tu ne puisse pas utiliser .NET 3.5 car c'est totalement rétro compatible:

Il faudrait effectivement qu'on se pose la question de la migration mais ce module va venir s'inscrire dans le cadre d'un gros projet : le développement d'un ERP en interne et tout changement (même si sur le papier c'est totalement compatible) doit être mûrement réfléchi et je t'avouerais qu'on est un peu charette en ce moment ...

Sinon conernant vos propositions Je suis assez interessé par le principe d'une appli client qui communiquerait avec le service, pourriez vous m'expliquer comment on fait pour faire communiquer les deux?