Pregunta

Tengo varias aplicaciones diferentes de c # worker que ejecutan varias tareas continuas: enviar correos electrónicos desde la cola, importar nuevos pedidos desde la base de datos del sitio web a la base de datos de pedidos, realizar copias de seguridad y restauraciones de la base de datos, ejecutar el procesamiento de datos para OLTP - > OLAP, y otras tareas relacionadas. Antes, los publiqué como servicios de Windows, pero actualmente los libero como aplicaciones de consola normales. Todos se basan en un marco de tareas comunes que creé, y estoy contento con eso, pero no estoy seguro de cuál es la mejor manera de implementar este tipo de aplicaciones. Me gusta la versión de la consola porque es rápida y fácil, y es posible ver rápidamente la actividad y el resultado del programa. El inconveniente es que la computadora del trabajador tiene varias pantallas de consola en ejecución y se ensucia. Por otro lado, el método de servicio parece tardar mucho en implementarse y tengo que revisar los registros de eventos para ver los mensajes. ¿Cuáles son algunas experiencias / comentarios sobre esto?

¿Fue útil?

Solución

Me gusta el enfoque de la aplicación de consola. Normalmente tengo las cosas configuradas para poder pasar un interruptor como -atattended que suprime la pantalla de la consola.

Otros consejos

El Servicio de Windows sería una buena opción, se ejecuta en segundo plano, no importa si cierra la sesión actual, también puede configurarlo para que se inicie automáticamente después de reiniciar Windows al realizar una actualización de parches en el servidor. Puede registrar mensajes importantes en el visor de eventos o en la tabla de base de datos.

Para algo como esto, la forma estándar de hacerlo es con los servicios de Windows. Desea que el servicio se ejecute en la cuenta de la red para que no requiera un usuario registrado.

Hace algunos años trabajé en algo que tenía problemas similares. Lógicamente necesitaba un servicio, pero a veces necesitaba ver qué estaba pasando y, en general, quería una historia. Así que desarrollé un servicio que hizo el trabajo, cada vez que quería iniciar sesión, llamaba a sus suscriptores (implementado como un patrón de observador).

El servicio registró su propio registrador de datos (escritura en una base de datos) y, en el tiempo de ejecución, el usuario podría ejecutar una GUI que se conectó al servicio utilizando la comunicación remota para convertirse en un oyente en vivo.

Voy a votar por los servicios de Windows. Va a ser un verdadero problema administrar esas aplicaciones de consola.

La implementación del Servicio de Windows es fácil: después de la instalación inicial, simplemente apágalos y haz una XCOPY. No hay necesidad de ejecutar ningún instalador complicado. Es solo semi-complicado la primera vez, e incluso entonces es solo

installutil MyApp.exe

Configura los servicios que se ejecutarán bajo una cuenta de dominio para la mejor seguridad y la interoperabilidad más fácil con otras máquinas.

Utilice una combinación de registros de eventos (con error, advertencia e información) para las notificaciones importantes, y simplemente descargue el registro detallado en un archivo de texto.

¿Por qué no obtener lo mejor de todos los mundos y usar algo como:
http://topshelf-project.com/

Le permitirá ejecutar su programa como línea de comandos o servicio de Windows.

No estoy seguro de si esto se aplica a sus aplicaciones o no, pero cuando tengo algunas aplicaciones de consola que no dependen de los comentarios del usuario o son el tipo de aplicaciones que solo hacen su trabajo y se cierran, ejecuto dichos programas. en un servidor virtual, de esta manera no veo que aparezca una pantalla cuando estoy trabajando, y los servidores virtuales son fáciles de crear y reiniciar.

Usamos regularmente los servicios de Windows como procesos de fondo. No me gustan las aplicaciones de línea de comandos, ya que necesita iniciar sesión en el servidor para que se ejecuten. Los servicios se ejecutan en segundo plano todo el tiempo (suponiendo que se inicien automáticamente). También son triviales para instalar con la herramienta de línea de comandos sc.exe que está en Windows. Me gusta más que el bloat-ware que es installutil.exe. Por supuesto, installutil hace más, pero no necesito lo que hace. Solo quiero registrar mi servicio.

También hemos creado una infraestructura donde tenemos un servicio genérico .exe que carga .DLL según una definición de interfaz, por lo que agregamos un nuevo servicio " " es tan simple como colocar una nueva DLL y reiniciar el servidor de servicio.

Sin embargo, comenzamos a alejarnos de los servicios. El problema que tenemos con ellos es que bloquean los archivos DLL (por razones obvias), por lo que es una molestia actualizarlos. Necesitamos parar, actualizar y luego reiniciar. No es difícil, pero pasos adicionales. En su lugar, nos estamos moviendo a las páginas especiales de " " " en nuestras aplicaciones asp.net que ejecutan los trabajos de fondo reales que necesitamos realizar. Todavía hay un servicio, pero todo lo que hace es invocar las páginas asp.net para que no bloquee ninguna de nuestras DLL. Luego podemos reemplazar las DLL en el directorio bin de asp.net y las reglas normales de asp.net para el reinicio de la aplicación del dominio.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top