¿Quieres conocer las tripas del MsgBox?

El código del runtime de VB2008 ha sido liberado…

…esta noticia junto a la de la liberación del Framework ha corrido como la pólvora desde hace unos días. Así que los chicos del VBTeam nos han preparado un pequeño artículo para demostrar cómo activar esta depuración, y así poder llegar hasta las tripas de este maldito código generado en el valle de Mordor. Me he tomado la libertad de traducirlo ‘al vuelo’ así que espero que no se hayan ‘colado’ demasiados errores… Vamos a ver algunos ejemplos:

Ejemplo de depuración clásica sin el código del runtime:

Hemos creado una simple aplicación de consola, que realiza una llamada a una función ‘foo’. En esta función hemos activado un punto de interrupción, de modo que al ejecutar nos detendremos y veremos como el editor de VS no muestra detalles de estas llamadas en la pila de llamadas, simplemente lo muestra cómo «[External Code»].

Desactivar «My Just Code»

El siguiente paso consiste en desactivar esta opción en las opciones de depuración, para así poder acceder a los detalles que no forman parte de nuestro código.

Después de desactivar esta opción, observaremos que eran llamadas realizadas antes de alcanzar a la función destino. Como el compilador no conoce en tiempo de compilación que función debe ser llamada, delega la llamada al enlazador del runtime. Lo que observamos en la pila de llamadas en medio del código de nuestras funciones es el código de la librería del runtime de VB, y si intentamos acceder a él haciendo doble click nos mostrará un mensaje diciendo que no existe código disponible para la localización actual:

Configurar la información de origen del código

Ahora, desde que el código de Microsoft.VisualBasic ha sido liberado nosotros podemos decirle a Visual Studio dónde encontrarlo. Para ello, usaremos el soporte de servidor de código en VS (para que esto funcione deberá estar instalado el siguiente hotfix: Visual Studio 2008 QFE, que actualiza el componente del depurador que trae los ficheros de código:

1. En Visual Studio 2008 seleccionar Tools -> Options -> Debugging
2. En la pestaña “General”
             a. Desmarcar “Just My Code”
             b. Marcar “Enable Enable Source Server Support”

En este paso vamos a decirle a VS dónde encontrar los símbolos, así como dónde vamos a guardarlos en local. Este paso es importante porque acceder a los símbolos en una ubicación local es mucho más rápido que acceder desde un servidor remoto.

En la pestaña “Symbols”

a. Hacer click en el icono «nuevo» y agregar la ubicación remota: http://referencesource.microsoft.com/symbols
b. Marcar la casilla “Search the above locations only when symbols are loaded manually”
c. Introducir una ruta de acceso local en el campo de texto. Debe ser una ubicación sobre la cual tengamos permiso de escritura.
d. Pulsar OK

A continuación, haremos clic con el botón derecho sobre el primer marco del runtime y seleccionaremos «LoadSymbols». Esperaremos a que los símbolos se carguen (esto se demorará un momento la primera vez, y nos preguntará si aceptamos el EULA). Una vez cargados los símbolos, podemos hacer doble clic y ¡qué diferencia! ¡Ahora podemos ver el código fuente del runtime! (En un primer momento tal vez se tome demasiado tiempo, pero una vez tenga los símbolos en la caché local no volverá a suceder…)

Estableciendo puntos de interrupción dentro del runtime de VB

Y todavía más. Ahora nosotros podemos navegar con F11 a través del código del runtime e incluso establecer puntos de interrupción. Si eres un poco curioso puedes establecer un punto de interrupción al principio de la llamada y reiniciar el proyecto. Una vez alcances el punto de interrupción podrás navegar con F11 a través del código y ver cómo fue implementado.

Notaremos que hay una advertencia – Es debido que el código del servidor no es «exactamente» el mismo. Existen unas pequeñas diferencias, como los flags de copyright al final, etc. Debido a eso VS se queja de la diferencia del código.

Esto puede solucionarse fácilmente haciendo clic con el botón derecho sobre el punto de ruptura, abriendo el menú «Location» y seleccionando «Allow source file to be different from the original location». Existe un modo de hacerlo de forma global, pero que no recomendamos porque afectaría a todos los proyectos.

También para estar seguros de que los símbolos son cargados antes de que la ejecución alcance al punto de ruptura, necesitamos deshabilitar la opción «manual only» de la carga de los símbolos.

Esto causará que todos los símbolos serán cargados bajo demanda y esto incluye algunas librerías del Framework .NET, con lo que esto puede tomar bastante tiempo cuando lanzamos la sesión de depuración. Una vez los símbolos han sido cargados deberíamos ser capaces de alcanzar este punto de ruptura en el runtime.

¿Que hay dentro del MsgBox?

Otro escenario interesante que debería funcionar ahora es la navegación mediante F11 por el interior de las funciones del runtime de VB. Una de las más usadas por todos parece ser el MsgBox, de modo que vamos a dar una ojeada a su interior. En un nuevo proyecto podemos usar una llamada a MsgBox e insertar un punto de interrupción:

Cuando alcancemos el punto de interrupción, basta con pulsar F11 y Wow!!! Ahora podemos introducirnos dentro del código de la función MsgBox, navegar a través de él y ver como funciona.

Questiones conocidas, FAQ:

1) Acceder a los símbolos de forma remota no es demasiado rápido. Esto causa ciertos retrasos en VS cuando los recursos son accedidos. Incluso con la caché local activada en algunos escenarios VS comprueba cuándo la información es actual. Podemos sortear esto yendo a: Tools -> Options -> Debugging -> Symbols configuration, y desmarcando “Search the above locations when symbols are loaded manually”. Y posteriormente depurar el proyecto. Tardará un tiempo en cargar todos los símbolos (incluidas varias librerías .NET) en la configuración (en algunas ocasiones pueden llegar a cargarse más de 50Mb). Después de que VS termine la carga, volver a Tools -> Options -> Debugging -> Symbols y marcar “Search the above locations…”. Esto hará que el depurador no se conecte al servidor cuando nosotros no queremos.

2) En ocasiones podemos observar que algunas variables o métodos no están disponibles. El motivo es porque estamos usando una versión optimizada. Un resultado de usar versiones optimizadas es que cierta información no está disponible. De modo que tenemos el código pero no somos capaces de acceder a los datos o agregar puntos de ruptura. Por otra parte, todo lo demás debería ser normal.

3) Funcionará con la edición VB Express? No. Esta funcionalidad no está disponible para esta edición ya que no incorpora estos componentes de Visual Studio.

Es posible consultar el artículo original aquí.

Saludos desde Andorra,