Instalar Windows 7 en Windows Virtual PC

Después de buscar un rato en Google Bing, no he visto ningún post sobre cómo instalar Windows 7 en una máquina con Windows Virtual PC. Puede resultar contradictorio puesto que Windows Virtual PC sólo funciona en Windows 7, pero ¿a quién no le ha hecho falta una máquina virtual con la que trastear? Prácticamente para eso se crearon las máquinas virtuales, ¿no? 😉

Pues bien, yo necesito una máquina con Windows 7 para instalar sobre ella Visual Studio 2010. Esto es lo que he hecho para tenerla.

Descarga e instalación

La descarga la he hecho de esta dirección: http://www.microsoft.com/windows/virtual-pc/. De los dos ficheros que indicaba que era necesario descargar, sólo lo he hecho con “Windows Virtual PC”, puesto que no me iba a hacer falta el “Windows XP Mode”.

Una vez bajado, la instalación es un simple doble click –> next –> next. Eso sí, es necesario reiniciar y tanto al apagarse como al volverse a arrancar, está un tiempo configurando esta nueva instalación.

Al volver a arrancar, podremos ver en el menú de inicio un nuevo enlace de nombre “Windows Virtual PC”. Pulsarlo nos llevará una ventana como la que aparece en la siguiente imagen.

VirtualMachinesWindow

Nueva máquina virtual

Ya tenemos la aplicación instalada, es momento de crear la primera máquina virtual. El proceso no puede ser más sencillo. Lo primero es pulsar el botón “Create Virtual Machine”, que aparece en la ventana anterior. Esto nos lanzará un cuadro de diálogo para crear una nueva máquina virtual, que comienza con darnos la opción de definir el nombre de esta nueva máquina, como se muestra en la siguiente imagen.

VirtualMachineName

El siguiente paso es indicar la cantidad de memoria RAM que queremos que tenga disponible la máquina virtual. Mucho ojo con esto porque, en el momento de lanzar la máquina virtual, tendrá que estar libre dicha cantidad de memoria RAM, pues de lo contrario no arrancará la máquina. La siguiente imagen muestra este paso en el cuadro de diálogo.

VirtualMachineMemory

Por último, debemos indicar qué clase de disco duro vamos a manejar. Las opciones principales son crear uno nuevo o elegir uno ya existente, en caso de que, por ejemplo, estuviéramos creando esta máquina virtual a partir de una ya existente. Elegimos la primera opción como se muestra en la siguiente figura.

VirtualMachineHardDisk

Con esto ya tendríamos terminada nueva máquina virtual. Para empezar con la instalación de Windows 7, bastaría con introducir en el DVD de instalación, volver a la ventana de Windows Virtual PC, seleccionar la nueva máquina “Windows7” y pulsar el botón “Open”. De este modo la máquina empieza a ejecutarse y, como cualquier máquina, arrancaría con el DVD la instalación. El final del proceso sería la pantalla con la que Windows 7 nos da la bienvenida para empezar la instalación, seleccionando la configuración de idioma como muestra la siguiente imagen.

Windows7InVirtualPC

El resto es next-> next-> next, puesto que para Windows 7 la instalación se está haciendo sobre una máquina real y los pasos a seguir son los mismos.

Para terminar, es muy recomendable instalar los Integration Components. Se puede hacer desde el menú Tools que aparece en la propia ventana de la máquina virtual y nos permitirá, entre otras cosas, tener sonido, acceso a USBs y, lo que me parece más importante, poder sacar el ratón de dentro de la máquina virtual sin tener que recurrir a la combinación ALT+CONTROL+RIGHT, lo que aumenta considerablemente la sensación de integración.

Debugger in Silverlight

Este fin de semana perdí una cantidad considerable de tiempo porque no me funcionaba el debugger en Silverlight. Básicamente, me salían esos simpáticos mensajes que aparece en Visual Studio cuando un breakpoint no se va a ejecutar:

The break point currently will not be hit , no symbols have been loaded to this document

¿Por qué? ¡¿Por qué?! Me preguntaba yo, intentando depurar una aplicación que estaba comportándose de forma incorrecta. Pues bien, la solución es tan sencilla, de esas que por suerte no se olvidan. Basta con activarlo dirigiéndose a las propiedades del proyecto ASP.NET que estará hosteando nuestro control Silverlight.

En las propiedades, bajo la pestaña Web, en la parte inferior de la pantalla se puede ver un menú como el de la siguiente imagen. Basta activar el checkbox correspondiente a Silverlight para que nuestro depurador favorito funcione de nuevo correctamente.

SilverlightDebugger

Espero que esto le sirva a alguien para perder menos tiempo del que perdí yo.

