Windows Installer y la creación de WiX

Solo quiero agregar información técnica más específica sobre la tecnología de Windows Installer en sí y algo de la historia que condujo a la creación del kit de herramientas WiX, ya que esta publicación puede ser encontrada por personas que recién se están iniciando en el campo de los instaladores de WiX. y el instalador de Windows.

Esto pretende ser una introducción rápida a WiX y MSI desde la perspectiva del desarrollador . También hay un artículo algo popular en serverfault.com que podría ser útil para comprender los beneficios de Windows Installer: Los beneficios corporativos de usar archivos MSI (a muchos desarrolladores no les gusta Windows Installer, pero los beneficios de implementación corporativa son en realidad bastante significativos; tal vez valga la pena leerlos rápidamente si crees que MSI es más problemático de lo que vale).

El origen del kit de herramientas WiX

Los archivos MSI son esencialmente bases de datos simplificadas de SQL Server almacenadas como archivos de almacenamiento estructurados COM . Este es el formato de archivo utilizado 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 son los archivos que se instalan dentro de uno o más archivos cab .

Al principio, los archivos/bases de datos MSI se modificaban mejor directamente utilizando herramientas de terceros como InstallShield , Advanced Installer yEstudio de paquete sabio(ya no está disponible debido a cuestiones legales; consulte una comparación de las herramientas MSI disponibles actualmente ). Estas herramientas almacenaron el archivo MSI en su formato nativo "instalable" como un archivo de almacenamiento estructurado COM. Esto significaba que su archivo MSI era tanto fuente como ejecutable, y en formato binario. Esto dificultó el control del código fuente de su proyecto de instalación. Las diferencias binarias en diferentes bases de datos MSI fueron difíciles y, debido a la integridad referencial de la base de datos , incluso los cambios más básicos en el MSI se reflejarán en docenas de tablas y dificultarán ver qué cambió incluso para 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 WiX. Este es un salto cualitativo en términos de gestionar el proceso de publicación y comprender los cambios en el archivo MSI. El conjunto de herramientas es muy completo y mucho más intuitivo para un desarrollador y presenta un grado de "automagia" en el sentido de 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 propia base de datos. En efecto, WiX lleva a MSI desde sus orígenes de base de datos a la "era XML" actual, de modo que los desarrolladores trabajan con archivos de texto y los archivos MSI pueden verse como ejecutables compilados en lugar de archivos fuente de bases de datos.

De hecho, 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, créame, como desarrollador, querrá mantenerse al margen de los archivos MSI. Son complejos, y distintivamente poco ortodoxos y contrarios a la intuición para la mentalidad de un desarrollador. Tiene que ver con la complejidad de almacenar un instalador completo como una única base de datos. Es casi en su totalidad declarativo y no procesal, pero algunas partes son secuenciales y definen el orden de instalación. Muchas piezas móviles y un mecanismo de " complejidad conspirativa " (errores que descubres cuando pensabas 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 operaciones del sistema de archivos ejecutadas como una transacción de base de datos . Cuando aprende MSI como desarrollador, seguramente sentirá que "algo anda mal con este diseño", y la verdad es que toda la tecnología se diseñó en torno a 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 un adelanto de lo que vendrá: tal vez Windows utilice SQL Server como su principal solución de almacenamiento en el futuro, y MSI sea el primer paso para convertir la implementación en un "lenguaje declarativo" o una enorme declaración SQL para lo que es. ¿Qué sucederá en el sistema de destino durante la implementación? Aunque esto es sólo una especulación.

Algunos consejos prácticos de WiX

Mantenlo simple, sigue las mejores prácticas y hagas lo que hagas, no luches contra el diseño: él se defiende . Si WiX no puede hacerlo, es probable que esté intentando ayudarle a evitar problemas de implementación. Luche con su gerente para simplificar o cambiar los requisitos, no con MSI; por una vez es más fácil :-).

La mayoría de las veces encontramos que los diseños de configuración inusuales y el uso de acciones personalizadas causan mucha complejidad innecesaria, o antipatrones de implementación si lo desea, y el problema a menudo se puede evitar mediante pequeños cambios en el diseño de la aplicación o el uso de construcciones MSI integradas . Un buen administrador permitirá esfuerzos para simplificar la implementación, pero debe comprender por qué es necesario. Me gustan las licencias como ejemplo de cómo se pueden hacer las cosas de manera diferente y simplificar la implementación evitando soluciones de implementación y aplicación anticuadas o innecesariamente complicadas.

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

