Hand on labs de Visual Studio Team System 2008

Comentaba El Bruno que se han liberado unas nuevas máquinas virtuales de Visual Studio Team System. Estás máquinas virtuales tienen una ventaja clara, su fecha de caducidad se ha extendido lo bastante como para que nos permitan probar a fondo Team System y Team Foundation Sever.

Pero lo anterior no es la única ventaja. Además junto con las imagenes para Virtual PC se ha incluido en la descarga un msi que contiene un buen puñado (casi cuarenta) de HOLs sobre Visual Studio Team System. Además este paquete de HOLs es descargable por separado y son apenas unos 26 Mb.

clip_image002

Decir que los HOLs estan basados en las máquinas virtuales comentadas por Bruno y accesibles desde el mismo sitio de descarga, pero también se pueden utilizar sin tener las máquinas virtuales si es que ya tenemos un TFS y /o un Visual Studio Team System a nuestra disposición.

Estuve en el primer aniversario de Baleares on Net

Baleares On Net

Ese viernes tuve el placer de participar en el evento del primer anivesario y Community Launch en ese grupo de Baleares on Net. Desde aquí agradecer a Jose Fco. Bonnin la oportunidad de participar en este evento y compartir un rato genial con el resto de ponentes. Siempre es un placer ver y charlar con Eladio Rincón (gracias por tu paciencia con mis preguntas), Miguel Jimenez (otra vez me perdí tu sesión), David Salgado (mejor deja los malabares) y demás fauna de la comunidad.

Hice la misma ponencia que en los Tech Days, sobre Scrum y Team System y la verdad, aunque anduve justo de tiempo, creo que fué fructifera. Sobre el resto de las sesiones, las que vi me gustarón muchísimo. Eso sí, la verdad es que me perdí algunas que tenían muy buena pinta por tener que salir temprano al aeropuerto…

Espero volver por Palma de Mallorca y al grupo con más tiempo.

Soporte para Microsoft JavaScript Library en Aptana Studio

Leo, via el blog de Brad Abrams que ya podemos usar Microsoft JavaScript Library en Aptana Studio:

Aptana_MS_Ajax

Aptana Studio es entorno open source para el desarrollo con JavaScript realmente potente y que soporta los frameworks Ajax/JavaScript más populares. Muchos lo hemos usado para editar y depurar nuestro JavaScript antes de que VS2008 nos proporcionase la herramientas necesarias para hacerlo desde Visual Studio. Pues bien, me entero de que ahora soporta tambien la Microsoft JavaScript Library. Parece que Microsoft se acerca al software libre y el software libre se acerca a Microsoft. En cualquier caso parece que desde el software libre se reconoce la inegable calidad técnica de la librería de JavaScript de Microsoft.

Usando Aptana junto con la libreria JavaScript de Microsoft obtendremos intellisense y la documentación integrada en la herramienta de desarrollo. Sin duda una excelente opción para desarrollar en PHP usando la librería de lado cliente que Microsoft proporciona.

Mis respuestas sobre Scrum (III)

En anteriores ocasiones (I y II) he dado en este blog respuesta a cuestiones que se me han planteado sobre Scrum. En los comentarios de uno de estos post anteriores un lector me ha dejado una serie de cuestiones que me parece interesante contestar en este post. Las cuestiones del lector aparecen en cursiva y mis respuestas a continuación. Espero que os resulten de interés y que mis repuesta habran la puerta a nuevas preguntas. También me gustaría que todo aquel que quiera aportar algo lo haga.

¿Se pueden realizar paralelamente multiples SCRUMs para multiples proyectos de desarrollo distintos?

Por supuesto. La situación ideal es un Scrum Master, un Producto Owner y un Equipo por proyecto. Esto no siempre es posible, sobre todo cuando un mismo equipo debe atender a varios proyectos. La táctica más empleada en este caso es acortar los sprints (a 10 días habiles habitualmente en lugar de los 20 días habiles comunmente empleados) y que el Scrum Master y el Producto Owner lo sean para todos los proyectos que el equipo aborda. Es importante recordar que durante un Sprint un equipo no debe encargarse más que de un proyecto, entendiendose como proyecto el conjunto de requisitos que forman parte de un mismo Producto Backlog.

