Windows Installer y la creación de WiX

Actualmente usamos WiX para construir nuestros archivos MSI, y como tal, es el único constructor de MSI que he tenido experiencia en usar. Sé que puedes construir instaladores nativamente en Visual Studio. ¿Cuáles son las diferencias entre usar WiX y Windows Installer, y cuáles son los pros y los contras de cada uno?

Solo quiero agregar información técnica más específica sobre la tecnología de Windows Installer, y parte del historial que conduce a la creación del kit de herramientas de WiX, ya que esta publicación puede ser encontrada por personas que acaban de ingresar 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 bastante popular que podría ser útil para comprender los beneficios de Windows Installer: los beneficios corporativos del uso de archivos MSI (a muchos desarrolladores no les gusta Windows Installer, pero los beneficios de la implementación corporativa son bastante significativos, tal vez vale la pena echarle un vistazo rápido si crees que MSI es más problemático de lo que vale).

El origen del kit de herramientas de WiX

Los archivos MSI son esencialmente desmantelados en bases de datos SQL Server almacenadas como archivos de almacenamiento estructurados por 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 único archivo. Esencialmente un sistema de archivos dentro de un archivo con flujos de almacenamiento de varios tipos, uno de los cuales es los archivos para instalar dentro de uno o más archivos cab .

Al principio, los archivos / bases de datos de MSI se modificaron mejor utilizando herramientas de terceros como InstallShield , Advanced Installer y Wise Package Studio (ya no está disponible debido a problemas legales – vea una comparación de herramientas MSI actualmente disponibles ). Estas herramientas almacenan 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 de la fuente de su proyecto de instalación. Los diffs binarios 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 la MSI caerán en cascada a través de docenas de tablas y dificultarán ver qué cambió incluso para los ojos entrenados.

WiX apareció 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, se “comstack” un binario MSI a partir de archivos XML de texto WiX. Este es un gran salto en términos de administración de su proceso de lanzamiento y 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 cierto grado de “automatismo”, ya que protege al desarrollador de algunas de las complejidades del esquema de base de datos MSI ya que los cambios se realizan en formato XML con su propio esquema y no la base de datos en sí. En efecto, WiX lleva a MSI desde sus orígenes de bases de datos a la “era XML” de hoy para que los desarrolladores trabajen con archivos de texto, y los archivos MSI se pueden ver como ejecutables comstackdos en lugar de archivos fuente de base 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 confíe en mí como desarrollador que querrá mantener fuera de los archivos MSI. Son complejos, distintivamente poco ortodoxos y contradictorios para una mentalidad de desarrollador. Tiene que ver con la complejidad de almacenar un instalador completo como una única base de datos. Es casi completamente declarativo y no de procedimiento, pero algunas partes son secuenciales y definen el orden de instalación. Montones de partes móviles y un mecanismo de relojería de ” complejidad conspiratoria ” (trampas que descubres cuando pensabas que todo estaba bien).

Estas construcciones de secuencia son algunas de las partes más complejas de una MSI que involucra ” derechos elevados ” y las operaciones del sistema de archivos se ejecutan como una transacción de base de datos . Cuando aprendes MSI como desarrollador, sientes que “algo está mal en este diseño”, y la verdad es que toda la tecnología se diseñó en función de los requisitos de implementación para 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á – quizás Windows usará 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 enorme statement SQL para lo que es va a suceder en el sistema de destino durante el despliegue? Sin embargo, esto solo es 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, se defiende . Si WiX no puede hacerlo, es probable que intente ayudarlo a evitar problemas de implementación. Lucha con tu gerente para simplificar o cambiar los requisitos, no MSI, por una vez es más fácil :-).

La mayoría de las veces encontramos que los diseños de instalación inusuales y el uso de acciones personalizadas provocan una gran cantidad de complejidad innecesaria o antipatrones de despliegue si lo desea, y el problema a menudo puede evitarse mediante pequeños cambios en el diseño de la aplicación o el uso de construcciones incorporadas de MSI . Un buen gerente permitirá los esfuerzos para simplificar la implementación, pero deben entender por qué es necesario. Me gusta la licencia como un ejemplo de cómo puede hacer las cosas de manera diferente y simplificar la implementación al evitar las soluciones de implementación y aplicaciones anticuadas o innecesariamente complicadas.

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

Este consejo particular no puede ser exagerado . En mi opinión personal, las acciones personalizadas de solo lectura (que pueden establecer propiedades) son lo opuesto: se recomiendan. En la mayoría de los casos, no causan un riesgo adicional significativo, ya que no hacen ningún cambio en el sistema que requiera 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 crucialmente funcionan bien entre colegas para permitir el retiro el trabajo de cada uno cuando está escrito en lenguajes de scripting simples como JavaScript (algunos aspectos torpes al tratar con 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 bueno “en uso intensivo para material web).

