Hands-on labs para Visual Studio 2010 Beta 2

Hola de nuevo, pues parece que hay más regalitos de Visual Studio 🙂 y es que además de las máquinas virtuales que comentaba ayer para hacer nuestras pruebas, nos hacen otro pequeño regalo en forma de hands-on labs.

Y es que Brian Keller, evangelista de Visual Studio, nos ha dejado siete hands-on labs para que podamos ir  aprendiendo nuevas cosas de Visual Studio 2010, laboratiorios que podremos aprovechar con las maquinas virtuales :).

Así que aquí os dejo un link dónde Brian K. (esta vez ha ido todo de Brians), nos ha dejado los laboratorios:

http://cid-8c96cc4d0756cacb.skydrive.live.com/browse.aspx/Public/Blog%20Attachments/2010%20Beta%202%20Labs?uc=3

Que os lo paséis bien 🙂

Fuente: http://blogs.msdn.com/briankel/archive/2009/12/23/now-available-visual-studio-2010-beta-2-virtual-machines-with-sample-data.aspx

Máquinas virtuales de prueba de VSTS 2008 y VS 2010 Beta 2

Un pequeño regalo del señor ese vestido de rojo, de Brian Randell, y que viene en forma de máquinas virtuales totalmente listas para hacer pruebas de VSTS 2008, y por otro lado de VS 2010 Ultimate Beta 2.

Y es que, como bién sabéis, ya existían unas máquinas virtuales de VS 2008 totalmente listas para jugar con ellas, pero como bien he dicho, para jugar, tenían fecha de caducidad de este mes, así que, el amigo Brian, nos proporciona una versión actualizada de las mismas, y que vienen en 2 x 2 sabores, distintos, a saber:

Las imágenes de Virtual PC 2007/Virtual Server 2005 R2, tienen un pequeño truco, nos dan dos formatos de VMC, el acabado en –V7 son para Virtual PC, y las acabadas en –R2, son para Virtual Server (fácil no?). Estas máquinas caducan el 31 de enero del 2011.

Y más regalitos, ya que estaban liados, han creado máquinas de Visual Studio 2010 Beta 2 para poder probarlo, estas vienen sólo en 1 x 3 sabores, y ojo que vienen en plan de evaluación, y como Brian R. nos comenta, el SQL Server, nos dejará de funcionar el 9 de abril (y por ende el TFS …).

Bueno, pues ya tenéis cositas para divertiros los ratos que os dejen el resto de regalos 🙂

Generando bootstrappers en nuestras Team Build

En la mayor parte de mis proyectos últimamente, estoy creando los setups con WiX, que la verdad es que es muy potente a la hora de crear setups, aunque su curva de aprendizaje es realmente empinada …

Sin embargo, con sólo tener el msi del instalable no siempre es suficiente, cuando vasa distribuir software que tiene dependencias externas, como por ejemplo, el propio .NET Framework, necesitamos, antes de instalar nuestro software, asegurarnos que el cliente tiene instaladas estas dependencias.

Aquí es dónde entran los “bootstrappers”, que básicamente son un envoltorio de nuestro msi, que verifica antes que las dependencias externas, y si no las tiene las instala.

Para este post me voy a basar en las dependencias de Microsoft, que las tenemos disponibles en el directorio de SDK cuando instalamos el propio Visual Studio 2008, si miráis  en %Program Files%Microsoft SDKsWindowsv6.0ABootstrapperPackages podéis ver los paquetes de dependencias que tenéis disponibles en vuestra máquina (comrpbadlo también en la máquina de Team Build de paso).

Dependiendo del tipo de paquete, algunos tendremos los ficheros instalables de las dependencias directamente, para incluirlos en nuestro setup final, además de unos ficheros Xml con todas las propiedades del paquete. Otra opción, que será la que usemos en este ejemplo, es que en vez de incluir todos los ficheros en nuestro setup (incrementando el peso final), le podemos decir, al generar el bootstrapper, que los coja de lo que llama el HomeSite que no es otra cosa que lo coja desde internet directamente (de la web de Microsoft por ejemplo) que es lo que yo siempre procuro hacer, para que los instalables sean lo más ligeros posibles (aunque necesitarán de internet).

Antes de incorporar una dependencia, quiero que miréis, en el directorio del paquete del Framework 3.5 por ejemplo, el fichero product.xml, abridlo con el bloc de notas mismamente  y os vais directamente al final del fichero, dónde tenéis el siguiente Xml:

<RelatedProducts>
    <DependsOnProduct Code=”Microsoft.Windows.Installer.3.1″ />
    <IncludesProduct Code=”Microsoft.Net.Framework.2.0″ />
    <IncludesProduct Code=”Microsoft.Net.Framework.3.0″ />
</RelatedProducts>

Esto nos especifica, que si incluimos este paquete en una de nuestros bootstrapper, tenemos dependencia de Windows Installer 3.1 (que incluiremos también en nuestro bootstrapper), y que instala el Framework 2 y el 3.

Bien, ya vemos un poco de dónde vamos a sacar las dependencias externas para nuestro setup, vamos a configurar la build.

Supongamos que ya tenemos una Team Build, que compila nuestra solución, y que tiene un proyecto de WiX en la misma, y que genera un msi con nuestro instalable. Hasta aquí todo se hace con Team Build, sin necesidad de hacer nada nuevo, más que una configuración de build que compile nuestro proyecto WiX. Y supongamos que nuestro producto requiere del framework 3.5 SP1.