¿Pueden ser los actores de un SCRUM parte de otros SCRUMs que se estén realizando al mismo tiempo?. ¿Que actores pueden ser parte de múltiples SCRUMs y que actores no?

La respuesta directa es NO. Pero como siempre no hay blancos y negros en esto. Igual que decía antes la relación correcta es un Product Owner, un Scrum Master, un Producto Backlog. A veces los proyectos no tienen entidad suficiente por si mismos y es necesario que el equipo trabaje en más de un proyecto. Esto se debe evitar en la medida de lo posible ya que cada vez que cualquier de los actores cambia del contexto de un proyecto a otro se produce inevitablemente una perdida de tiempo. Por esto mismo, para evitar perdidas de tiempo en cambios de contexto es importante que durante un Sprint el equipo este centrado solo en un proyecto, a lo sumo en dos.

Es viable en mi opinión, que el Product Owner y el Scrum Master alimenten y den servicio a más de un proyecto si los proyectos son de pequeña envergadura. Eso si lo que me parece dificilmente viable es que un equipo este trabajando en más de dos proyectos a la vez. La táctica ideal es establecer la duración del Sprint de manera que sea posible mantener al equipo centrado en un solo proyecto durante la duración del Sprint.

¿Hay un número minimo posible de personas para un SCRUM? sé que lo recomendable es 8 personas, pero ¿hay un minimo?, por ejemplo en un pequeño proyecto de desarrollo ¿podría haber una persona por cada rol?

Ocho personas es el número máximo, no el recomendable. Un rol clave en Scrum, es el Equipo. ¿Puede haber un equipo de menos de dos personas? Por definición no. Pero tampoco en esto sería yo estricto. Es posible tener un equipo de una sola persona si el proyecto es pequeño.

¿En el mismo caso de antes puede una persona cumplir mas de un rol en el SCRUM?

Si efectivamente, aunque no sea lo ideal, es posible que una persona cubra dos roles. La única incompatibilidad clara es que nunca el Product Owner sea parte del Equipo. El Product Owner debe ser el representante de los intereses del cliente en el proyecto. Los desarrolladores a menudo olvidamos en parte los intereses del cliente y perseguimos nuestros propios intereses: aprender tal o cual tecnologia, implementar tal o cual patrón, utlizar tal o cual herramienta de desarrollo… si bien los intereses de los desarrolladores son legitimos deben quedar siempre supeditados a los intereses del cliente y a lograr el mayor retorno de la inversión en el proyecto. También es cierto que, si un desarrollador tiene que priorizar que caractarísticas implementar, es posible que priorize las más interesantes de desarrollar, las más divertidas, en lugar de las que más valor aporten al cliente. Esto hace evidente que no es buena idea que quien guie el desarrollo desde el punto de vista de seleccionar y priorizar las características a implementar sea parte del equipo de desarrollo.

Lo comentado nos deja en la situación de que el rol ‘comodín’ en Scrum es el Scrum Master, que aunque repito no sea lo ideal, puede actuar como Product Owner o como miembro del equipo de desarrollo.

¿Debería el Product Owner ser de nivel jerárquico superior a los miembros del equipo? ¿Algun nivel recomendable?

Las jerarquias existen en la empresa, no hay duda, pero no son relevantes para Scrum. En Scrum todos los participantes son iguales en lo que al proyecto se refiere. Tienen diferentes responsabilidades si, pero todos juegan un papel de igual importancia. Dicho esto es cierto que contar con un Scrum Master que tenga peso dentro de la empresa puede ayudar a que sea más efectivo en su labor de eliminar impedimentos.

¿Debería ser el Product Owner o el Scrum Master del área informática (informático) necesariamente?

