SharePoint 2007 & Visual Studio 2008 Remote Debugger

¿Como depurar un WebPart, Feature u otro componente hospedado en un servidor SharePoint de forma remota desde una estación de trabajo utilizando Visual Studio 2008? Esta pregunta se la he hecho a algunos expertos en el tema y generalmente la respuesta que he obtenido resulta ser “Es complicado”. Sin embargo,  no es tan complicado como parece una vez que configuras el servidor y te acostumbras a trabajar de forma remota (quizás lo complicado sea la configuración inicial necesaria).

Antes de empezar, quiero realizar algunas consideraciones importantes:

• Microsoft no soporta este tipo de escenario. Lo recomendado es que cada desarrollador tenga una Máquina Virtual con los siguientes productos instalados: Windows Server, Visual Studio, SQL Server y Windows SharePoint Services 3.0. Así entonces el desarrollo y la depuración se realizaría localmente en la Máquina Virtual y no se interactuaría con la máquina física. De hecho, el componente Microsoft Visual Studio Extension for Windows SharePoint Services, no puede instalarse si no existe una instalación de Windows SharePoint Services 3.0 desplegada, lo que nos conduce a tener obligatoriamente como sistema operativo Windows Server (2003 como mínimo) instalado, por lo que si queremos mantener en nuestra PC Windows XP o Windows Vista intacto hay que utilizar una Máquina Virtual (Microsoft Virtual PC, VMWare, VirtualBox u otro compatible).
• Visual Studio 2010 y SharePoint 2010 probablemente nos entreguen un nuevo modelo de desarrollo en donde se pueda tener una separación entre Cliente (PC Desarrollador) y Servidor (SharePoint), pero hasta la fecha en Internet solo hay especulaciones al respecto.  De todas formas, este post es válido tanto para Visual Studio 2008 como para Visual Studio 2010 Beta.
• Para efectuar una depuración remota necesitamos como mínimo la edición Profesional del Visual Studio.

Una buena pregunta sería, ¿Por qué necesito dividir “Servidor” y “Cliente” y meterme en este rollo de la depuración remota? Bueno, si tenemos una PC con bajos recursos (1GB de memoria RAM y poco disco duro) o un Laptop multipropósito, puede que tener Windows Server 2003 como Sistema Operativo base no sea conveniente y tener una máquina virtual con Windows Server+SQL+SharePoint+Visual Studio+MSDN sería problemático ya que necesitaríamos los mismos recursos de la PC real en la máquina virtual. Además, quizás contemos con alguna PC vieja que tenga 512MB Ram y 10GB HDD por ejemplo y la podríamos destinar a hospedar el Servidor de WSS 3.0. Entonces todo el proceso de desarrollo y compilación lo realizaríamos en nuestra estación de trabajo que probablemente tenga muchos más recursos y todo lo referente a pruebas pues en el “cerdito” (PC vieja). También podemos crear un “cerdito” virtual con 320MB de RAM y 10GB de HDD y trabajar en el Host con Visual Studio (Por supuesto, el rendimiento dependerá de la cantidad de recursos con que se cuente por lo que no podemos esperar hacer mucho muy rápido con 320MB RAM). De cualquier forma (Virtual o Real), el escenario que veremos consiste en un servidor y una estación de trabajo donde estas no están asociadas a ningún Controlador de Dominios de Windows.

1 – Instalar los componentes necesarios para la depuración remota en el Servidor SharePoint

Instalar en el Servidor SharePoint, el Microsoft Visual Studio Remote Debugger que se puede encontrar en el DVD de instalación de Visual Studio.

CDROM:\Remote Debugger\x86\rdbgsetup.exe

CDROM:\Remote Debugger\x64\rdbgsetup.exe

Note que no es necesaria la instalación completa de Visual Studio en el Servidor que tiene  Windows SharePoint Services 3.0 o Microsoft Office SharePoint Server 2007 (MOSS 2007) instalado; basta con instalar el rdbgsetup.exe (10MB).

2 – Controlar la Seguridad

