¿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”].

deb1

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.

deb2 

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:

deb3

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”

deb4

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

deb5

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…)

deb6

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.

deb7

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.

deb8

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.

deb9

¿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:

deb10

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.

deb11

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,


** crossposting desde el blog de Lluís Franco en geeks.ms **

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>