No. A la hora de elegir al Producto Owner lo más importante es que sea capaz de representar los intereses del cliente, que conozca el producto que se quiere construir y las prioridades del cliente. Es importante que sepa determinar, expresar y priorizar los requisitos.

El Scrum Master debe ser un buen jefe de producto y sobre todo debe conocer Scrum a fondo. La principal carácteristica que debe presentar es la capacidad de formar y guiar equipos, debe ser un excelente mediador y un gran facilitador.

¿Debería ser el Product Owner del área usuaria?

Es lo ideal. El Product Owner debe ser la voz del cliente en el proyecto y debe ser capaz de conciliar los intereses de todos los stakeholders del proyecto. Se hace evidente que un Product Owner que pertenezca área usuaria, entendida como la parte de la empresa que usará el software desarrollado es una excelente oportunidad.

¿En la empresa donde yo trabajo se desarrollan o corrigen partes o modulos del sistema que utiliza la compañía, estos nacen de un requerimiento del área usuaria, pasan por el área de desarrollo de la Compañía quien evalua el requerimiento y encarga la programación a una empresa de outsourcing. ¿Estoy frente a los posibles actores de un SCRUM?

Sin duda, cada vez más empresas utilizan Scrum en la gestión de proyectos para los que externalizan el desarrollo. En mi opinión tener el equipo de desarrollo fuera de tu empresa siempre es un riesgo importante para el proyecto, pero sin duda es posible usar Scrum en esta situación.

¿Dónde queda la etapa de certificación de un SCRUM? ¿Esta es iterativa como todo lo demás? ¿O solo se certifica al final? ¿En el caso de la certificación los actores cambian? ¿Por ejemplo el área usuaria pasa a formar parte del team?

Efectivamente la aproximación es iterativa. Al final de cada Sprint debemos tener ‘un incremento de funcionalidad potencialmente entregable’. Si para poder entregar nuestro software tenemos que certificarlo (entiendo que pasandolo por un departamente de calidad) este proceso se debe hacer antes de poder considerar un Product Backlog Item (un  requisito) como completado, por lo tanto la certificación es algo que debe hacerse como parte del Sprint.

Es cierto que en ocasiones, cuando se usan entidades certificadores externas o departamentos de calidad externos al equipo de desarrollo a veces se certifican release en lugar de lo entragado en cada Sprint. Es decir se pasa a certificación o verificación en producto de varios Sprints y el proceso se realiza de manera paralela al desarrollo de nueva funcionalidad.

Tambien ocurre que a menudo se utilizan las dos aproximaciones de manera combinada. Un tester o varios forman parte del equipo Scrum y verifican lo implementado en cada Sprint de manera paralela al desarrollo y luego una entidad o equipo de calidad externo verifica releases (lo desarrollado como resultado de varios sprints) en especial equellas que se van a pasar a producción o entregar al cliente.

¿Qué pasa con las reuniones y organización de éstas en periodos donde la gente sale de vacaciones y no puede estar en toda la secuencia? Se debe detener el proyecto?

Generalmente, no hay problema para conciliar las vacaciones con el desarrollo. Si todo el equipo de desarrollo va a estar de vacaciones durante un periodo largo (tipo vacaciones de verano) , simplemente no habrá Sprint en ese perido. Si lo que ocurre es que algunos de los miembros de equipo no va a estar algunos días no hay problema, al calcular la capacidad del equipo para el Sprint se tendrán en cuenta estas ausencias. Si quien falta es el Producto Owner, será el Scrum Master quien ocupe su puesto. Si es el Scrum Master quien falta, será, típicamente algún miembro del equipo de desarrollo quien ocupe su lugar.

Scrum nunca se detiene porque falte alguno de los implicados en el proyecto.

Típicos tópicos erroneos sobre estimación ágil