Por cierto, un pequeño apunte :), el paquete para bootstrapper del .NET 3.5 SP1, NO viene por defecto con ninguna instalación de VS 2008 ni siquiera con SP1, necesitaremos instalar un Visual Studio Express con SP1 preinstalado (http://www.microsoft.com/express/download/) que si que trae este paquete. La podéis instalar en una máquina virtual, y del directorio que os he dicho anes, coger el paquete directamente (directorio DotNetFX35SP1), y copiarlo a tu maquina en en directorio de paquetes.

Vale, pues lo que vamos a hacer ahora es editar nuestra Team Build, tenemos que abrir el fichero TFSBuild.proj y lo que vamos a hacer, es, en el paso de Team Build AfterDropBuild, cuando ya tengamos todo compilado, y copiado al directorio de destino, vamos a generar el bootstrapper.

Lo primero, es decir que dependencias vamos a incluir, para esto, añadimos las siguientes líneas al fichero TFSBuild.proj, justo antes del cierre </Target>:

<ItemGroup>  
    <BootstrapperFile Include=”Microsoft.Net.Framework.3.5.SP1″>
      <Visible>False</Visible>
      <ProductName>.NET Framework 3.5 SP1</ProductName>
      <Install>true</Install>
    </BootstrapperFile>
    <BootstrapperFile Include=”Microsoft.Windows.Installer.3.1″>
      <Visible>False</Visible>
      <ProductName>Windows Installer 3.1</ProductName>
      <Install>true</Install>
    </BootstrapperFile>
</ItemGroup>

Y, a continuación vamos a poner el código para generar el bootstrapper usando esos items:

<Target Name=”AfterDropBuild”>

   <!–Bootstrapper for Manager EN–>
   <GenerateBootstrapper
       ApplicationFile=”MiMsi.msi”
       ApplicationName=”Mi Setup”
       BootstrapperItems=”@(BootstrapperFile)”
       OutputPath=”$(DropLocation)$(BuildNumber)DirectorioDestino”
       ComponentsLocation=”HomeSite”
       Culture=”en”
   />

<Copy SourceFiles=”$(OutDir)MiMsi.msi” DestinationFolder=”$(DropLocation)$(BuildNumber)DirectorioDestino”></Copy>

</Target>

Aquí le estamos diciendo, que después de haber copiado los ficheros compilados al directorio final, vamoa a generar un bootstrapper, para el msi llamado MiMsi.msi, le damos el nombre para mostrar en el bootstrapper (el título de la pantalla), la conlección de items que hemos creado antes, en OutputPath le damos el directorio dónde va a generar el fichero setup.exe (el bootstrapper), al decirle en ComponentsLocation el valor HomeSite, le decimos que cogerá los paquetes desde internet, y por último el idioma del bootstrapper (en este caso inglés).

Como último paso, copio nuestro msi, desde el directorio dónde lo ha compilado Team Build, hasta el directorio de destino dónde ya hemos generado el setup.exe, que lanza la instalación de las dependencias, y a continuación lanzaría nuestro msi.

Podéis ver que no es excesivamente difícil hacer nuestro propio bootstrapper, que instale primero nuestras dependencias, y a continuación nuestra aplicación. Tampoco es que sea un proceso muy sencillo (como sería deseable), pero con esto y la documentación de la tarea GenerateBootstrapper del MSDN podéis empezara crear vuestros propios bootstrapper: http://msdn.microsoft.com/en-us/library/ms164294(VS.85).aspx

Por cierto, todo esto realmente es MSBuild, yo he incluido el target en mi build de Team Build en el último paso, pero si no tenemos Team Build, y editando los ficheros .wixproj, podemos incluirlo en nuestra compilación local, creando, por ejemplo un target (cambiando lo de AfterDropBuild), llamado “Bootstrapper”, y ejecutandolo desde línea de comandos con MSBuild :

msbuild MiWix.wixproj /target:Bootstrapper

Cambiando los directorios necesarios también, lógicamente 🙂

Bueno espero que os haya sido de ayuda, aunque es un poco complejo de seguir, cualquier duda aquí me tenéis.

Plantilla Scrum for Team System de Conchango para TFS 2010

Buenas noticias para todos aquellos que usamos la plantilla de Scrum de Conchango, y es que alguien en el ALM 09 me preguntaba acerca de la plantilla de Scrum de Conchango para TFS 2010, y mi respuesta era que estaban trabajando en ella pero aún no había nada público.

Pues eso era hasta hoy, ya han puesto la Beta 2 de la nueva plantilla disponible para descargar, la verdad es que le han dado una vuelta grande, y la han agregado mucha funcionalidad nueva, aunque eso supone un poco más de complejidad en su uso.

Esta Beta 2 de la plantilla, está diseñada para TFS 2010 Beta 2, y está disponible tanto para x86 como para x64, habrá que probarla, aunque la verdad, es que la plantilla de MSF Agile 5.0, me parece bastante buena también para hacer Scrum (se ve la dirección de MSF Agile hacia Scrum …)

En fin, que aquí os dejo el hilo del foro dónde la tenéis disponible:

Scrum for Team System version 3 Beta 2