Servicio de Windows o Programador de tareas para tareas de mantenimiento?

Question

Tengo una aplicación C# que realiza algunas tareas de mantenimiento. Tiene que funcionar aproximadamente cada hora, aunque no es muy importante si está un poco apagado. Y tiene que ejecutarse en un Servidor Win2003 sin que nadie haya iniciado sesión.

Básicamente me pregunto si debería escribir un Servicio de Windows, y si es así, si Thread.Sleep() es una forma adecuada de pausar el Thread para un hora, o si hay mejores formas de asegurarse de que el hilo permanece inactivo y no carga ningún servidor? (alias, lo que es más opuesto a un Spinlock)

La alternativa es el Programador de tareas de Windows, pero no estoy seguro si eso es bueno para el uso del servidor ya que a) tendría que almacenar el calendario en él que en mi app.config, b) No puedo controlar el servicio fácilmente a través de iniciar/detener/reiniciar y c) No sé si las credenciales del usuario de Windows son tan seguras como cuando las ingresé en el servicio MMC Snapin.

¿Cuáles son sus opiniones? ¿Es posible y bueno tener un Servicio inactivo o recomendaría el programador de tareas en su lugar?

Answer 1

Puede encontrar este video interesante. Buena entrevista con el ingeniero responsable de los servicios de Windows y también cuando elegir el servicio o la tarea. En pocas palabras, si su función entra en la categoría de mantenimiento periódico, vaya con una tarea.

Answer 2

El servicio de Windows es más seguro: nadie puede dejarlo y funciona. He encontrado muchos problemas con las tareas de Windows (no se ejecutan, ...).

Windows Task Scheduler es para tareas de usuario final, no para tareas de aplicación. De todos modos, Windows Backup lo usa ;-)

Answer 3

Yo prefiero el Programador de tareas, ya que es más fácil de mantener y hacer cambios en el programa si es necesario.

Además, las utilidades que se ejecutan continuamente y "duermen" corren el riesgo de causar problemas si el desarrollador "olvida" hacer cosas como conexiones cercanas, archivos, etc. que pueden acumularse con el tiempo. Tener el programa "correr y salir" es una manta de seguridad adicional. :-)

Answer 4

Si va por la ruta de los servicios, le recomiendo usar System.Threading.Timer. Con eso puedes configurarlo para disparar un evento una vez por hora. Puedes poner el intervalo en app.config si crees que alguna vez necesitarás cambiarlo.

Los servicios también se ejecutan bajo la cuenta del sistema local (de forma predeterminada), mientras que debe proporcionar un nombre de usuario/contraseña cuando se utilizan tareas programadas. Si usa su nombre de usuario, se convierte en un problema de mantenimiento si alguna vez cambia su contraseña y olvida actualizar la tarea.

Tengo una situación donde utilizo una combinación de ambos en realidad. El servicio funciona constantemente durante el día, pero realizan mantenimiento de red y de base de datos todas las noches. Entonces, uso dos tareas programadas. Uno para cerrar el servicio a la medianoche y otro para volver a encenderlo a las 4 a. M. Esto se hace llamando a los archivos .BAT con los comandos NET STOP/NET START.

Answer 5

Creo que un servicio de Windows es probablemente más confiable y fácil de monitorear, pero no ofrecerá la misma flexibilidad de programación que una tarea programada lista para usar. Probablemente iría con el servicio de todos modos, ya que la mayoría de las aplicaciones empresariales tienden a ejecutarse como servicios, no como tareas programadas.

Para proyectos recientes, he usado Quartz.NET para configurar el procesamiento programado en servicios de Windows. En realidad, no es demasiado difícil de configurar (buen tutorial), y el CronTrigger le dará mucha flexibilidad con solo un poco de configuración. Me gusta más que un Temporizador de .NET sin formato.

Answer 6

Supongo que arrojaré mi valor de 5 centavos, con el programador de tareas se ahorrará algo de memoria cuando la tarea no se esté ejecutando.