Acabo de leer esto: What is the benefit of developing the application as a windows service? pero todavía no estoy seguro de cuándo usar un servicio de Windows.¿Aplicación de consola programada frente a servicio de Windows? Cuando es apropiado usar cada
Tengo un par de tareas que deben ejecutarse a intervalos (es decir, cada 5 minutos). ¿Qué tipo de proyecto debería usar? ¿Hay algún ejemplo de los tipos de aplicaciones que deberían ser servicios de Windows?
Para cualquier tarea programada, yo por lo general recomendar un servicio de Windows, por las siguientes razones:
en cuanto a otros ejemplos de aplicaciones que pueden ser servicios de las ventanas, una gran cantidad de veces son útiles para aplicaciones como la comunicación remota: puede hacer que un servicio ejecute un servidor remoto al que los clientes se conectan. Obviamente muy útil para las tareas de procesamiento de datos que desea ejecutar en segundo plano, o procesos en los que desea enviar un correo electrónico bajo ciertas condiciones, etc.
En general, siempre he encontrado tareas programadas para ser mucho más frágil y poco confiable. Y a menos que los haga iniciar sesión correctamente, a menudo es más difícil de depurar.
En referencia al error con el temporizador: si lee el informe de error en el sitio de MS, puede ver que se produce cuando llama a "Parar" dentro del evento Timer_Elapsed. La respuesta a esto es simple: no llame a stop. En su lugar, envuelva todo en un cheque para un booleano "IsRunning" y solo ejecute si IsRunning es falso. Incluso si no hubo un problema con el temporizador, debe hacer esto de todos modos porque el temporizador podría volver a dispararse durante su ejecución si su ejecución lleva más tiempo que su intervalo de temporizador.
De todos modos, sigo pensando que el uso de las tareas programadas es una solución débil y me da recuerdos de Windows 95.
Una tarea programada no necesita un usuario conectado. Una tarea programada se puede ejecutar como una cuenta integrada. Para estos tipos de tareas de mantenimiento, las acciones de control y falla son prácticamente irrelevantes. Sus ejemplos de programas de servicio son muy buenos. –
No estoy seguro de dónde ha tenido la gente la idea de que el servicio del Programador de tareas es de alguna manera poco confiable, esto tal vez fue cierto en Windows 98, pero ciertamente después de Win2K esto categóricamente no es cierto. –
Corrección agregada: usuario conectado: para tareas de mantenimiento, puede ser útil reiniciar. Por ejemplo, si tiene una herramienta de terceros que está utilizando y debido a cosas que están fuera de su control, a veces se cuelga. Cuando esto sucede, el servicio puede reiniciar el servidor (solo una por ejemplo). –
Ese es un caso típico para el servicio de Windows, IMO.
que preferiría servicio de las ventanas en la mayoría de los casos.
Una cosa buena cuando se utilizan tareas programadas:
Todos los recursos utilizados se liberan cuando la tarea programada ha finalizado.
Cuando se utiliza el servicio de Windows (sin detener el servicio), el proceso nunca muere. Y debe en su programa asegurarse de que se liberen los recursos.
Al detener un servicio de Windows, también se liberan los recursos. – StingyJack
@StringyJack: Sí, estoy de acuerdo. Cuando detiene el servicio Pero si no detiene el servicio de Windows ...;)) –
Oye ... Mi Desarrollador Gut se ofende con la observación "Stringy". =) – StingyJack
Para aplicaciones de un solo o estrecho ejecutar una aplicación de consola a través del Programador de tareas es casi siempre el diseño correcto.
Para carreras de larga o tareas complejas que puede necesitar la interacción tales como arranque manual, detener, hacer una pausa, continua, etc.entonces, en general, un servicio de Windows es la mejor opción.
Las tareas programadas se pueden ejecutar bajo cualquier cuenta y no necesitan un usuario conectado al igual Servicios. Para tareas de un solo propósito, como las que propone, el control externo de la tarea generalmente es irrelevante, por lo que no necesita la capacidad de control de un Servicio.
Un factor importante también es el programador de tareas es un planificador basado en evento muy robusto y flexible. Es extremadamente improbable que pueda escribir un planificador que sea más robusto y que pueda manejar los caprichos del tiempo y la programación basada en disparadores. De hecho, hay una serie de preguntas sobre el uso de temporizadores para programar tareas en los servicios en este sitio y es notable la cantidad de respuestas (incluidas algunas de las respuestas "correctas") que son de mala calidad o totalmente incorrectas.
EDIT: También es interesante notar que la política Microsoft se está desplazando desde el uso de los servicios para las acciones basado en tareas. Si revisa Vista, Win2K8 y Win7, verá una lista creciente de tareas programadas para fines especiales que realizan el mantenimiento del sistema y muchos servicios del sistema.
Tengo una serie de tareas programadas de Windows que se ejecutan cada hora en un servidor web de producción. No son confiables en absoluto. Se ejecutan en Windows 2003 Server en una cuenta de máquina específica. La mayoría de las veces funcionan perfectamente, pero ocasionalmente no se ejecutan y algunas veces terminan antes de que se terminen.
Parte de esto puede deberse al hecho de que son vbscripts y la forma en que están escritos, pero he visto tareas programadas con WS FTP Pro (software FTP comercial) que se comportan de la misma manera.
He convertido a muchos de ellos a los servicios de Windows y nunca he tenido que preocuparse de ellos de nuevo.
Definitivamente me inclino por los servicios de Windows. Al igual que algunos de los otros comentarios, me han quemado las tareas programadas de Windows demasiadas veces. No confío en ellos para soluciones de nivel empresarial.
recomendaría una tarea programada en todos los casos, excepto los programas que necesitan para funcionar en intervalos muy cortos, o que se ejecutan continuamente. Programas que se inician, realizan su función, y el cierre tienen una vida útil de recursos bien definidos, llevan a cabo la preparación y la limpieza adecuada en un número limitado de pasos (y si no, el hecho de que no terminan en el tiempo esperado es indicación de un error), y por lo tanto son más fáciles de razonar. Y no necesita juguetear con temporizadores y cosas por el estilo.
tareas programadas tienen operaciones equivalentes al detener y reiniciar los comandos de los servicios, es decir. deshabilitar tarea, habilitar tarea. Sencillo, y permite a los actuales operaciones en curso completa en lugar de tratar de abortar ellos, que es inherentemente correcta manera de manejar esto. Hacer todos estos estados/tiempos de vida de recursos de gestión de transición manualmente es simplemente propenso a errores en presencia de refactorización.
haber tenido que hacer escribir, depurar, implementar y apoyar las tareas tanto, prefiero programado de lejos. No dudo que haya casos de uso en los que esta sería la elección incorrecta. Pero para cualquier tarea relativamente trivial, una aplicación de consola que se ejecuta como una tarea de programación funciona muy bien.
En mi experiencia, las tareas programadas son extremadamente confiables. No recuerdo un solo fallo y apoyo alrededor de una media docena de diferentes tareas programadas que se ejecutan en cualquier lugar de diaria a cada 15 minutos. (No es que no haya fallado pero todos fueron problemas de código o configuración. Y se registraron y se enviaron notificaciones. El problema NUNCA ha sido con la Infraestructura de programación de tareas.)
Las tareas del Programador de tareas se pueden ejecutar en cualquier contexto de usuario y no necesita que nadie inicie sesión
Mi mayor ventaja está en el despliegue. Para aplicaciones de consola, simplemente publique el EXE en la carpeta de destino correcta. Para los servicios de Windows necesita detener el servicio (usando net.exe), desinstalar el servicio (usando InstallUtil.exe), esperar (tengo la implementación inactiva durante 25 segundos), publicar el EXE y luego hacerlo todo en reversa (instalar , comienzo).
Si tuviera que desarrollar un servicio de Windows de nuevo, sin escribo como una aplicación de consola y luego encontrar una manera de envolverlo en un servicio para hacer la depuración de menos de un dolor de cabeza.
¡Hay una consideración adicional para los desarrolladores que usan Visual Studio Express! – David
Si usted va la ruta de servicio, NO utilizar el temporizador. Se puede bloquear y dejar su servicio en un estado no operativo, pero parece que se está ejecutando. – StingyJack
Ni siquiera sé lo que significa que un temporizador se "cuelgue". Los temporizadores son parte del sistema operativo, y si eso falla su servicio tiene mayores problemas que el temporizador. – MSalters
Los temporizadores no son parte del sistema operativo. Vea esta publicación SO para más información. http://stackoverflow.com/questions/397744/-net-windows-service-with-timer-stops-responding/397757#397757 – StingyJack