open your eyesHace algunos días que al hilo de algunos post que hemos publicado sobre  estimación Lucas Ontivero y yo venimos manteniendo un debate interesante sobre técnicas de estimación. La estimación es un tema que he tratado de manera habitual en este blog. El defiende un enfoque más tradicional e ‘ingenieril’ y yo lo que creo que es un enfoque más ágil, posibilista y realista.

En mi último post sobre Planning Poker, una técnica que usan para estimar la dimensión de los proyectos una parte importante de los equipos que usan metodologías ágiles, Lucas Ontivero publica un comentario con ciertas críticas a esta técnica (que podrían ser extensivas a la estimación ágil en general) y que translucen, desde mi punto de vista bastante desconocimiento de porque funcionan las técnicas de estimación ágil. Este desconocimiento es generalizado y fruto de años de frustado enfoque ‘ingenieril’ y tradicional a la gestión de proyectos. Comentaré aquí porque esas críticas son infundadas y porque la estimación ágil funciona. Esto empezó siendo un comentario, pero creció hasta convertirse en un post. Pongo las críticas de Lucas, que son las de muchos otros, todo hay que decirlo, en cursiva y mi respuesta debajo.

“El Planning Poker es solo una única técnica de estimación y deberíamos usar varias. Usar Planning Poker con Wideband Delphi es comer pan con pan.”

Planning Poker y Wideband Delphi casi siempre van de la mano. En el caso del Planning Poker, la clave es que al usar las cartas todas las estimaciones se desvelan de manera simultanea lo que evita que unas estimaciones sesguen otras. Además las cartas siguen una serie inspirada en la serie de Fibonnacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, la idea es que es posible diferencia un requisito de 1 de una de 2 pero difícilmente cuando estimamos un requisito en 13 lo podemos distinguir de uno de 14 debido a las incertidumbres inherentes a toda estimación. La incertidumbre de la estimación crece de manera no lineal con el tamaño del requisito a estimar. Usar valores no continuos, sino los valores discretos de la serie planteada, se ha demostrado como una manera efectiva de considerar la incertidumbres que supone estimar requisitos de magnitud creciente.

En lo que se refiere a Wideband Delphi simplemente es un proceso orientado a construir consenso entorno a la estimación a base de compartir información y detectar dispersión en las estimaciones. Sin duda se tratan de dos técnicas complementarias y diferentes. Planning Poker y Wideband Delphi no asumen nada sobre como cada uno llega a su estimación: uno lo hará por descomposición, otro por comparación, otro usando datos históricos, otro simplemente basándose en su intuición… cualquier técnica que permita obtener un resultado rápidamente sirve.

“Las técnicas de estimación ágil necesitan la participación de todos y esto no siempre es posible. Si somos 21, como en mi proyecto, se complica un poco. Aunque sigue siendo factible.”

Esto no es cierto. Sobre todo cuando se trata de estimar requisitos que es cuando precisamente se usa Planning Poker. Sin duda es recomendable, pero no imprescindible, que todo el equipo participe en el proceso de estimación a nivel de requisitos, si que es imprescindible cuando estimamos tareas de desarrollo, pero no es este el nivel de granularidad que hoy me ocupa. En cualquier caso si seguimos una metodología ágil, nunca tendremos un equipo de 21 miembros, sino varios equipos con un menor número de miembros. Lógicamente en un proyecto de esta envergadura los requisitos se particionarán de alguna manera y cada equipo atacará un conjunto de requisitos. Se hace evidente que cada equipo podrá estimar el conjunto de requisitos que va a atacar. No hay nada que impida que todos participen.

“Se tiende a eliminar las opiniones extremas y la gente se cansa por lo que empieza una convergencia forzada hacia un valor que no siempre es compartido (en un proyecto de training perdimos 2 días discutiendo hasta que cuando nos cansamos convergimos mágicamente!)”