Este consejo en particular no puede ser exagerado . En mi opinión personal, las acciones personalizadas de sólo 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 requieran soporte de reversión y se pueden usar de manera muy efectiva para reunir la lógica de configuración en un solo lugar, y lo que es más importante, funcionan bien entre compañeros de trabajo para permitir retomar el trabajo de cada uno cuando está escrito en lenguajes de programación simples comojavascript(algunos aspectos torpes cuando se trata de la API de MSI) o VBScript (manejo de errores deficiente y características generales del lenguaje, pero bien probado con la API de MSI. Francamente, parece que Microsoft está tratando de "matar" el lenguaje. JavaScript está al menos "vivo"). y bien" en uso intensivo para material web).

Para resumir con respecto a los scripts: existe un acuerdo general entre los especialistas en implementación de que las acciones de script 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 que requieren la 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. Aquí hay una larga "discusión" sobre este tema: pros y contras de diferentes tipos de acciones personalizadas (no es genial, solo una muestra de experiencia del mundo real). Sin embargo, podría valer la pena echarle un vistazo: las acciones personalizadas son la principal causa de fallas en el despliegue (enlace a mi propaganda contra ellas), y esto nos lleva al siguiente punto: la complejidad general del despliegue (y cómo abordarlo).

La complejidad del despliegue

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

1. Los errores son de naturaleza acumulativa : a menudo causan más problemas cuanto más intenta arreglar las cosas con una solución rápida. Muy pronto será imposible tenerlo en cuenta, ya que el problema generalmente está "en estado salvaje" (publicado) y debe tratarse como un proceso de entrega: cada iteración con su propio riesgo añadido, y no solo un problema único que resolver. depura hasta que tengas una solución.
2. Los errores son extremadamente difíciles de depurar cuando no se tiene acceso al sistema en cuestión . El registro puede ayudar cuando se hace correctamente, pero a menudo no se le entrega cuando lo necesita para la depuración, o tiene el formato o detalle incorrectos, o simplemente es completamente inútil ya que las acciones personalizadas a menudo no registran las cosas correctamente.
3. 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 lo utilizan la mayoría de las empresas con instalaciones y paquetes de sistemas operativos estandarizados): diferencias de hardware y controladores (grandes y pequeño), cliente pesado/cliente ligero, servidor terminal, plataforma del sistema operativo (x86/x64/etc...), versión del sistema operativo (Win7, Win10, WinXP, etc...), edición del 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 sistemas 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 red (dominio, grupo de trabajo, etc...), subredes, configuración de proxy, sistema y configuración de correo electrónico (Exchange, Outlook, Novell, etc...), directorio activo, esquema de autenticación, unidades y recursos compartidos de red, estado de aplicaciones, disponibilidad de secuencias de comandos, bloqueo de secuencias de comandos, todo tipo de versiones de tiempo de ejecución (C, C++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, tiempos de ejecución de secuencias de comandos), registro de objetos COM y DCOM y configuración, COM+, IIS y servidores web, variables de ruta y variables ambientales, 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), software firewalls, sistemas emulados/virtualizados, sistema de despliegue (SCCM, Tivoli, Etc...). Lo sigue y sigue.

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

Más información sobre la implementación y lo que podría necesitar 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 que realice una configuración, salpicado de 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 seguir siendo relevante para los desarrolladores.

Herramientas MSI relacionadas

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

Orca es la herramienta SDK de Windows que permite abrir, editar y, hasta cierto punto, comparar archivos binarios MSI. De hecho, fue escrito principalmente por el hombre que más tarde creó el 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 una de las favoritas de los empaquetadores de aplicaciones para usar y tener disponible para depuración y pequeñas correcciones debido a su confiabilidad , simplicidad y " limpieza "; no agrega "valores predeterminados". basura" a un MSI al guardarlo (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 sencilla, y no una herramienta básica en absoluto :-). Para poder hacerse con Orca, necesita instalar el SDK de Windows (!). En realidad, un poco exagerado 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, búsquelo Orca-x86_en-us.msie instálelo. Si no es así, ¿tal vez un amigo que tenga Visual Studio instalado lo busque y luego se lo envíe? Es un archivo pequeño.

También hay algunas herramientas alternativas gratuitas 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 manejar 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 analiza su uso y describe sus componentes básicos. Los archivos de ayuda incluidos con DTF lo ayudarán a comenzar rápidamente con el kit de herramientas y nunca volverá a utilizar funciones Win32 o clases COM para acceder a archivos MSI.

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

Aug 23 '2012 23:08 Stein Åsmul