C# ClickOnce implementación para servicios de Windows?

Question

¿Cuáles son algunas de las mejores prácticas para poder implementar un servicio de Windows que deberá actualizarse?

Tengo un servicio de Windows que implementaré pero que podría requerir algunas depuraciones y nuevas versiones durante el proceso beta. ¿Cuál es la mejor manera de manejar eso? Idealmente, me gustaría encontrar una solución de implementación estilo ClickOnce para los servicios de Windows, pero mi entendimiento es que esto no existe. ¿Qué es lo más cercano que puedo llegar a ClickOnce para un servicio de Windows?

Answer 1

Una solución simple que utilizo es simplemente detener el servicio y copiar x los archivos de mi carpeta bin a la carpeta de servicio.

Un archivo por lotes para detener el servicio y luego copiar los archivos debe ser fácil de combinar.

Net stop myService 
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre 
net start myService 

Answer 2

Dado que un servicio es de larga duración de todos modos, el uso de la implementación de estilo ClickOnce puede no ser viable, porque ClickOnce solo se actualiza cuando inicia la aplicación. Por lo general, un servicio solo se iniciará cuando la máquina se reinicie.

Si necesita una actualización automática de un servicio, la mejor opción es codificar manualmente algo en el servicio, pero yo preveo problemas con casi cualquier solución: la mayoría de los procesos de instalación requerirán cierto nivel de interacción del usuario (si solo para evitar el UAC), así que no puedo imaginar que esto conduzca a una respuesta que no implique que un usuario haya iniciado sesión en frente de la pantalla en algún momento.

Una idea que podría funcionar es la implementación de un directorio activo (o algún equivalente similar). Si su servicio se implementa mediante un instalador estándar de tipo MSI, AD le permite actualizar la aplicación de forma silenciosa como parte de la política de la computadora. Sospecho que tendrías que obligar al servidor a actualizar la política de AD (reiniciando o utilizando gpupdate desde la consola), pero aparte de eso debería ser una implementación de no intervención.

Answer 3

Sugeriría utilizar el enfoque de "complemento" en esto, es decir, usando el Proxy Design Pattern.

Durante el uso de este patrón, un subproceso independiente puede verificar a través de una carpeta de actualizaciones. Necesitará usar ShadowCopy en la implementación de su ensamblaje. Cuando el hilo de actualización de su servicio encuentre una nueva versión de su servicio, deberá descargar el ensamblaje de producción actual y cargar la nueva versión, sin detener el servicio en sí. ¡Aún más! Su servicio nunca debe notar la diferencia, si no hay un código de falla dentro de su ensamblaje.

Answer 4

Sugeriría crear un proyecto de configuración normal y agregar el resultado del proyecto de servicio de Windows en ese proyecto de instalación.

Para obtener más información, consulte http://support.microsoft.com/kb/816169.

Answer 5

Tengo un sistema que utilizamos aquí que parece funcionar bastante bien con los servicios. Nuestro sistema implementado tiene alrededor de 20-30 servicios en un momento dado. En el trabajo utilizamos un producto llamado TopShelf lo puede encontrar aquí http://topshelf-project.com/

Básicamente TopShelf se encarga de muchas de las cosas relacionadas con el servicio. Instalación, desinstalación, etc. todo desde la línea de cmd del servicio. Una de las características más útiles es la capacidad de ejecutar como consola para la depuración. Crea un servicio y con un inicio de línea de cmd diferente puede ejecutarlo como una consola para ver el resultado del servicio. Agregamos una característica personalizada a este software que nos permite configurar los perfiles por adelantado. Básicamente, nuestros perfiles configuran algunas cosas como el registro, ubicaciones de recursos, etc. para que podamos controlar todo eso sin tener que republicar ningún código. Todo lo que hacemos es ejecutar una orden como

D: \ Services \ ServiceName.exe Core.Profiles.Debug o
D: \ Services \ ServiceName.exe Core.Profiles.Producción

para obtener diferentes configuraciones de registro.

Nuestro script de compilación crea las secuencias de comandos install.cmd y uninstall.cmd para cada uno de nuestros servicios. Todo lo que hacemos es copiar los archivos en el servidor y ejecutar la secuencia de comandos. Si queremos ver resultados de depuración, detenemos el servicio y hacemos doble clic en el exe y obtenemos una consola para leer todo el resultado.

Una cosa más que el topshelf tiene que no usamos porque no es necesario es el concepto de estantería (hay documentación en este sitio web para esto). Esto le permite actualizar el servicio sin tener que "reiniciar", pero aún necesita copiar los archivos manualmente a menos que cree un sistema automatizado para eso.

Sin embargo, mi sugerencia si necesita una disponibilidad del 100% del servicio es tener un sistema redundante. No importa cómo configure su servicio para las actualizaciones, no puede evitar fallas de hardware que causen tiempo de inactividad sin un sistema de failover automático. Si dicho sistema estuviera en su lugar, mi estrategia de actualización recomendada sería apagar 1 nodo, actualizar, probar, encender apagar el otro nodo, actualizar, probar y volver a encender el 2do nodo. Puedes hacer esto por supuesto con un simple script. Este puede ser un sistema más complicado de lo que necesita, pero si no puede desconectar un servicio para un simple reinicio que demora 5 segundos, entonces realmente necesita algún sistema para lidiar con los problemas de hardware porque puedo garantizar que eventualmente sucederá.