Jérôme De Cuyper

Acabo de liberar la versión 1.0.0.0 de DotNetWinService en codeplex. Escogí codeplex porque su navegador de código fuente es bastante práctico y claro para consultar archivos del proyecto:

Navegador de archivos fuentes

DotNetWinService es una mezcla de varias tecnologías entras las cuales se encuentran log4Net, Spring.NET y Quartz.NET. Permite implementar de forma declarativa (con XML) tareas programadas adentro de un servicio Windows. Las tareas se definen adentro del archivo spring-objects.xml:

Archivo spring-objects.xml

Existen, por lo pronto, 4 tipos de tareas disponibles:

TaskURL, para ejecutar una petición HTTP: cuando se trabaja sobre un sitio web en ASP.NET, a veces conviene mejor mantener toda la lógica de negocio adentro de una página que se ejecuta en un intervalo regular. Puede servir para generar un reporte y mandarlo por correo una vez por semana por ejemplo.

TaskEXE, para ejecutar un archivo EXE o BAT: éste procesa se carga solamente si es el único cargado en memoria, no pueden existir varias instancias del mismo proceso corriendo al mismo tiempo. Puede servir para realizar tareas más pesadas como procesar imágenes o generar reportes que ocupen más tiempo de computación.

TaskMethod, para disparar un método adentro de un assembly: solamente se soportan tipos primitivos y cadenas (System.String). En lugar de tener un archivo EXE, se carga el assembly en memoria, y mediante reflexión, se ejecuta un método (estático o de instancia).

TaskMethodInterop, para intercambiar datos entre dos métodos en el mismo assembly o en assemblies diferentes: el valor de retorno del primer método se convierte en el valor de entrada del segundo método. El parámetro es de tipo System.String.

El proyecto está desarrollado con C# y Visual Studio 2008. No duden en comentar o en aportar código.

Recientemente me encargaron una aplicación que leyera varios feeds y los almacenara en una base de datos sin que tuviera que intervenir un usuario. Y se me ocurrió que crear un servicio de windows sería la mejor forma de hacerlo.

Para ponerlo en palabras sencillas, un servicio windows es un ejecutable que -en segundo plano- realiza tareas especificas como monitorear cambios en archivos del sistema o en perifericos (USB, disco duro externo,…), o cualquier cosa que necesitemos hacer automáticamente, por ejemplo recordatorios o enviar correos. Su característica más interesante es que un servicio no requiere intervención de un usuario, funcionan al fondo. Por lo mismo, en la mayoría de los casos no son visibles en el entorno UI del usuario (aunque no es el caso, por ejemplo, de la consola SQL server Service Manager de MS SQL Server). La no-visibilidad y la autonomía de esos procesos, ocasionó, en el mundo UNIX®, su asosiación con la palabra “daemon”. Aunque se parecen, las palabras “daemon” y “demonio” no significan lo mismo. Evi Nemeth, co-autora del libro “UNIX System Administration HandBook“, indica lo siguiente:

Many people equate the word “daemon”‘ with the word “demon”, implying some kind of Satanic connection between UNIX and the underworld. This is an egregious misunderstanding. “Daemon” is actually a much older form of  “demon”; daemons have no particular bias towards good or evil, but rather serve to help define a person’s character or personality. The ancient Greeks’ concept of a “personal daemon” was similar to the modern concept of a “guardian angel” — “eudaemonia” is the state of being helped or protected by a kindly spirit. As a rule, UNIX systems seem to be infested with both daemons and demons.

El servicio que desarrolle se encarga, mediante un uso básico de threads, de hacer peticiones HTTP a una serie de ligas RSS. El resultado de las peticiones se procesan y almacenan en una base de datos. Visual Studio 2005 y 2008 ofrecen todo lo necesario para desarrollar un servicio de tipo “Hello world” en unos instantes. Les aconsejo desarrollar primero una aplicación de consola y luego pasar su código en un servicio para evitar perder tiempo en instalar y desinstalar el servicio durante la fase de debugeo. Cuando tiene listo su ejecutable, nada más le falta instalarlo mediante la herramienta installutil.exe que se encuentra en:

%SystemRoot%\Microsoft.NET\Framework\v2.0.50727

Para installar el servicio:

installutil "C:\serviciosWindows\miAssembly.exe"

Para installar el servicio y cambiar la ruta del log de instalación:

installutil
/LogFile="C:\serviciosWindows\log\instalUtil.installLog"
"C:\serviciosWindows\miAssembly.exe"

Para desinstallar el servicio:

installutil /u "C:\serviciosWindows\miAssembly.exe"

No tuve ningún problema para instalar mi servicio en XP Pro. Sin embargo, cuando lo intente hacer en una máquina Vista me encontre con unos problemas de seguridad. A la hora de arrancar, el servicio lanzaba un error en el CLR Debugger:

No se controló System.Security.SecurityException
Message="No se encontró el origen, pero no se pudo buscar en algunos o
todos los registros de eventos. Registros inaccesibles: Security."
Source="System" StackTrace: en System.Diagnostics.EventLog.FindSourceRegistration(String source,
String machineName, Boolean readOnly) en System.Diagnostics.EventLog.SourceExists(String source, String machineName) en System.Diagnostics.EventLog.SourceExists(String source) en Lab.MiServicio..ctor() en Lab.Program.Main()

Y del lado de la consola de los servicios (services.msc):

Windows no pudo inicar el servicio "" en Equipo local. Error 1053: El servicio no respondió a tiempo a la solicitud de inicio o de control.

Cuando un servicio arranca, intenta registrarse en el visor de eventos. Si no tiene los permisos necesarios, se termina inmediatamente. Para evitar esta restricción, se tiene que abrir el cmd con los derechos de administrador y luego ejecutar el commando de instalación. Además de ser una herramienta muy poderesa, los servicios generalmente obligan el programador a trabajar con threads. Lo cual implica unos dolores de cabeza pero nuevas ideas para solucionar problemas de computación.

Ligas de interés:

http://www.freebsd.org/copyright/daemon.html
http://es.wikipedia.org/wiki/Daemon