tutorial - Windows Installer y la creación de WiX

wix visual studio 2012 (2)

Solo quiero agregar información técnica más específica sobre la tecnología Windows Installer, y parte de la historia previa a la creación del kit de herramientas WiX, ya que esta publicación puede ser encontrada por personas que recién ingresan al campo de los instaladores, WiX y Windows Installer.

Esto pretende ser una introducción rápida a WiX y MSI desde la perspectiva de un desarrollador . También hay un artículo de serverfault.com algo popular que podría ser útil para captar los beneficios del instalador de Windows: los beneficios corporativos del uso de archivos MSI (a muchos desarrolladores no les gusta el instalador de Windows, pero los beneficios de la implementación corporativa son bastante significativos; crees que MSI es más problema de lo que vale).

El origen del kit de herramientas WiX.

Los archivos MSI son esencialmente bases de datos de SQL Server almacenadas como archivos de almacenamiento estructurados por COM . Este es el formato de archivo usado en Microsoft Office (tenga en cuenta que MS Office solía usar archivos OLE / COM , pero las versiones más nuevas ahora usan Office Open XML ), y fue diseñado como una forma de almacenar datos jerárquicos dentro de un solo archivo. Esencialmente, un sistema de archivos dentro de un archivo con flujos de almacenamiento de varios tipos, uno de los cuales es el de los archivos que se instalan dentro de uno o más archivos de cabina .

Al principio, los archivos / bases de datos MSI se modificaban mejor directamente utilizando herramientas de terceros, como InstallShield , Advanced Installer y ~~Wise Package Studio~~ (ya no está disponible debido a problemas legales; consulte una comparación de las herramientas MSI actualmente disponibles ). Estas herramientas almacenaron el archivo MSI en su formato "instalable" nativo como un archivo de almacenamiento estructurado COM. Esto significaba que su archivo MSI era fuente y ejecutable, y en formato binario. Esto hizo difícil el control de la fuente de su proyecto de instalación. Las diferencias binarias en diferentes bases de datos de MSI eran difíciles, y debido a la integridad referencial de la base de datos , incluso los cambios más básicos en el MSI se acumularán en docenas de tablas y dificultarán ver qué ha cambiado incluso para los ojos entrenados.

WiX surgió como una forma para que los desarrolladores permitieran la creación de un archivo MSI binario a partir de archivos fuente de texto normales. Al igual que un binario EXE normal, un binario MSI se "compila" a partir de archivos XML de texto de WiX. Este es un gran salto en cuanto a la administración del proceso de publicación y la comprensión de los cambios en el archivo MSI. El kit de herramientas es muy completo y mucho más intuitivo para un desarrollador y presenta un grado de "automágico", ya que protege al desarrollador de algunas de las complejidades del esquema de la base de datos MSI, ya que los cambios se realizan en un formato XML con su propio esquema y no la base de datos en sí. En efecto, WiX lleva a MSI de los orígenes de su base de datos a la "era XML" de hoy en día para que los desarrolladores trabajen con archivos de texto, y los archivos MSI se pueden ver como ejecutables compilados en lugar de los archivos de origen de la base de datos.

En realidad, es posible crear buenos archivos MSI sin saber demasiado sobre el funcionamiento interno del archivo MSI, siempre que siga las mejores prácticas de WiX , y confíe en mí como desarrollador, querrá mantenerse alejado de los archivos MSI. Son complejos, distintivamente heterodoxos y contraintuitivos para una mentalidad de desarrollador. Tiene que ver con la complejidad de almacenar un instalador completo como una sola base de datos. Es casi totalmente declarativo y no procesal, pero algunas partes son secuenciales y definen el orden de instalación. Un montón de piezas móviles y un mecanismo de " complejidad conspiratoria " (errores que descubres al pensar que todo estaba bien).

Estas construcciones de secuenciación son algunas de las partes más complejas de un MSI que involucran " derechos elevados " y las operaciones del sistema de archivos se ejecutan como una transacción de base de datos . Cuando aprende MSI como desarrollador, tiene la certeza de que "algo anda mal con este diseño", y la verdad es que toda la tecnología se diseñó alrededor de los requisitos de implementación de Office en el pasado, y se volvió tan compleja como tenía que ser. Además, los archivos MSI pueden ser una vista previa de lo que vendrá, tal vez Windows utilizará SQL Server como su principal solución de almacenamiento en el futuro, y MSI es el primer paso para convertir la implementación en un "lenguaje declarativo" o una gran declaración SQL de lo que es. va a suceder en el sistema de destino durante el despliegue? Esto es sólo una especulación.

Algunos consejos prácticos de WiX.

Manténgalo simple, siga las mejores prácticas y haga lo que haga, no luche contra el diseño, se resiste . Si WiX no puede hacerlo, es probable que esté tratando de ayudarlo a evitar problemas de implementación. Luche a su gerente para simplificar o cambiar los requisitos, no MSI, por una vez es más fácil :-).

