Une application avec l'icône "barre d'état système" est-elle OK pour un planificateur en cours d'exécution ou devrais-je créer un service Windows?

Question

Condition - J'ai une tâche périodique que je veux exécuter dans un environnement Windows pour mon application. Il aura une interface simple qui permet une configuration de base (par exemple, les URL et la fréquence de son exécution). Je veux qu'il s'exécute toutes les X heures (configurable) quand la machine fonctionne.

Question - Est-ce que je crée simplement une application avec une présence dans la barre d'état système? Ou devrais-je créer un service avec une interface utilisateur distincte qui s'y connecte.

PAR LA VOIE - Je suis un débutant C# développant en utilisant Visual Studio Express, gardez à l'esprit. Aussi, si vous pouviez donner un aperçu rapide de la conception de ce que vous recommandez, ce serait génial pour quelqu'un de nouveau (par exemple, si vous suggérez un service, cela signifie-t-il que vous avez vraiment besoin d'une application pour le service? a une interface qui fait la configuration pour le service?)

Answer 1

J'ai développé une telle application l'année dernière. Une simple application de formulaires Windows qui a juste une icône de plateau.L'utilisateur peut configurer l'application via un menu contextuel (affiché lorsque l'utilisateur clique avec le bouton droit sur l'icône de la barre d'état). J'ai utilisé une minuterie qui déclenche l'événement Elapsed ...

Si cette application sera la seule à effectuer certaines tâches en temps opportun, alors allez-y simplement avec une application Windows Forms avec une icône de plateau. Mais s'il y a plusieurs applications possibles qui peuvent envoyer une entrée et déclencher une activité, vous devriez envisager de déplacer la fonctionnalité commune dans un service Windows. Vous devriez également envisager d'utiliser un service Windows si l'application s'exécute sur une machine avec des services Terminal Server (plusieurs utilisateurs -> plusieurs instances de votre application).

Je n'utiliserais pas de tâche planifiée! Il est moins convivial ...

-Pavel Nikolov

Answer 2

Bâtir un service avec des crochets d'interface utilisateur semble trop compliqué pour ce que vous essayez d'accomplir. Une application de plateau de système semble juste pour cela, j'irais certainement de cette façon.

Answer 3

Cela dépend de la taille de l'application. Si c'est assez petit, laissez-le dans le bac si vous n'avez pas déjà écrit cette solution

Answer 4

Si vous cherchez quelque chose de simple, pensez à utiliser Windows Scheduler pour planifier les travaux, un shim pour exécuter les jobs après le démarrage du planificateur et un utilitaire de configuration qui permet l'installation. Mais je dois vous recommander d'évaluer la flexibilité et la fiabilité des tâches. Si tout se passe bien si les travaux ne sont pas exécutés de manière cohérente, une application utilisateur dans la zone de notification sera suffisante. Mais si le travail est crucial pour une fonction d'entreprise ou une autre opération, j'irais avec scheduler ou le service. Si vous faites un service, vous aurez un utilitaire de configuration et un service qui communiquera par certains moyens. Vous pouvez demander à l'utilitaire de configuration d'écrire dans un fichier (peut-être un fichier de configuration XML) pour mettre à jour la configuration, puis redémarrez le service pour mettre à jour la configuration.

Answer 5

Si vous en avez besoin pour exécuter X heures, la machine est en cours d'exécution, même si personne n'est connecté, alors une tâche planifiée ou un service peut être correct.

Que va faire le service dans le «temps mort» entre les téléchargements? Si la réponse n'est rien, alors la tâche planifiée est presque certainement correcte. Vous souhaitez créer une application de console à exécuter en tant que tâche planifiée.

Il serait utile que nous en sachions davantage sur l'utilisation de l'interface utilisateur, le cas échéant.

Answer 6

S'il doit être exécuté alors qu'aucun utilisateur n'est connecté, vous avez besoin d'un service. S'il s'agit d'une application utilisateur qui n'a pas besoin d'être exécutée lorsque tous les utilisateurs sont déconnectés, une application de la barre d'état système est OK.

Answer 7

Je créerais le traitement principal en tant que service Windows, sinon, si l'ordinateur redémarre et que vous ne vous connectez pas, le processus ne commencera pas à s'installer dans le bac (et donc votre processus ne fonctionnera pas). Alternativement créer une application de console factice ou silar et exécuter cela via le planificateur de fenêtres. Aussi avec un service Windows, s'il plante, vous pouvez le configurer pour redémarrer automatiquement ce que vous ne pouvez pas (facilement) faire avec une application Windows assis dans le bac.

Je disposerais alors d'une deuxième application avec une interface graphique qui écrit la configuration dans un fichier de configuration commun utilisé par les deux applications.