Para resumir las cosas con respecto a las secuencias de comandos: 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 carentes de características de lenguaje necesarias para implementar construcciones de encoding avanzadas. En conclusión: es difícil escribir código sólido con scripts, de cualquier tipo. Las acciones personalizadas de código administrado son posibles (.NET), pero debido a su requisito de que se instale .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 “discusión” larga sobre este tema: pros y contras de diferentes tipos de acciones personalizadas (no es genial, solo un vertedero de la experiencia del mundo real). Aunque valdría la pena echarle un vistazo: las acciones personalizadas son la principal causa de fallas en el despliegue (enlace a mi propaganda en contra de ellas), y esto nos lleva al siguiente punto: la complejidad general de la implementación (y cómo lidiar con ella).

La complejidad de la implementación

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

  1. Los errores son acumulativos por naturaleza : a menudo causa más problemas cuanto más intenta solucionar las cosas con una solución rápida. Muy pronto tiene la imposibilidad de mantener en sus manos ya que el problema generalmente está “en la naturaleza” (publicado) y debe tratarse como un proceso de entrega, cada iteración con su propio riesgo agregado y no solo un problema para depurar hasta que tenga una solución.
  2. Los errores son extremadamente difíciles de depurar cuando no tiene acceso al sistema en cuestión . El registro puede ayudar cuando se hace correctamente, pero a menudo no se entrega cuando lo necesita para la depuración, o está en el formato o la verbosidad incorrecta, o simplemente completamente inútil ya que las acciones personalizadas a menudo no registran las cosas correctamente.
  3. Los sistemas objective (y el entorno objective) difieren en casi todas las formas imaginables (este es el caso incluso si se trata de un entorno operativo estándar (SOE) como la mayoría de las empresas usan con paquetes e instalaciones OS estandarizados): hardware y diferencias de controladores (grandes y pequeño), cliente gordo / thin client, servidor de terminal, plataforma OS (x86 / x64 / etc …), versión OS (Win7, Win10, WinXP, etc …), edición OS (ultimate, home, etc. .), Versión de idioma del sistema operativo, estado de actualización del SO y nivel de parches, situación de malware, problemas de espacio en disco, esquema de particionamiento, tipos de sistema de archivos, problemas de encriptación (sistema de archivos, red), configuración de derechos de usuario, configuración 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 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 secuencias de comandos, locking de scripts n, todo tipo de versiones en tiempo de ejecución (C, C ++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, tiempos de ejecución de scripts), registro y configuración de objetos COM y DCOM, COM +, IIS y servidores web, variables de ruta y ambientales variables, asociaciones de archivos y operaciones shell, configuración de software inalámbrico, número de usuarios, versiones .NET y configuración, paquetes de idioma, estado y configuración GAC y WinSxS (archivos de política), firewalls de software, sistemas emulados / virtualizados, sistema de implementación (SCCM, Tivoli) , Etc …). Lo sigue y sigue.

El despliegue es un concepto simple, con una combinación 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 exagerarse, ya que a menudo es imposible depurarlos adecuadamente.

Más sobre la implementación y lo que un progtwig de instalación moderno podría necesitar: ¿Cuál es el beneficio y el verdadero propósito de la instalación del progtwig? . Este es un resumen de las tareas que puede requerir una configuración para hacer salpicado con diversos detalles técnicos. Se pueden haber agregado demasiados detalles, tal vez destruyendo 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 características era extremadamente limitado. Hubo conversaciones para reemplazar el tipo de proyecto MSI dentro de Visual Studio con un proyecto WiX XML, y esta es generalmente la forma en que las personas construyen sus archivos MSI ahora. No use 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, hasta cierto punto, comparar archivos MSI binarios. De hecho, fue escrito principalmente por el hombre que más tarde creó el kit de herramientas WiX en sí. Rob Mensching mientras trabajaba en el equipo de Windows Installer en Microsoft . La herramienta también permite otras operaciones, como la generación de 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 herramientas comerciales, sigue siendo un paquete de aplicación favorito para usar y tiene disponible para la depuración y correcciones pequeñas debido a su fiabilidad , simplicidad y ” limpieza “, no agrega “predeterminado chatarra “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 , revisiones de visualización , validación de paquetes y otras operaciones importantes.

De hecho, creo que es una herramienta avanzada, con una interfaz simple, y no una herramienta básica en absoluto :-). Para hacerse con Orca, debe instalar Windows SDK (!). Un poco exagerado cuando el tamaño de la herramienta es muy 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 instalado Visual Studio y el SDK, busque Orca-x86_en-us.msi e instálelo. Si no lo hace, ¿quizás un amigo con Visual Studio lo haya buscado y luego se lo haya enviado? 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 de .NET para tratar los archivos MSI programáticamente. Bien escrito, fácil de usar y muy poderoso, 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 respuesta breve en serverfault.com que analiza su uso y describe sus componentes básicos. Los archivos de ayuda incluidos con DTF le ayudarán a avanzar rápidamente con el kit de herramientas, y nunca mirará hacia atrás al usar las funciones de Win32 o las clases COM para acceder a los archivos MSI.

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

WiX crea paquetes MSI que usan Windows Installer. Entonces, WiX usa el motor de Windows Installer.

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

Si está satisfecho con WiX, quédese con él.