La mayoría de las veces nos encontramos con que los diseños de configuración inusuales y el uso de acciones personalizadas causan una gran cantidad de complejidad innecesaria o despliegues antipatrónicos si lo desea, y el problema a menudo se puede evitar con pequeños cambios en el diseño de la aplicación o el uso de construcciones de MSI incorporadas . Un buen administrador permitirá los esfuerzos para simplificar la implementación, pero deben entender por qué es necesario. Me gusta la licensing como ejemplo de cómo puede hacer las cosas de manera diferente y hacer que la implementación sea más sencilla al evitar las soluciones de implementación y aplicación antiguas o innecesarias.

Evite acciones personalizadas innecesarias (lectura / escritura) a toda costa : cuadruplican la complejidad y el riesgo de una configuración. Pregunte aquí en Stack Overflow y busque si hay una alternativa incorporada. En la mayoría o al menos muchos casos, hay construcciones integradas equivalentes en MSI para hacer el trabajo.

Este consejo en particular no puede ser exagerado . En mi opinión personal, las acciones personalizadas de solo lectura (que pueden establecer propiedades) son todo lo contrario: se recomiendan. No causan un riesgo adicional significativo en la mayoría de los casos, ya que no realizan cambios en el sistema que requieren soporte de reversión, y pueden usarse de manera muy efectiva para recopilar la lógica de configuración en un solo lugar, y fundamentalmente funcionan bien entre compañeros de trabajo para permitir la recuperación el trabajo de cada uno cuando está escrito en lenguajes de script simples como ~~JavaScript~~ (algunos aspectos torpes al tratar con la API de MSI) o VBScript (manejo de errores deficientes y características generales del idioma, pero bien probadas con la API de MSI. Francamente, parece que Microsoft está tratando de "matar" el idioma. JavaScript está al menos "vivo" y bien "en uso pesado para cosas web).

Para resumir las cosas con respecto a las secuencias de comandos: hay un consenso general entre los especialistas en implementación de que las acciones de secuencia de comandos de todo tipo son, en general, difíciles de depurar , vulnerables a la interferencia de antivirus y carecen de las características de lenguaje necesarias para implementar construcciones de codificación avanzadas. En conclusión: es difícil escribir código robusto con scripts, de cualquier tipo. Las acciones personalizadas de código administrado son posibles (.NET), pero debido a su requisito de instalación de .NET, la recomendación segura es escribir acciones personalizadas en C ++. Esto permite dependencias mínimas, muy buena depuración y construcciones de lenguaje avanzadas. Hay una larga "discusión" de este tema aquí: ventajas y desventajas de diferentes tipos de acciones personalizadas (no es genial, solo es un basurero de la experiencia del mundo real). Sin embargo, puede que valga la pena: las acciones personalizadas son la causa principal de los fallos de implementación (enlace a mi propaganda en su contra), y esto nos lleva al siguiente punto: la complejidad general de la implementación (y cómo tratarla).

La complejidad de la implementación

La implementación es el proceso complejo de migrar equipos de destino heterogéneos de un estado estable a otro; esto requiere un enfoque disciplinado ya que:

Los errores son acumulativos en la naturaleza : a menudo causan más problemas a medida que intenta arreglar las cosas con una solución rápida. Muy pronto tendrá la imposibilidad de mantenerlo en sus manos, ya que el problema generalmente está "en libertad" (publicado) y debe tratarse como un proceso de entrega: cada iteración tiene su propio riesgo agregado, y no solo un solo problema para depura hasta que tengas una solución.
Los errores son extremadamente difíciles de depurar cuando no tiene acceso al sistema en cuestión . El registro puede ayudar cuando se realiza correctamente, pero a menudo no se le entrega cuando lo necesita para la depuración, o está en el formato o verbosidad incorrectos, o simplemente es completamente inútil ya que las acciones personalizadas a menudo no registran las cosas correctamente.
Los sistemas de destino (y el entorno de destino) difieren en casi todos los aspectos imaginables (este es el caso incluso si se trata de un entorno operativo estándar (SOE), como la mayoría de las empresas utilizan con paquetes e instalaciones de sistemas operativos estandarizados): diferencias de hardware y controladores (grandes y pequeño), fat client / thin client, servidor de terminal, plataforma de sistema operativo (x86 / x64 / etc ...), versión de sistema operativo (Win7, Win10, WinXP, etc ...), edición de sistema operativo (ultimate, home, etc. .), Versión de idioma del sistema operativo, estado de actualización del sistema operativo y nivel de parche, situación de malware, problemas de espacio en disco, esquema de partición, tipos de sistema de archivos, problemas de cifrado (sistema de archivos, red), configuración de derechos de usuario, configuración de UAC, configuración de privilegios del sistema ( NTRights ) , tipo de conexión, velocidad de conexión, configuración de la red (dominio, grupo de trabajo, etc.), subredes, configuración de proxy, sistema de correo electrónico y configuración (Exchange, Outlook, Novell, etc.), directorio activo, esquema de autenticación, recursos compartidos y unidades de red, estado de la aplicación, disponibilidad de scripts, scripts lock-dow n, todo tipo de versiones de tiempo de ejecución (C, C ++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, tiempo de ejecución de secuencias de comandos), registro y configuración de objetos COM y DCOM, COM +, IIS y servidores web, variables de ruta y entorno variables, asociaciones de archivos y operaciones de shell, configuración de software inalámbrico, número de usuarios, versiones y configuración de .NET, paquetes de idiomas, estado y configuración de GAC y WinSxS (archivos de políticas), firewalls de software, sistemas emulados / virtualizados, sistema de implementación (SCCM, Tivoli) , Etc ...). Lo sigue y sigue.

