Debug remoto con Visual Studio 2010

Ante todo, valgan las siguientes aclaraciones:

1. Este procedimiento fue probado exitosamente con Windows XP SP3 de 32 bits con los últimos updates en ambas máquinas, y también con una máquina de debug con Windows 7 Professional de 32 bits y una máquina remota con Windows XP SP3 de 32 bits. Otras combinaciones pueden no funcionar.
2. Ambas máquinas estaban dentro de la misma red interna de la organización. Supongo que es posible hacer debug remoto a una máquina en otra red, pero es un escenario más complejo que requerirá, mínimamente, configurar firewalls y establecer alguna especie de VPN o túnel. No consideraremos este escenario.

Para abreviar, se define:

• VS: Máquina donde correremos el Visual Studio.
• RE: Máquina remota, donde se ejecuta el programa a depurar.

Con todo esto en mente, los pasos a realizar son:

1. Ambas máquinas deben tener una cuenta de usuario con el mismo nombre y contraseña. En VS, correremos el Visual Studio bajo esa cuenta, y en RE, bajo una cuenta con igual nombre y contraseña, correremos la aplicación. Ambas cuentas deben ser de Administrador; tal vez pueda hacerse con cuentas limitadas configurando adecuadamente políticas y permisos; se lo dejo a otro.
2. En VS, loguearse a la cuenta en cuestión, abrir el Visual Studio y compilar la aplicación en Debug. Asegurarse antes de que el Visual Studio no esté corriendo en otra cuenta, o al menos que tenga abierta otra solución, ya que puede haber conflictos. Puede que falle la compilación si se usa Strong Naming para las assemblies manejadas, en cuyo caso será necesario ingresar la clave para todas las assemblies.
3. Una vez que la aplicación compila exitosamente, compartir el directorio donde están los binarios de Debug(típicamente, en Proyecto/bin/Debug). Esto se logra haciendo click derecho en dicha carpeta, y yendo a la solapa Sharing de las Properties:
   
   Luego de seleccionar la opción "Share this Folder", clickear el botón "Permissions", y darle permisos totales a la cuenta compartida por las máquinas. Si la cuenta no aparece, clickear "Add" y agregarla primero.
4. Ir a RE y verificar que se pueda acceder a la carpeta compartida.
5. En RE, ir a Panel de Control->Herramientas Administrativas->Directiva de Seguridad Local->Directivas Locales->Opciones de seguridad->Network Access: Sharing and security model for local accounts y seleccionar la opción Classic - local users authenticate as themselves. Esto es para poder loguearse desde VS con la misma cuenta.
6. En RE, abrir un Internet Explorer, ir a Tools->Internet Options->Security->Trusted Sites->Add this website to the zone y agregar la carpeta compartida como sitio seguro:
   
   En el screenshot, desarrollo3 y precision son dos máquina de desarrollo que usamos para hacer debug remoto (serían dos VS distintas).
7. En RE, asegurarse de que el .exe.config asociado al .exe de la aplicación tenga el siguiente tag:
   
   Si no hacemos esto, cuando querramos correr la aplicación en RE nos aparecerá un cartel diciéndonos que activemos ese switch.
8. En RE, ejecutar el .exe que está en la carpeta compartida. Es vital que pueda correr exitosamente solo, o no funcionará el debug remoto. El primer problema que encontraremos, particularmente si usamos C++ nativo en algún proyecto, será que en RE no están instaladas las versiones de debug de las dll del runtime de C++ (sólo están las de release). Podemos usar el dependency walker en RE para ver cuáles son y copiarlas desde VS, pero es más cómodo, en VS, crear un proyecto de tipo instalador que empaquete esas dlls, compilarlo y correrlo en RE. Los detalles de esto, en un próximo post (este ya es bastante largo...)
9. En VS, buscar la carpeta Remote Debugger (en mi caso estaba en C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE) y copiarla a RE, en cualquier lugar. Yo la copié en la carpeta compartida.
10. En RE, ir a la carpeta Remote Debugger copiada/compartida en el paso anterior y ejecutar msvsmon.exe. Ir a Tools->Options y en Server Name poner el nombre de usuario de la cuenta compartida seguido por @ y el nombre de RE. Seleccionar Windows Authentication, clickear Permissions y darle permiso de Debug a la cuenta compartida. Hecho esto, en la ventana de mensajes de msvsmon debería decir algo como "Msvsmon started a new server named blablabla. Waiting for new connections...".
11. En RE, ejecutar el .exe de la carpeta compartida.
12. En VS, en el Visual Studio, ir a Debug->Attach to Process. En este formulario, en Qualifier, escribir el Server name que ingresamos en el msvsmon. Si la conexión es exitosa, en la ventana de abajo aparecerán los procesos que están corriendo en RE. Si no, puede decirnos cosas como que no puede conectarse a msvsmon porque la autenticación falló. En ese caso, agregar una excepción en Panel de Control->Firewall de Windows->Excepciones, tanto para RE como para VS, ambas apuntándole al msvsmon.exe de la carpeta compartida, y con ámbito limitado a la red local. Para que el Visual Studio y el msvsmon tomen estos cambios, puede que sea necesario reiniciarlos. Como último recurso, y bajo propio riesgo, desactivar temporariamente los firewalls.
13. Si el attach es exitoso, ya es posible parar en breakpoints, ver la salida de Output, etc.
14. Desenfundar la espada y comenzar a decapitar bugs. Si el proyecto es un engendro con más de 100 proyectos, manejados y nativos en distintos lenguajes como es nuestro caso, es probable que luego de 5 o 10 pasos de debugging el debugger de VS se cuelgue; tendremos que colocar un solo breakpoint y muy sabiamente para poder resolver el problema rápidamente. ¡Buen provecho!