Crear en el Servidor SharePoint una cuenta local de Windows, con el mismo nombre y contraseña de la cuenta que utilizamos para validarnos en nuestra PC y la agregamos al grupo de Administradores.

Como el “Servidor SharePoint” será una máquina (virtual) dedicada (probablemente hospedada en la misma PC de desarrollo), podemos darnos ciertas libertades y agregar dicho usuario como administrador. De lo contrario habría que configurar el Remote Debugger de forma granular para permitir que un usuario no administrador pueda depurar aplicaciones y esto puede “complicar” la configuración y el proceso de depuración en general.

3 – Configurando la Red

Vamos a asumir que el Servidor y la Estación de Trabajo tienen ya configurados un IP (por ejemplo 192.168.29.128 y 192.168.29.130 respectivamente) y se comunican entre sí (para probar dicha comunicación utilizar el comando PING). Esta configuración dependerá del sistema de virtualización que se esté utilizando (VMWare o Virtual PC) o la estructura física de la red utilizada.

El aspecto clave sería cómo asociar el IP del Servidor SharePoint mediante un nombre (por ejemplo http://sharepoint). Tenga en cuenta que no tenemos DNS, Active Directory o cualquier otro servicio de infraestructura; solo contamos con una estación de trabajo y un servidor con Windows 2003 minimal (Solamente con SharePoint y SQL).

C:\Windows\System32\drivers\etc\hosts

192.168.29.128         sharepoint.tempuri.org
192.168.29.128         sharepoint
192.168.29.130         developer.tempuri.org
192.168.29.130         developer

El fichero HOSTS permite la asociación de un nombre a un IP. Gracias a este fichero, podemos simular llamados en nuestro navegador web al estilo http://sharepoint.tempuri.org que serían redirigidos a nuestro servidor SharePoint. Note que el fichero HOSTS hay que modificarlo tanto en el cliente como en el servidor. En Windows 2008 o Vista (UAC activo) si vamos a editar este fichero con Notepad, debemos primero elevar los privilegios (Botón derecho –> Ejecutar como Administrador) sino no vamos a poder guardar las modificaciones aunque seamos administradores.

Otro detalle sería verificar la configuración del Cortafuegos. Podemos configurar ambas máquinas para que confíen entre ellas y no tener que estar permitiendo la comunicación puerto a puerto.

4 – Modificando el web.config

Por cada aplicación web que configuramos en WSS 3.0, existe una carpeta física que utiliza el IIS (Internet Information Server) para almacenar la configuración de dicha aplicación ASP.NET(web.config). La carpeta del sitio predeterminado en una instalación predeterminada de WSS 3.0 es la siguiente:

C:\Inetpub\wwwroot\wss\VirtualDirectories\80

Para habilitar la depuración de la aplicación, hay que abrir el fichero web.config, y buscar el nodo “compilation” y cambiarlo de la siguiente forma:

<compilation batch="true" debug="true">

En una instalación predeterminada de WSS 3.0, el nivel de confianza (code access security – CAS) de .NET para la ejecución de código binario viene en el mínimo (WSS_Minimal). Esto es recomendable dejarlo así en un entorno productivo, pero en nuestro servidor de desarrollo quizás nos convenga ponerlo en Full como se muestra a continuación.

<trust level="Full" originUrl="" />

5 – Configurando el Entorno de Visual Studio

Supongamos que hemos creado un WebPart para SharePoint en Visual Studio sin utilizar las Extensiones de Visual Studio para SharePoint (Ver referencia Walkthrough: Creating a Basic Web Part). Básicamente lo que tenemos es un Proyecto Biblioteca de Clases (Class Library Project) en donde nuestro WebPart es una clase que hereda de Microsoft.SharePoint.WebPartPages.WebPart.

Supongamos también que realizamos todos los pasos del Walkthrough y tenemos desplegado ya el WebPart en una página de nuestro servidor SharePoint. ¿Cómo actualizamos a la nueva versión de nuestro WebPart en el Servidor tras una compilación exitosa?

En vez de guardar el ensamblado en el GAC (Global Assembly Cache), almacenarlo directamente en la carpeta BIN del Directorio Virtual (IIS) en el Sitio donde está hospedado el WebPart (Quitar todas las versiones de nuestro ensamblado que tengamos en el GAC). Por ejemplo:

C:\Inetpub\wwwroot\wss\VirtualDirectories\80\bin

Esto es necesario, para que cada vez que compilemos una nueva versión de nuestro WebPart y la copiemos para el BIN, el servidor automáticamente cargue y ejecute dicha versión y no la anterior. Por supuesto, una vez terminado el WebPart sería recomendable enviarlo al GAC en el servidor de Producción.

¿Cómo automatizar la copia de las DLL de nuestro WebPart hacia la carpeta BIN en el servidor cada vez que presionemos “Compilar” en el Visual Studio?

En las Propiedades de nuestro Proyecto (Botón derecho sobre el proyecto –> Propiedades) existe una sección llamada Build Events en donde podemos especificar qué queremos hacer antes o después de que se realice una compilación. En nuestro caso agregaremos la siguiente línea en Post-Build Events:

copy /Y “$(TargetDir)\*”�
\\sharepoint\c$\inetpub\wwwroot\wss\VirtualDirectories\80\bin

Esta línea de comandos copia la salida (DLL y PDB) para la carpeta BIN en el Servidor. Note que como estamos trabajando con el mismo “usuario” podemos acceder como administrador a C: en el Servidor mediante \\sharepoint\c$ sin especificar ninguna credencial.

6 – Depuración Remota

Para iniciar el proceso de depuración, primero debemos verificar que el Remote Debugger que instalamos en el paso 1 esté ejecutando en el servidor SharePoint.

Luego, en la estación de trabajo abrimos el Visual Studio, cargamos nuestro proyecto “Mi Primer WebPart” y nos dirigimos hacia Debug –> Attach to Process.

En el diálogo “Attach to Process” hay que especificar correctamente el Qualifier que tiene un formato usuario@servidor. El usuario sería aquel que especificamos en el paso 2 y el nombre del servidor el que especificamos en el paso 3. Luego presionamos “Refresh” y aparecerán todos los procesos del servidor remoto.

Para depurar nuestro WebPart debemos seleccionar todos los procesos w3wp.exe (pueden aparecer más de uno) y presionar “Attach”.

Luego abrimos un Navegador Web y accedemos a la URL de la página en donde se encuentra el WebPart (http://sharepoint). Automáticamente Visual Studio se encargará de interceptar el pedido y si existe algún Breakpoint pues el Remote Debugger congelará necesariamente el proceso que se está depurando (w3wp.exe). Note que en ese momento todos los pedidos HTTP al servidor también se congelarán hasta que el desarrollador decida continuar la ejecución del proceso.

Una vez que hayamos terminado, seleccionamos Debug –> Detach All para desconectarnos y finalizar la depuración. Si queremos terminar el proceso remoto seleccionamos Debug –> Stop Debugging. Si terminamos el proceso remoto, perderemos los valores de sesión y aplicación en memoria, aunque automáticamente el IIS nos levantará otro proceso w3wp.exe cuando se vuelva efectuar otro pedido HTTP.

Conclusiones

Los pasos del 1 al 5 se realizan una sola vez. El Paso 6 es el que debemos realizar cada vez que deseemos realizar una depuración remota. ¿Es tedioso dar tantos Clicks? Siempre queda la posibilidad de grabar una Macro en Visual Studio que automatice los Clicks

Referencias

How to: Debug SharePoint Applications

http://msdn.microsoft.com/en-us/library/dd206929.aspx

How to: Set Up Remote Debugging

http://msdn.microsoft.com/en-us/library/bt727f1t.aspx

Walkthrough: Creating a Basic Web Part

http://msdn.microsoft.com/en-us/library/ms415817.aspx

http://msdn.microsoft.com/en-us/library/ms452873.aspx

Tags: Debug, Remote Debugger, SharePoint, Visual Studio, WSS