Luis Guerrero Hablando de .NET, Silverlight, WPF, Windows Phone 7 y depuración

1Jul/083

Experiencia de uso de .Net Framework 3.5 SP1

Como ya comente en otro post, ya ha salido el .net Framework 3.5 SP1 y el Visual Studio 2008 SP1, pues bien quiero comentar mi experiencia de uso desde que lo instale en mi portátil. Tengo que aclarar que mi portátil es tanto de uso profesional como de uso personal, así que es importante para mí que este service pack no rompa las aplicaciones que estoy desarrollando.

Voy a comentar desde varios punto de vista que características incluye este service pack que no se han comentado en los post oficiales de Microsoft y cosas que yo considero importantes.

Depuración

Dentro de la sección de depuración hay varias cosas interesantes a mencionar pero solo una negativa a comentar.

La única pega que tiene que el SP1 es que al cambiar las versiones de los ensamblados del framework la depuración con el código fuente del framework no está disponible porque no podemos bajarnos los símbolos de depuración con la información del código fuente de Microsoft. Por ejemplo, mscorlib.dll tiene de versión 2.0.50727.3031 (netfxsp.050727-3000).

Por lo demás vamos a comentar cosas positivas en el área de depuración que incluye el SP1 de Visual Studio 2008.

Dentro del menú de herramientas -> Opciones -> Depuración tenemos una opción interesante.

  • Enable .Net Framework source stepping, que nos permite depurar el código fuente del framework simplemente marcando esta opción.

image

Dentro de lo que es la depuración normal de una aplicación nos podemos encontrar con llamadas complejas que a su vez llaman a otras funciones que devuelven parámetros para pasarlo a la función principal, pues bien ahora podemos seleccionar en qué función queremos saltar, por ejemplo tenemos este trozo de código.

   1: Parse(RequestManager.Current.MakeRequestOfertas());

En el que se realizan tres llamadas a funciones, Parse, al singleton de RequestManager y al método MakeRequesOfertas, pues bien imaginemos que queremos depurar pero solo nos interesa la función MakeRequestOfertas, normalmente pulsado F11 y entrado dentro de las funciones pasaríamos por el singleton del RequestManager.Current todas las veces, lo que puede hacerse un poco molesto, pues ahora en el menú contextual podemos especificar a qué función saltar.

image

Siguiendo con esta característica del depurador de Visual Studio, una de las cosas más molestas cuando se depura código es entrar dentro de las propiedades cuando se está depurando código lo que nos hace perder un tiempo en recorrer todas las instrucciones que hay dentro de la propiedad. Dentro del framework hay un atributo que nos permite decirle al depurador que no salte dentro del código de una función para no perder tiempo en depurarla, este atributo System.Diagnostics.DebuggerStepThroughAttribute únicamente se puede usar para clases, estructuras, constructores y métodos. Pues bien ahora con el SP1 del Visual Studio 2008, en el menú contextual en modo depuración tenemos una opción que nos permite que habilitar la característica de saltar sobre las propiedades y sobrecarga de operadores (Step over properties and operators).

Otra característica más del depurador es que ahora podemos hacer depuración remota con Windows Vista, cosa que antes no era posible. Además de esto se han corregido problemas con la depuración de aplicaciones multihilo.

La depuración de consultas LINQ también se ha mejorado, permitiendo ver los resultados de una consulta LINQ directamente con el depurador, pero no se soporta la edición en tiempo de ejecución durante la depuración

image

Como últimas características, se ha mejorado la depuración de aplicaciones de WCF y de scripts, como por ejemplo JavaScript

Runtime WPF

Otra de las características que nos prometían con este service pack es un mejor rendimiento de las aplicaciones de WPF, y lo han conseguido.

Si miramos a la arquitectura actual de WPF, hay un componente no administrador dentro del arquitectura milcore.dll que es la api responsable de convertir las llamadas de dibujado de geometría de WPF a código que llama a DirectX, esto permite que nuestras aplicaciones en WPF estén aceleradas por hardware de una manera transparente, es también esta milcore.dll uno de los principales componentes que utiliza el Desktop Windows Manager para componer la interfaz de usuario de Windows Vista y permitirnos que podamos hacer las pre visualizaciones de las aplicaciones y el Switch3D.

 

image

image

Pues bien ahora en una aplicación WPF del .net Framework 3.5 SP1, milcore.dll ha desaparecido de los módulos cargados y no está en la pila de ejecución de tu proceso actual. ¿Qué es lo que hay ahora?, pues si nos fijamos en los Threads que hay en una aplicación cualquiera de WPF vemos que hay una nueva dll llamada wpfgfx.dll, que es la que se encarga de dibujar los gráficos en WPF. Esto es un cambio de concepto interesante porque ahora el modelo de dibujado de una aplicación WPF es multihilo. Esto que significa, pues que el hilo principal de tu aplicación, cuando solicite el dibujado de un control o una animación enviará un mensaje a este thread que será el responsable de dibujar esa petición, lo que hace que se mejore sensiblemente el tiempo de respuesta de una aplicación WPF y además su rendimiento.

image

Cosas a decir de wpfdfx.dll, pues es una dll no administrada, osea completamente nativa y si nos fijamos en las importaciones que hace esta dll no encontramos ninguna referencia a d3d9.dll (DirectX), pero si encontramos referencias a GDI32.dll, Knerl32.dll, Winmm.dll (Windows Multimedia) y WindowsCodects.dll (Infraestructura de codecs de imagen de WPF). Pero si somos un poco curiosos y desemsamblamos al dll con IDA vemos que no hace referencia directamente al d3d9.dll pero si lo carga con LoadLibrary y después emplaza los métodos con GetProcAddress.

 

Espero que os guste !!

¿Te ha gustado este artículo?

¡Considera subscribirte al RSS para estar al día!

Filed under: .Net, Depuración, Programacion Leave a comment