Code Coverage (II): Uso

Una vez que tenemos activado el Code Coverage para un ensamblado y tras lanzar los correspondientes tests, ver los resultados es una mera cuestión de abrir la pestaña de “Code Coverage Results”, que si no es visible se puede activar en el menú “Test – Windows – Code Coverage Results”.

CodeCoverageResults

En la ventana de ejemplo se puede ver cómo los resultados se gestionan, en primer lugar, por ensamblado ; y dentro del ensamblado , cómo se pueden ir expandiendo los diferentes espacios de nombres, clases y, por último, métodos. Sin duda, una gran granularidad que nos permite saber con precisión dónde estamos quedándonos cortos en el testeo.

Pero, si esta ayuda es buena, tener el código coloreado indicando qué partes han sido ejecutadas durante el testeo y cuáles no, sería aún mejor, ¿verdad? Basta con pulsar el botón “Show Code Coverage Coloring”, el tercero por la derecha en la ventana de “Code Coverage Results”, para obtener algo como la siguiente imagen.

ColoredCode

¡Genial! Ahora no sólo sé la cantidad de código que me falta por testear, sino que incluso sé qué para qué código necesito escribir nuevos tests. Vale, esto se salta totalmente los principios de TDD, pero la vida no siempre es maravillosa…

Un último apunte para terminar: he comprobado (en mis carnes) que algunos proyectos dan problemas al intentar configurar los ensamblados a los que se les va a calcular la cobertura de código.

Los síntomas son sencillos: abrimos el .testrunconfig, pinchamos en “Code Coverage”, y la ventana se cierra sin emitir ningún error. No soy el primero al que le pasa y aunque está reportado como bug, aparentemente sigue sin solucionarse.

La forma de evitarlo es tan chapucera como útil: simplemente hay que hacer el unload de algunos proyectos que son los que dan problemas. A mí, personalmente, me ha ocurrido exclusivamente con los proyectos de base de datos, pero parece ser que también existen problemas con proyectos WSSF. Avisados quedáis.

Code Coverage (I): Activación

Voy a decirlo aquí en alto y con vergüenza: hasta esta semana, no había usado nunca el Code Coverage. Y como ocurre con todas las buenas herramientas, ahora pienso: “¿cómo he podido estar sin esto hasta ahora?”.

Empezar a usarlo es sencillo, aunque tiene una pequeña peculiaridad: sólo funciona cuando los tests se ejecutan, no si se depurar. ¿Qué quiere decir esto? Que a la hora de seleccionar el conjunto de tests que queramos lanzar, deberemos utilizar la opción “Run Selection” en lugar de “Debug Selection”, en la ventana de “Test View”.

TestViewWindow

Como ya sabemos, el problema de esto es que cualquier punto de depuración que tengamos en el código no va a ejecutarse, pero parece un mal menor comparado con las posibilidades que tiene Code Coverage. Además, uno de los principios de testeo unitario es precisamente evitar la necesidad de depurar el código, así que no hay de qué quejarse.

Para poder ver la pestaña que muestra los resultados de cobertura de código existen dos posibilidades: pulsar el último de los botones que parecen en la ventana de “Test Results” o bien acceder a la opción de menú “Test – Windows – Code Coverage Results”.

Sin embargo, de poco nos servirá esto si no activamos previamente el Code Coverage para que se calculen sus resultados. Esto se configura en el fichero .testrunconfig que existe en la carpeta “Solution Items”.

TestRunConfig

Una vez abierto, hay pulsar en la opción de “Code Coverage” y seleccionar los assemblies sobre los que vamos a calcular la cobertura de código. Este punto es más importante de lo que podría pensarse, puesto que lo normal será tener dos versiones para cada uno: la versión de Debug y la versión de Release (podemos tener más si existen más configuraciones del proyecto). La clave es que no podemos elegir las dos a la vez, por lo que seleccionemos la que seleccionemos, tendrá que estar “sincronizada” con la configuración actual del proyecto. De lo contrario, tendremos un problema: la cobertura se calculará sobre un assembly que no tiene porqué estar actualizado con los últimos cambios que hemos hecho en el código.

Un ejemplo: digamos que hemos elegido la versión de Debug del assembly, pero tenemos configurado el proyecto en modo Release. Tenemos un 100% de cobertura de código, pero introducimos nuevas líneas en un método y compilamos (en Release). El assembly de Debug, sobre el que se va a pasar la cobertura, no ha cambiado, por lo que nos seguirá marcando 100% de cobertura aún cuando sabemos que no tenemos tests para el código que acabamos de añadir. Puede ser todo un problema, ¿verdad?

Por hoy es suficiente. Otro día, cómo interpretar los resultados y el coloreado del código.