No se trata de ‘llevarse al gato al agua’. En un equipo ágil nadie va a defender sus estimaciones durante dos días. Simplemente es una cuestión de ego y el ego tiene poca cabida en los equipos ágiles. El objetivo es lograr una estimación compartida, consensuada y razonada, nunca tratar de imponer tu estimación sobre la de los demás. Todos asumimos que nuestra estimación puede ser errónea y que solo compartiendo y desvelando información la estimación mejorará. No hay margen para discutir dos días porque todos en un equipo ágil deben conocer que a partir de cierto punto dedicar más tiempo a realizar la estimación solo la mejora marginalmente. Hay una asíntota clara. A partir de cierto punto por más tiempo que pases estimando tu estimación solo será mínimamente más acertada, el esfuerzo no merece la pena.

“Consume más tiempo que los métodos paramétricos, que los que usan analogía y que los “ingenieriles””

No comparto está afirmación. Múltiples estudios (me remito a la bibliografía de Steve McConnell) cita que uno de los motivos porque los métodos tradicionales de estimación no se llevan a cabo es porque se percibe que consumen demasiado tiempo. Las sesiones de estimación ágiles siempre están limitadas en el tiempo, no hay margen para la divagación. Es una práctica habitual en las metodologías ágiles establecer límites temporales claros e inviolables a toda reunión o proceso.

“Hace falta un buen moderador para llegar a buen puerto.”

No se suele necesitar un moderador. En equipos que tienden a divagar o a dispersarse, generalmente por no estar entrenados en la estimación, un simple reloj de arena es suficiente. Una vez consumido el tiempo se estima si o si. Insisto, no por más comentar un requisito o discutir una estimación vamos a obtener una mejor estimación. Si hay dispersión, se produce otra ronda. No he vivido nunca más de tres rondas de estimación y ayudo a estimar a muchos equipos a lo largo del año. En cualquier caso, creo que ser un buen moderador es una característica que todo gestor de proyectos eficiente debe poseer y un buen gestor de proyectos es algo que todo proyecto necesita, luego la estimación ágil, aunque la proposición que abre esta sección fuese cierta, no introduce ninguna exigencia nueva en nuestros proyecto: siempre necesitamos un buen moderador, a ser posible varios.

“Arroja mejores resultados mientras más expertos “verdaderos” sean sus participantes. Si no son expertos…”

No es cierto que la estimación de solo expertos sea mejor. Esto sería cierto si los expertos fuesen quienes realizasen luego la implementación . Es evidente que quien va a implementar una requisito es quien debe estimarlo. Esto es una máxima en estimación. La motivación es evidente, solo quien va a realizar algo puede estimarlo. Seguro que Miguel Induráin estimaría, como ciclista experto que es, que puede subir el Tourmalet en un determinado tiempo y seguro obtendría una buena estimación. Pero si él estima y soy yo quien sube sin duda se va a equivocar, por experto que sea.

En los proyectos de software, rara vez se conoce con certeza quien finalmente implementará un requisito, por eso tenemos que tender a dar voz a cuantos más implicados mejor, idealmente a todo el equipo. A menudo la gente más inexperta vislumbra incertidumbres o dificultades que los expertos tendemos a olvidar. Introducir gente menos experta en el proceso de estimación es una manera de asegurarte de que las estimaciones son validas en un espectro más amplio de situaciones no solo cuando contamos con desarrolladores expertos.

En cualquier caso, es necesario que todos los desarrolladores, expertos o no, puedan asumir las estimaciones como suyas. Es una cuestión de motivación. Si un desarrollador no asume una estimación como realista no trata de cumplirla. Steve McConnell habla de las estimaciones percibidas como no realistas como uno de los principales factores que dañan la motivación. La manera de asegurarte que las estimaciones se perciben como realista es basarlas en el consenso y construir las estimaciones con la participación de todos los implicados. Mi motivación para cumplir una estimación que yo acepte, en la que participe y a la que me comprometí es alta, mi motivación para cumplir una estimación que mi jefe acepto, en la que yo no participé y para la que él se comprometió seguro no va a ser tanta. En Peopleware, biblia de la gestión de proyectos con más de 25 años, se describe como la motivación es el principal factor impulsor de los proyectos de software.

