windows services - programadas - Servicio de Windows vs tarea programada
consumir web service c# (10)
¿Cuáles son los inconvenientes y ventajas de los servicios de Windows frente a las tareas programadas para ejecutar un programa repetidamente (por ejemplo, cada dos minutos)?
- Es más fácil configurar y bloquear los servicios de Windows con los permisos correctos.
- Los servicios son más "visibles", lo que significa que todos (es decir, los técnicos) saben dónde buscar.
¿Cuál es la sobrecarga de comenzar y salir de la aplicación? Cada dos minutos es bastante frecuente. Un servicio probablemente permita que el sistema funcione con mayor facilidad que la ejecución de su aplicación con tanta frecuencia.
Ambas soluciones pueden ejecutar el programa cuando el usuario no está conectado, por lo que no hay diferencia. Sin embargo, escribir un servicio es algo más complicado que una aplicación de escritorio normal: es posible que necesite un cliente GUI separado que se comunique con la aplicación de servicio a través de TCP / IP, tuberías con nombre, etc.
Desde el punto de vista de un usuario, me pregunto cuál es más fácil de controlar. Tanto los servicios como las tareas programadas están fuera del alcance de la mayoría de los usuarios no técnicos, es decir, ni siquiera se darán cuenta de que existen y pueden configurarse / detenerse / reprogramarse, etc.
¿Por qué no proporcionar ambos?
En el pasado, puse los bits ''core'' en una biblioteca y envolví una llamada a Whatever.GoGoGo () tanto en un servicio como en una aplicación de consola.
Con algo que está disparando cada dos minutos, las probabilidades son decentes, no está haciendo mucho (p. Ej., Solo una función tipo "ping"). Los wrappers no deberían contener mucho más que una única llamada a método y algo de logging.
Alguna desinformación aquí. Windows Scheduler es perfectamente capaz de ejecutar tareas en segundo plano sin que aparezcan ventanas y sin necesidad de contraseña. Ejecútelo bajo la cuenta NT AUTHORITY / SYSTEM. Use este interruptor schtasks:
/ ru SISTEMA
Pero sí, para acceder a los recursos de la red, la mejor práctica es una cuenta de servicio con una política de contraseñas sin vencimiento por separado.
EDITAR
Dependiendo de su sistema operativo y los requisitos de la tarea en sí, es posible que pueda usar cuentas menos privilegiadas que Localsystem con la opción /ru .
Del fino manual ,
/RU username
A value that specifies the user context under which the task runs.
For the system account, valid values are "", "NT AUTHORITY/SYSTEM", or "SYSTEM".
For Task Scheduler 2.0 tasks, "NT AUTHORITY/LOCALSERVICE", and
"NT AUTHORITY/NETWORKSERVICE" are also valid values.
Task Scheduler 2.0 está disponible desde Vista y Server 2008.
En XP y Server 2003, el system es la única opción.
En el desarrollo de .NET, normalmente empiezo desarrollando una aplicación de consola, que se ejecutará con todos los resultados de la sesión en la ventana de la consola. Sin embargo, esto es solo una aplicación de consola cuando se ejecuta con el comando argumento /console . Cuando se ejecuta sin este parámetro, actúa como un servicio de Windows, que seguirá funcionando en mi propio temporizador programado codificado personalizado.
Los servicios de Windows, en mi opinión, se utilizan normalmente para gestionar otras aplicaciones, en lugar de ser una aplicación de larga ejecución. O ... están ejecutando continuamente aplicaciones pesadas como SQL Server, BizTalk, RPC Connections, IIS (aunque IIS descarga el trabajo técnicamente a otros procesos).
Personalmente, estoy a favor de tareas programadas sobre servicios de ventana para tareas de mantenimiento repetitivas y aplicaciones como copia / sincronización de archivos, envío masivo de correo electrónico, eliminación o archivo de archivos, corrección de datos (cuando otras soluciones no están disponibles).
Para un proyecto, he estado involucrado en el desarrollo de 8 o 9 servicios de Windows, pero estos permanecen en la memoria, inactivos, consumiendo 20 MB o más de memoria por instancia. Las tareas programadas harán su trabajo y lanzarán la memoria inmediatamente.
Esta es una vieja pregunta, pero me gustaría compartir lo que he enfrentado.
Recientemente me dieron el requerimiento de capturar la captura de pantalla de un radar (de un sitio web Meteorológico) y guardarlo en el servidor cada 10 minutos.
Esto requirió que usara WebBrowser. Normalmente hago servicios de Windows, así que decidí hacer este servicio también, pero seguiría fallando. Esto es lo que vi en la ruta del módulo Faulting del Visor de eventos : C: / Windows / system32 / MSHTML.dll
Como la tarea era urgente y tenía muy poco tiempo para investigar y experimentar, decidí usar una aplicación de consola simple y la activé como una tarea que se ejecutó sin problemas.
Me gustó mucho el artículo de Jon Galloway recomendado en respuesta aceptada por Mark Ransom.
Recientemente se cambiaron las contraseñas en los servidores sin reconocerme y todos los servicios no se pudieron ejecutar porque no podían iniciar sesión. Entonces la persona que afirma en el artículo comenta que esto es un problema. Creo que los servicios de Windows pueden enfrentar el mismo problema (por favor, corríjanme si me equivoco, soy un novato)
También lo mencionado, si se abren las ventanas del programador de tareas o aparece la ventana de la consola. Nunca me he enfrentado a eso. Puede aparecer, pero al menos es muy instantáneo.
La palabra ''serv''ice'' comparte algo en común con ''serv''er''. Se espera que siempre se ejecute, y ''serv''e. Una tarea es una tarea.
Juego de rol. Si soy otro sistema operativo, aplicación o dispositivo y llamo a un servicio, espero que se ejecute y espero una respuesta. Si yo (os, app, dev) solo necesito ejecutar una tarea aislada, entonces ejecutaré una tarea, pero si espero comunicarme, posiblemente de manera bidireccional, quiero un servicio. Esto tiene que ver con la manera más efectiva de comunicar dos cosas, o una sola cosa que quiere ejecutar una sola tarea.
Luego está el aspecto de la programación. Si desea que algo se ejecute a una hora específica, programe. Si no sabe cuándo lo va a necesitar, o si lo necesita "sobre la marcha", servicio.
Mi respuesta es más filosófica por naturaleza porque es muy similar a cómo los humanos interactúan y trabajan con otros. Cuanto más comprendamos el arte de la comunicación, y las "entidades" entiendan su función, más fácil será esta decisión.
Dejando a un lado toda la filosofía, cuando está "creando rápidamente prototipos", como suele hacer mi departamento de TI, hace lo que debe para llegar a fin de mes. Una vez que la creación de prototipos y la prueba de concepto están fuera del camino, generalmente en la planificación y el descubrimiento temprano, debe decidir qué es más confiable para la sostenibilidad a largo plazo.
De acuerdo, en conclusión, depende en gran medida de muchos factores, pero es de esperar que haya proporcionado una visión en lugar de confusión.
Los servicios de Windows quieren más paciencia hasta que esté listo. Tiene un poco de depuración e instalación. No tiene rostro Si necesita una tarea que debe hacerse en cada segundo, minuto u hora, debe elegir el servicio de Windows.
Tarea programada se desarrolla rápidamente y tiene una cara. Si necesita una tarea diaria o semanal, puede usar Tarea programada.
Un servicio de Windows no necesita tener a nadie conectado, y Windows tiene facilidades para detener, iniciar y registrar los resultados del servicio.
Una tarea programada no requiere que aprenda a escribir un servicio de Windows.
Actualizar:
Casi cuatro años después de mi respuesta original y esta respuesta está muy desactualizada. Desde que apareció TopShelf , el desarrollo de Servicios de Windows fue fácil. Ahora solo necesita averiguar cómo admitir la conmutación por error ...
Respuesta Original:
Realmente no soy partidario de Windows Scheduler. La contraseña del usuario se debe proporcionar como @moodforall indica más arriba, lo cual es divertido cuando alguien cambia la contraseña de ese usuario.
La otra gran molestia con el Programador de Windows es que se ejecuta de manera interactiva y no como un proceso en segundo plano. Cuando aparecen 15 ventanas de MS-DOS cada 20 minutos durante una sesión de RDP, se pateará a sí mismo que no las instaló como Servicios de Windows.
Independientemente de lo que elija, ciertamente le recomiendo que separe su código de procesamiento en un componente diferente de la aplicación de la consola o el Servicio de Windows. Luego tiene la opción de llamar al proceso de trabajo desde una aplicación de consola y conectarlo al Programador de Windows, o usar un Servicio de Windows.
Descubrirá que programar un servicio de Windows no es divertido. Un escenario bastante común es que tiene un proceso de larga ejecución que desea ejecutar periódicamente. Pero, si está procesando una cola, realmente no desea que dos instancias del mismo trabajador procesen la misma cola. Por lo tanto, necesita administrar el temporizador, para asegurarse de que si su proceso de ejecución prolongada se ha ejecutado más tiempo que el intervalo de temporizador asignado, no se inicie de nuevo hasta que el proceso existente haya finalizado.
Después de haber escrito todo eso, piensas, ¿por qué no acabo de utilizar Thread.Sleep? Eso me permite dejar que el hilo actual continúe ejecutándose hasta que haya terminado y luego se active el intervalo de pausa, el hilo se queda dormido y se inicia de nuevo después del tiempo requerido. ¡Ordenado!
Luego, lee todos los consejos en Internet con muchos expertos que le dicen que es una mala práctica de programación:
Entonces te rascarás la cabeza y pensarás a ti mismo, WTF, Deshacer pagos pendientes -> Sí, estoy seguro -> Deshacerte de todo el trabajo de hoy ... maldición, maldición, maldición ...
Sin embargo, me gusta este patrón, incluso si todos piensan que es basura:
Método OnStart para el enfoque de un solo hilo.
protected override void OnStart (string args) { // Create worker thread; this will invoke the WorkerFunction // when we start it. // Since we use a separate worker thread, the main service // thread will return quickly, telling Windows that service has started ThreadStart st = new ThreadStart(WorkerFunction); workerThread = new Thread(st); // set flag to indicate worker thread is active serviceStarted = true; // start the thread workerThread.Start(); }El código crea una secuencia separada y le asigna nuestra función de trabajador. A continuación, inicia el subproceso y permite que se complete el evento OnStart, de modo que Windows no cree que el servicio esté bloqueado.
Método de trabajo para el enfoque de un solo hilo.
/// <summary> /// This function will do all the work /// Once it is done with its tasks, it will be suspended for some time; /// it will continue to repeat this until the service is stopped /// </summary> private void WorkerFunction() { // start an endless loop; loop will abort only when "serviceStarted" // flag = false while (serviceStarted) { // do something // exception handling omitted here for simplicity EventLog.WriteEntry("Service working", System.Diagnostics.EventLogEntryType.Information); // yield if (serviceStarted) { Thread.Sleep(new TimeSpan(0, interval, 0)); } } // time to end the thread Thread.CurrentThread.Abort(); }Método OnStop para el enfoque de hilo único.
protected override void OnStop() { // flag to tell the worker process to stop serviceStarted = false; // give it a little time to finish any pending work workerThread.Join(new TimeSpan(0,2,0)); }
Fuente: http://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (Dead Link)
He estado ejecutando muchos servicios de Windows como este durante años y funciona para mí. Todavía no he visto un patrón recomendado en el que las personas estén de acuerdo. Solo haz lo que funcione para ti.