La implementación es un concepto simple, con una mezcla complicada de variables que pueden causar los errores más misteriosos, incluido el favorito del desarrollador: el error intermitente . Como todos sabemos, la gravedad de estos errores no puede ser exagerada, ya que a menudo son imposibles de eliminar correctamente.

Más información sobre la implementación y lo que debe hacer un programa de instalación moderno: ¿Cuál es el beneficio y el propósito real de la instalación del programa? . Este es un resumen de las tareas que se pueden requerir para realizar una configuración con varios detalles técnicos. Es posible que se hayan agregado demasiados detalles, lo que tal vez destruya la "calidad general" de la respuesta. Sin embargo, la intención es permanecer relevante para los desarrolladores.

Herramientas de MSI relacionadas

Un archivo de proyecto MSI de Visual Studio es una forma liviana de crear un archivo MSI como parte de Visual Studio, y fue extremadamente limitado en su conjunto de características. Hubo conversaciones para reemplazar el tipo de proyecto MSI dentro de Visual Studio con un proyecto WiX XML, y así es como la gente construye sus archivos MSI ahora. No utilice este tipo de proyecto. Ha causado serios problemas para muchos usuarios debido a su falta de flexibilidad y errores graves.

Orca es la herramienta SDK de Windows que permite abrir, editar y comparar en cierta medida los archivos MSI binarios. De hecho, fue escrito principalmente por el hombre que más tarde creó el propio kit de herramientas WiX. Rob Mensching mientras trabajaba en el equipo de Windows Installer en Microsoft . La herramienta también permite otras operaciones, como generar archivos de transformación para modificar los archivos MSI y algunas otras operaciones técnicas. Aunque es una herramienta muy básica que carece de las funciones más avanzadas disponibles en las herramientas comerciales, sigue siendo un paquete de aplicaciones favorito para usar y está disponible para la depuración y pequeñas correcciones debido a su confiabilidad , simplicidad y " limpieza "; no agrega "predeterminado" basura "a un MSI al guardarla (las herramientas de terceros agregan tablas personalizadas y basura similar). Lo uso para pequeñas actualizaciones de MSI , depuración , inspección del flujo de resumen , creación de transformaciones básicas , visualización de parches , validación de paquetes y otras operaciones importantes.

De hecho, supongo que es una herramienta avanzada, con una interfaz simple, y no una herramienta básica :-). Para poder obtener Orca, debe instalar el SDK de Windows (!). Un poco exagerado realmente cuando el tamaño de la herramienta es tan pequeño, pero al menos es fácil saber dónde está disponible en lugar de buscar una descarga por separado.

ACTUALIZACIÓN : si tiene Visual Studio y el SDK instalado, busque Orca-x86_en-us.msi e instálelo. Si no lo hace, tal vez tenga un amigo con Visual Studio instalado, búsquelo y luego se lo envíe. Es un archivo pequeño.

También hay algunas herramientas gratuitas alternativas disponibles como se describe aquí (hacia abajo): ¿Cómo puedo comparar el contenido de dos (o más) archivos MSI?

DTF - Deployment Tools Foundation es un conjunto de clases .NET para tratar los archivos MSI mediante programación. Bien escrito, fácil de usar y muy potente, ahora se incluye con la descarga principal de WiX . Es un componente crucial en cualquier proyecto para automatizar el uso corporativo de archivos MSI. Aquí hay una breve respuesta en serverfault.com que discute su uso y describe sus componentes básicos. Los archivos de ayuda que se incluyen con DTF lo harán avanzar rápidamente con el kit de herramientas, y nunca volverá a usar las funciones Win32 o las clases COM para acceder a los archivos MSI.

Hay muchas otras herramientas de Windows Installer en el mercado, y algunas de ellas se pueden encontrar en comparación con WiX en ¿Qué producto de instalación usar? InstallShield, WiX, Wise, Advanced Installer, etc. (mismo enlace que el anterior).

Actualmente utilizamos WiX para compilar nuestros archivos MSI y, como tal, es el único constructor de MSI que tengo experiencia usando. Sé que puedes construir instaladores de forma nativa en Visual Studio. ¿Cuáles son las diferencias entre usar WiX y Windows Installer, y cuáles son las ventajas y desventajas de cada uno?

WiX crea paquetes MSI que utilizan Windows Installer. Así que WiX usa el motor de Windows Installer.

Visual Studio es solo una alternativa de WiX, solo otra herramienta de creación de configuraciones. No lo recomiendo porque es extremadamente limitado. Ofrece sólo características básicas.

Si estás contento con WiX, quédate con él.