En cualquier caso, desde un punto de vista de gestión de equipos de trabajo, es sano que todo el mundo tenga voz en algo tan importante como la estimación.

Planning Poker distribuido

Planning Poker El Planing Poker es una técnica  usada en estimación en conjunción con wideband delphi, para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil.


El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo. Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación. Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.


De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.


Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente. Para estos casos, he conocido gracias a un cliente una herramienta gratuita que es sumamente útil a la hora de hacer Planning Poker cuando el equipo está distribuido. Se trata de una sencilla web que permite realizar el proceso de Planning Poker de manera colaborativa y distribuida.



Además en esta página podemos encontrar mucha información sobre Planning Poker. La página ha sido creada por la empresa de Mike Conh, autor de excelentes libros sobre gestión ágil de proyectos, como por ejemplo Agile Estimating and Planning. Espero que esta curiosa web sea de vuestro interés.

Depurar servicios con ayuda de PowerShell

Hablaba hace unos días de algunos trucos para depurar servicios: Depurando servicios de Windows más facilmente. Los trucos comentados en mi anterior post, aun siendo útililes, tienen un problema. De una u otra manera alteran el servicio que queremeos depurar. El código que realmente se ejecuta no es exactamente el código que ejcutará nuestro servicio en su versión release.


Windows cuenta con un mecanismo que nos permite establecer un depurador para que se ejecute cuando se arranca un determinado ejecutable. El proceso, que es bastante tedioso, está sobradamente descrito en estos dos artículos: Debugging startup code of services and com servers y How to debug Windows services. He hecho un script de PowerShell que automatiza el proceso.


