Uso de TracePoint en Visual Studio 2017 a la hora de depurar nuestras aplicaciones
Muchos programadores que trabajan con Visual Studio, no conocen la característica TracePoint.
Es mi intención en esta entrada, el hablar sobre ella para darla a conocer a quienes no sepan de su existencia.
Seguro que cuando leas esto, la usarás más de lo que crees.
Es bastante común, que cuando estamos depurando nuestras aplicaciones en Visual Studio 2017, tengamos la necesidad de conocer una determinada información dentro de una variable o un objeto por ejemplo.
Bastará (normalmente) con poner un punto de interrupción en nuestro código y esperar a que el flujo de ejecución pase por nuestro punto de interrupción para que el proceso se detenga y podamos ver qué está sucediendo allí.
Esta tarea es como digo, bastante habitual, pero no deja de ser por ello y en muchas ocasiones bastante tediosa.
Así que muchas veces lo que hacemos es poner algo como:
Debug.Print(person.Name);
No está mal.
Nos evitamos sin duda tener que detener el flujo de ejecución de nuestra aplicación, y dentro de la ventana Output de Visual Studio, podemos ver realmente lo que querermos ver.
Sin embargo, estamos añadiendo al código de nuestra aplicación, código innecesario.
Aunque es cierto que cuando generemos los ensamblados de nuestra aplicación como Release estas líneas de código desaparecerán, no es menos cierto que en el repositorio de código, sí estaremos subiendo código que no tiene mucho sentido.
Incluso seguramente ocurra, que un programador que vea esto, no lo tocará puesto que pensará que alguien lo necesita.
Y también no es menos cierto, que lo más probable es que el programador que hizo eso, olvide que existe y lo dejará ahí por el resto de los días.
Ahora bien, si queremos hacer algo parecido a lo anterior pero queremos ser más pulcros, podemos utilizas las instrucciones de compilación condicional.
En nuestro caso haríamos algo parecido a:
#if DEBUG
Debug.Print(person.Name);
#endif
Se trataría de algo parecido a lo anterior, pero con una técnica más refinada.
Dicho de otra forma, es el mismo perro con diferente collar.
La pregunta que nos podemos hacer entonces es: ¿hay algo que nos ayude a hacer algo similar sin tener que «ensuciar» nuestro código y subirlo al repositorio?.
La respuesta es sí.
Con TracePoint.
Con TracePoint podemos indicar información de nuestra aplicación que queremos que se muestre en la ventana Output.
Pero la mejor forma de ver esto es con un ejemplo pseudo-práctico.
Imaginemos que tenemos un bucle de código que se ejecuta 10 veces, y que en cada iteración, crea un objeto Person con un nombre (Name) y una edad (Age), y mete el objeto creado en una colección People.
Como vemos, un ejemplo poco sofisticado.
Sin embargo, queremos ver qué ocurre con cada objeto Person que creamos y cuales son los valores de Name y Age en cada uno de ellos.
Ir ejecutando línea a línea con F10 es una excelente alternativa para perder tiempo, pero es a lo que muchas veces estamos acostumbrados.
Poner en marcha alguno de los mecanismos anteriores puede resultarnos bastante útil también, pero ensuciamos nuestro código como decía.
Así que lo primero que vamos a hacer para usar TracePoint aquí es poner un punto de interrupción en la línea de código hasta la que queremos evaluar.
Haremos clic sobre el punto de interrupción con el botón derecho del ratón, y seleccionaremos la opción Actions del menú emergente.
Se abrirá una ventana en la que introduciremos la información que queremos que se muestre en la ventana Output cuando el proceso de ejecución pase por este lugar.
En mi caso:
{nameof(person.Name)} as {person.Name} | {nameof(person.Age)} as {person.Age}
Visualmente, observarás que el punto de interrupción, normalmente un círculo, es ahora un rombo del mismo color. Ese es el identificativo de un TracePoint.
Si ejecutamos nuestra aplicación, veremos que en la ventana Output, tenemos información de acuerdo al proceso de ejecución y el TracePoint que hemos indicado.
Como podemos apreciar, el uso de TracePoint es una manera fácil y sencilla de evitar que escribamos código innecesario en nuestra aplicación, y nos ahorrará el poner código extra que por error u omisión, subamos al repositorio de código.
Espero que te haya resultado útil.
Happy Coding!
2 Responsesso far
Esto no es nada nuevo con el WinDbg se podía hacer esto hace por lo menos 12 años.
Y funciona con todos los lenguajes.
WinDbg no está en la mano de todos los desarrolladores, y no todos los perfiles pueden o están capacitados para hacer cosas con WinDbg.
Sin embargo, los desarrolladores sí utilizamos Visual Studio, y queremos que sea un IDE que tenga todo lo que necesitamos en una única herramienta.
Si WinDbg lo permite, bien está saberlo, pero a mí como desarrollador de Visual Studio, para mi productividad y trabajo, me interesa más tener un todo en uno.