aelena.com

Si quereis depurar un workflow de MOSS que despierta al recibirse un correo en la biblioteca a la que el workflow está asociado, debereis adjuntar el depurador de Visual Studio no contra w3wp.exe sino contra el timer de MOSS, OWSTimer.exe. Y es que aunque MOSS corra sobre la infraestructura de ASP.Net, este proceso es el encargado de enviar notificaciones y realizar tareas programadas para Windows SharePoint Services, y se ve que la gente del equipo de desarrollo de MOSS decidió programar una tarea cuando llega un correo y correr con w3wp.exe cuando se cargan elementos a mano en una biblioteca.

Es decir, según la funcionalidad que queramos probar (1. Un WF que arranca con un correo y 2. un WF que arranca al añadir manualmente un nuevo elemento en una biblioteca), el escenario de depuración será diferente, ya que la forma de ejecutar estas tareas será distinta.

Además esto implica que si queremos leer parámetros de configuracion de un web.config como estamos acostumbrados a hacer desde una webpart o un desarrollo web normal, esta operación fallará cuando el encargado de despertar el WF sea  OWSTimer.exe, ya que este proceso no sabe nada del web.config que tengamos en el directorio de nuestra aplicación web o site. De manera que no queda otra que tener la configuración en un XML aparte, o base de datos, u otra alternativa, como un servicio web quizás, para hacer  nuestro escenario un poquito más SOA y desacoplado.
Eso sí, de vez en cuando el Visual Studio decidirá cerrarse. Supongo que para que esto de desarrollar para MOSS no se convierta en algo demasiado agradable o cómodo. ;P

Es posible además que cuando esto ocurra, luego el proceso no aparezca, y es porque se habrá caído el propio servicio de MOSS. Entonces, abrimos las Herramientas Administrativas, vamos a Servicios, y buscamos Windows SharePoint Services Timer. Lo volvemos a levantar y a depurar de nuevo.
Saludos