Os dejo el código de PowerShell, que además es un buen ejemplo sobre como trabajar con el registro y sobre como parsear parámetros de línea de comandos con PowerShell.






  1. #Script que automatiza el establecimiento de un depurador para que se inicie al inicia un servicio  
  2. #El procedimiento está descrito en http://support.microsoft.com/kb/824344  
  3.  
  4. #Asegurarnos de que todas las variables son previamente declaradas  
  5.  
  6. param ( [switch] $Prepare,  
  7.         [switch] $Clean,  
  8.         [string] $ServiceName,  
  9.         [string] $ServiceExecutable )  
  10.           
  11. Set-PSDebug -Strict  
  12.  
  13. #Path al depurador que deseamos usar  
  14. #Yo uso el depurado de VS pero podríamos usar windbg si el servicio fuese nativo y no .net  
  15. $debuggerPath = “vsjitdebugger.exe” 
  16. $imageFileExecutionOptionsPath = “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options” + $ServiceExecutable
  17. $serviceRegistryPath = “HKLM:SYSTEMCurrentControlSetServices” + $ServiceName 
  18. $servicesControlRegitryPath = “HKLM:SYSTEMCurrentControlSetControl” 
  19.  
  20. function Usage()  
  21. {  
  22.     “Establece las claves del registro necesarias para que el depurador se adjunte automáticamente al proceso de un servicio cuando este se ejecuta.” 
  23.     “Puede ser necesario reiniciar la máquina para que este script tenga efecto.” 
  24.     “Basicamente este script automatiza el proceso descrito en http://support.microsoft.com/kb/824344.” 
  25.     “” 
  26.     “Usage: Debug-Service -Prepare | -Clear -ServiceName <string> -ServiceExecutable <string>” 
  27.     “” 
  28.     “Parameters:” 
  29.     “-Prepare: Prepara el servicio especificado para su depuración.” 
  30.     “-Clear: Vuelve el servicio a su estado normal.” 
  31.      
  32.     exit  
  33. }  
  34.  
  35. function Prepare()  
  36. {  
  37.     #Configuramos en el registro el depurador a iniciar cuando se arranque el servicio  
  38.     if ( !(Test-Path $imageFileExecutionOptionsPath))  
  39.     {  
  40.         New-Item -path $imageFileExecutionOptionsPath | out-null  
  41.     }  
  42.       
  43.     Set-ItemProperty -path $imageFileExecutionOptionsPath -name “debugger” -value $debuggerPath 
  44.  
  45.     #Configuramos el servicio como interactivo para que se pueda mostrar la ventana del depurador  
  46.     $serviceTypeValue = (Get-ItemProperty -path $serviceRegistryPath).Type  
  47.     $serviceTypeValue = $serviceTypeValue -bor 0x00000100  
  48.     Set-ItemProperty -path $serviceRegistryPath -name “Type” -value $serviceTypeValue 
  49.     #Establecemos el arranque del servicio a manual  
  50.     Set-ItemProperty -path $serviceRegistryPath -name “Start” -value 3  
  51.       
  52.     #Configuramos el tiempo de timeout para el arranque de los servicios en 24 horas para tener margen para depurar  
  53.     Set-ItemProperty -path $servicesControlRegitryPath -name “ServicesPipeTimeout” -value 86400000  
  54. }  
  55.  
  56. function Clean()  
  57. {  
  58.     if ( (Test-Path $imageFileExecutionOptionsPath))  
  59.     {  
  60.         Remove-Item -path $imageFileExecutionOptionsPath 
  61.     }  
  62.       
  63.     Remove-ItemProperty -path $servicesControlRegitryPath -name “ServicesPipeTimeout” 
  64. }  
  65.  
  66. if (!($Prepare -or $Clean) -or !($ServiceName -and $ServiceExecutable))  
  67. {  
  68.     Usage  
  69. }  
  70.  
  71. if ($Prepare -and $Clean)  
  72. {  
  73.     Write-Warning “No se puede usar Prepare y Clean a la vez” 
  74.     exit  
  75. }  
  76.  
  77. if ($Prepare)  
  78. {  
  79.     Prepare  
  80. }  
  81.  
  82. if ($Clean)  
  83. {  
  84.     Clean  

Depurando servicios de Windows más facilmente

Depurar servicios es una tarea complicada. Esta complejidad tiene su origen en dos aspectos, uno, que es el SCM quien inicia un servicio y por tanto no podemos iniciar los servicios con el depurador adjuntado al proceso (al menos no facilmente) y dos para cuando tenemos oportunidad de adjuntar el depurador, el código de inicio del servicio ya ha ejecutado.

Os voy a contar un par de trucos que uso a la hora de depurarlos.

El primero es bien simple, se trata de usar la siguiente instrucción:

System.Diagnostics.Debugger.Launch();

Esta instrucción hará que salte el típico cuadro de diálogo que nos permite seleccionar el depurador que queremos adjunta a nuestro servicio. Evidentemente la podemos usar en aplicaciones que no sean servicios para tener la oportunidad de ajuntar un depurador cuando se ejecute determinado código.

image

Esta línea puesta como primera línea del método Main de nuestro servicio nos permitirá contar con el depurador adjuntado desde el primer momento y depurar así el inicio del servicio. Es importante poner está línea entre compilación condicional para evitar que se nos cuele la instrucción que activa el depurador en una construcción de ‘release’…

    static void Main()

    {

      #if DEBUG_SERVICE_START

         System.Diagnostics.Debugger.Launch();

      #endif

      …

    }

El segundo truquito es hacer que nuestro servicio se comporte como una aplicación de consola en unas ocasiones y como un servicio en otras.

    static void Main()

    {

      #if DEBUG

        Service1 svc = new Service1();

        svc.OnStart(null);

        //Es necesario domir este hilo para que la aplicación

        //no termine y nos permita depurar

        System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);

      #else

        ServiceBase[] ServicesToRun;

        ServicesToRun = new ServiceBase[] { new Service1() };

        ServiceBase.Run(ServicesToRun);

      #endif

    }

Espero que estos dos truquitos os faciliten la vida a la hora de depurar vuestros servicios…