¿Cuáles son las ventajas de usar archivos .msi sobre los archivos setup.exe normales?

Tengo la impresión de que la implementación es más fácil en máquinas donde los usuarios tienen pocos permisos, pero no estoy seguro de los detalles.

¿Qué características tiene msiexec.exe que hacen que la implementación sea más fácil que usar escenarios de setup.exe?

¿Algún consejo o truco al implementar aplicaciones .msi?

Solo algunos beneficios:

• Se puede anunciar (para que se pueda realizar la instalación a pedido).
• Al igual que la publicidad, las características se pueden instalar tan pronto como el usuario intente usarlas.
• La administración del estado se mantiene para que Windows Installer proporcione una forma de permitir a los administradores ver si una aplicación está instalada en una máquina.
• Posibilidad de retroceder si falla una instalación.

Creo que cuando estoy implementando software en un entorno empresarial: la implementación de software a través de MSI es casi agradable. Por el contrario, casi siempre me encuentro temiendo implementar software cuando está en otro contenedor.

Para obtener información adicional sobre la manipulación de instalaciones de MSI, escriba msiexecen el cuadro de diálogo Ejecutar.

ACTUALIZACIÓN, julio de 2018 : un resumen extremadamente comprimido de la información a continuación está disponible en stackoverflow: Los principales beneficios de MSI ( "executive summary"- de algún tipo).

He trabajado en desarrollo como administrador de versiones , ingeniero de construcción , desarrollador de configuración y como empaquetador de aplicaciones e ingeniero de implementación en grandes corporaciones.

Esta es una revisión de las mejores (y peores) características conceptuales y del mundo real de MSI. Los problemas de diseño más comunes encontrados en los archivos MSI se presentan a continuación como una respuesta separada . No pretender estar completo, en realidad es solo un "tugurio cerebral" desordenado, concebido como "esas cosas que no se pueden encontrar en los libros" (probablemente por una buena razón).

También quiero sugerir este artículo de MSDN como una buena lectura: Windows Installer: beneficios e implementación para administradores de sistemas .

Estandarización:

En una palabra, MSI trata sobre la estandarización y sobre cómo lidiar con los " olores de implementación " de las tecnologías de instalador heredadas. Una colección completa de diseños de arquitectura de instalación defectuosos que causaron repetidos problemas de implementación.

En general, MSI proporciona un marco completo y estandarizado para el instalador, que también incluye de manera crucial la desinstalación y las características y opciones integradas para el funcionamiento silencioso con una GUI estandarizada que se puede activar de forma remota .

Estas características por sí solas constituyen una mejora masiva con respecto a las tecnologías de instalación anteriores que trataban la desinstalación y la ejecución silenciosa al azar, quizás las características más importantes para la implementación corporativa junto con la administración confiable de paquetes remotos a través de Active Directory o herramientas de administración remota dedicadas como Microsoft SCCM (anteriormente SMS), IBM Tivoli , CA Unicenter y similares.

Alguien duplicó una versión anterior de esta respuesta . Tal vez una lectura más rápida?

Instaladores heredados "olores de implementación"

MSI desalienta activamente los olores de implementación heredados por diseño. Estos temas se analizan en las secciones posteriores a continuación, pero como una lista rápida, los problemas más reconocibles con los instaladores heredados y la tecnología de implementación anterior eran:

• 1) a veces degradaron y sobrescribieron archivos compartidos y versionados con poca preocupación por el dll-hell que resultó
• 2) a menudo no se proporcionó una rutina de desinstalación adecuada con el instalador, o no se completó de manera adecuada y confiable, especialmente si se ejecuta en silencio. Este es un problema muy importante para la gestión corporativa de empresas públicas
• 3) la instalación silenciosa rara vez se admitía correctamente. La confiabilidad era deficiente y, a menudo, uno tenía que registrar una ejecución de la instalación con selecciones de diálogo y esto no lidiaba bien con condiciones inesperadas como diálogos de error o diálogos de advertencia que no se registraron en la ejecución original.
• 4) el instalador no mantuvo un registro de lo que se instaló y, por lo tanto, no había una forma automática de verificar los archivos en el disco para verificar si todavía eran las versiones instaladas originalmente por el instalador
• 5) presentaron parámetros de línea de comando impredecibles, poco confiables y no estándar para el ejecutable de instalación
• 6) siguiendo la línea de comandos no estándar y la falta de estándares, fue difícil personalizar los instaladores con valores específicos necesarios para la implementación corporativa de una manera confiable y predecible
• 7) los usuarios normales no podían ejecutar estas instalaciones, y a menudo uno tenía que perder el tiempo con los derechos de administrador temporales (use "ejecutar como" si eso fuera suficiente, o inicie sesión como administrador, instale y luego cierre sesión - esta generación completa de inicio de sesión y perfil a veces era necesario para completar la instalación)
• 8) el instalador setup.exe a menudo no devuelve un código de error adecuado o un código de éxito, y a veces se cierra inmediatamente e inicia otro proceso que finalizará la instalación, lo que hace difícil determinar si la instalación se completó, especialmente a través de un lote archivo
• 9) la mayoría de los archivos setup.exe permitieron extraer los archivos, pero no de una manera confiable y predecible: generalmente tenía que pasar mucho tiempo buscando los interruptores correctos para hacerlo
• 10) la tala fue generalmente pobre y bastante azarosa en algunas herramientas. La depuración con archivos de registro rara vez produce claridad, pero ayudó un poco
• 11) no había transparencia en lo que estaba haciendo el instalador y ninguna reversión no confiable para deshacer los cambios después de una instalación fallida
• 12) no existía una forma estándar de la industria de implementar componentes de tiempo de ejecución compartidos, ya fueran componentes del sistema operativo, componentes de terceros o los suyos

La lista continúa con muchos otros defectos de implementación cruciales y reconocidos . Obviamente, en el mundo de la implementación corporativa surgieron estos problemas con mayor frecuencia, y ha resultado en el negocio del " reempaquetado de aplicaciones ", donde se captura un instalador heredado con tecnologías de escaneo de disco y registro para crear un archivo MSI que cumpla con los estándares para una implementación confiable.

El reempaquetado de aplicaciones es un trabajo especializado y, en general, genera archivos MSI de excelente calidad si lo hacen personas bien informadas, pero no es posible reempaquetar todas las aplicaciones debido a la compleja lógica de registro que debe ejecutarse de manera interactiva para que ciertas aplicaciones funcionen.

Beneficios de MSI - Resumen breve

En lenguaje sencillo, los beneficios realmente importantes de MSI son (sin ningún orden en particular):

• 1) la desinstalación siempre está disponible para todos los paquetes, a menos que esté deshabilitada activamente
• 2) esto es lo mismo para el registro , que es excelente y estandarizado, aunque detallado (herramientas como WiLogUtl.exe pueden usarse para analizar los archivos de registro)
• 3) lo que hace un archivo MSI es (semi) transparente o "inspeccionable" en su mayor parte. La excepción son las acciones personalizadas (consulte la sección de transparencia a continuación)
• 4) la personalización de la configuración se realiza de forma estandarizada ( transformaciones )
• 5) no hay necesidad de meterse con derechos de administrador temporales ya que la instalación se ejecuta a través de anuncios de Active Directory, políticas de grupo o administración remota. Algunas calificaciones aquí. Vea también esta captura de pantalla del editor de objetos de política de grupo.
• 6) la instalación / desinstalación silenciosa a través de herramientas de administración o usando msiexec.exe funciona bien
• 7) hay soporte completo de reversión para instalaciones fallidas. Si instala manualmente en la caja , debe conocer algunas calificaciones .
• 8) el archivo MSI se presta tanto a la inspección como a la validación para garantizar la coherencia y la validez lógica, ya que se ajustan a un esquema de base de datos ( ver ejemplo de validación )
• 9) las actualizaciones son tipos estandarizados, aunque complejos y con frecuencia propensos a errores para empaquetadores sin experiencia
• 10) la extracción de archivos del msi es una característica incorporada (consulte el artículo vinculado para obtener una buena descripción general rápida)
• 11) la línea de comandos de Windows Installer, msiexec.exe , presenta un control muy detallado de cómo se debe realizar la secuencia de instalación, y todas las opciones funcionan con todos los archivos MSI que cumplen con los estándares (establecer nivel de registro, ejecutar silenciosamente / interactivamente / semi-silenciosamente , establecer parámetros de instalación, aplicar transformaciones, etc ...).
• 12) fusionar módulos es el mecanismo MSI para entregar archivos compartidos con múltiples paquetes MSI. Es un módulo consumible o paquete de lógica de instalación que se puede combinar con cualquier paquete MSI en tiempo de compilación. Wix ha ampliado y mejorado este concepto con el uso de archivos de inclusión de Wix, un concepto que en mi opinión es superior a la combinación de módulos, especialmente para sus propios archivos (es decir, no archivos del sistema operativo)
• 13) el motor del instalador de Windows cuenta con un mecanismo para evitar sobrescribir archivos versionados o modificados en la instalación. Esto está controlado por una lógica de reemplazo de archivos bastante compleja . Aunque eficiente y buena, la lógica puede terminar siendo un problema en sí mismo, ya que muchos desarrolladores enfrentan el problema de no poder sobrescribir sus archivos de configuración modificados al actualizar. La solución a estos problemas generalmente son cambios menores en el diseño de la aplicación para evitar patrones de implementación comunes , aunque esa es una gran discusión en sí misma.

En el mundo real , he encontrado aspectos menos exitosos para incluir parches (muy complejos), MSI-GUI (características simples, bastante complejas, carece de flexibilidad), resistencia (puede causar problemas difíciles de depurar repitiendo problemas de auto reparación ) y la complejidad general de tratar con la tecnología para principiantes (la alta complejidad de las operaciones básicas a veces, por ejemplo, actualizaciones, GUI y los muchos detalles que interactúan causan resultados inesperados, etc.). La velocidad del proceso de instalación también se ha desacelerado considerablemente debido al aumento de la sobrecarga de MSI. Vea algunos consejos para mejorar la velocidad de instalación de MSI .

El resto del texto trata algunos de estos aspectos de MSI con más detalle.

Transparencia (formato de instalador abierto)

Un archivo MSI es esencialmente una base de datos SQL-Server despojada almacenada como un archivo de almacenamiento estructurado COM , esencialmente un sistema de archivos en un archivo o una colección de flujos de datos. Este es el tipo de archivo utilizado en los documentos de Microsoft Office , y produce un formato estándar que puede revisarse e inspeccionarse , un gran problema para las grandes corporaciones.

Con la excepción de las acciones personalizadas compiladas, un archivo MSI es un cuadro blanco . Si la configuración cambia algo loco, como la configuración de red de todo el sistema, puede verlo utilizando las herramientas adecuadas . La notable excepción son las acciones personalizadas compiladas , que son recuadros negros . Los requisitos del logotipo de Windows requieren que se anoten acciones personalizadas para explicar lo que están haciendo, pero los desarrolladores de configuración a menudo lo ignoran. Esperemos que la llegada de Wix mejore esto.

Para determinar qué hacen realmente esas acciones personalizadas compiladas en un sentido técnico, es necesaria una captura de configuración . Esto casi nunca se hace en mi experiencia. Es más común ponerse en contacto con el proveedor para obtener información si el software necesita aprobación para la implementación corporativa, y luego podría ser la propia aplicación la que impide su uso, y no solo la configuración.

Personalización (transformaciones)

Un MSI se puede personalizar a través de transformaciones para adaptarse a las necesidades y estándares de una organización y al mismo tiempo permitir la interoperabilidad con las actualizaciones del instalador del proveedor. No cambia el instalador en sí, crea su personalización en un archivo separado específico de la organización llamado transformación (archivo .mst) (un fragmento de base de datos o una transacción de cambio si lo desea). Puede desactivar acciones personalizadas y, en general, cambiar, anular o deshabilitar cualquier cosa en el instalador, e incluso puede agregar cosas nuevas, incluidos archivos. Los archivos de transformación también se utilizan a veces para localizar un archivo MSI a diferentes idiomas. Se pueden aplicar varias transformaciones a un solo MSI, aquí hay una muestra con rutas truncadas :

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Explicación rápida de parámetros:

/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.

Gestión e informes

Windows Installer mantiene una base de datos completa de todos los elementos que un producto ha instalado en el registro ( HKEY_CLASSES_ROOT \ Installer , ¡nunca cambie nada aquí directamente! Eso también es válido para los expertos).

Puede determinar de manera confiable si un producto está instalado, qué características se instalaron y qué versiones de archivo se instalaron. Además, puede obtener una lista de los parches que se hayan aplicado al producto base, si corresponde. Puede acceder a esta base de datos a través de las API que admiten Win32, COM o .NET utilizando una variedad de herramientas de scripting, configuración y administración como Microsoft SCCM , IBM Tivoli , CA Unicenter, etc.

Seguridad (derechos elevados temporales)

MSI también abarca los principios de "derechos elevados" que permiten a un usuario restringido activar la instalación de un producto que requiere la instalación de derechos de administrador. Esto es parte de la " función de publicidad " que permite a un administrador poner a disposición de los usuarios los instaladores sin tener que instalarlos en todas las estaciones de trabajo. El instalador en sí debe estar correctamente creado en varias cuentas principales para que este concepto de derechos elevados funcione correctamente. Los usuarios pueden activar la instalación del producto ellos mismos, o la instalación puede ser controlada por un sistema de implementación dedicado como SCCM, Tivoli, Unicenter (empresas más grandes normalmente). No es necesario meterse con derechos de administrador temporales para que todo funcione que suele ser el caso con los instaladores heredados.

La completa base de datos de instalación también garantiza que tenga una visión general completa de los parches instalados y, por lo tanto, la posibilidad de detectar vulnerabilidades de seguridad a través de herramientas de automatización y administración.

Validación

Los archivos MSI pueden verificarse con reglas de validación para garantizar que cumplan con una serie de reglas de coherencia interna (denominado ICE) Las corporaciones pueden crear sus propios controles de ICE para hacer cumplir las normas y requisitos corporativos especiales. Esto ayuda mucho con el control de calidad. La razón por la que es posible la validación se debe a la naturaleza autorreferenciada de las bases de datos relacionales y el esquema de base de datos asociado. La base de datos debe ser internamente coherente y cumplir con su propio esquema con respecto a las claves externas, los tipos de datos, el ancho de campo, la versión del esquema, etc. La validación también va más allá y es capaz de detectar defectos y errores lógicos genuinos en el paquete. , no solo formatear y escribir fallas. Por ejemplo, puede detectar archivos o tipos de archivos que se están implementando en destinos de destino erróneos.

Resiliencia (auto reparación)

La función de instalación de administrador del instalador de Windows proporciona una forma estándar de extraer los archivos fuente de un MSI ( aquí hay información adicional sobre este tema ). Estos archivos de origen se pueden poner en un recurso compartido y estar disponibles para todas las estaciones de trabajo para su instalación. Esto garantiza que las operaciones de reparación, desinstalación y modificación se completen sin solicitar los medios de instalación en CD o similar. Esto es particularmente importante para las operaciones de actualización y parches que pueden requerir acceso a los archivos fuente de las versiones anteriores en circunstancias especiales.

También hay problemas comunes con esta característica de resistencia. La mayoría de los administradores han experimentado máquinas con ciclos cíclicos de reparación automática que nunca parecen detenerse. Siga el enlace para obtener una larga lista de causas de este problema. Y nuevamente, aquí hay una versión más corta que podría ser más fácil de leer.

Retroceder

La instalación de un archivo MSI normalmente desencadenará la creación de un punto de restauración . Además, todos los archivos y elementos de registro reemplazados o sobrescritos durante la instalación se guardarán y restaurarán si la instalación no se completa, salvo los cambios realizados en acciones personalizadas.

Las acciones personalizadas deben implementar su propio soporte de reversión para el cumplimiento del logotipo de Windows. Esto a menudo se ignora, pero implica crear una segunda acción personalizada para deshacer los cambios realizados por la acción personalizada principal.

La reversión asegura que la estación de trabajo se deje en un estado estable incluso si la instalación fallara. El script de reversión real se almacena en una carpeta oculta directamente en la unidad del sistema, generalmente C: \ Config.MSI , y contiene archivos con las extensiones .RBS y .RBF - Archivos de script de reversión . Como es de esperar, los archivos MSI mal diseñados pueden violar las características integradas de Windows aquí, consulte mi otra publicación en este hilo para obtener más detalles.

Hay formas de deshabilitar la reversión y acelerar la instalación. Generalmente no se recomienda, pero aquí hay detalles sobre la propiedad MSIFASTINSTALL y DISABLEROLLBACK . Esta es una característica complicada, pero aquí hay un resumen rápido de reversión .

Parches y actualizaciones

Aunque es muy complejo, la aplicación de parches en el instalador de Windows está completamente administrada y registrada en el sistema para que se pueda determinar el estado de seguridad de los sistemas al verificar lo que se ha instalado. Las actualizaciones están estandarizadas para algunas variantes básicas, y esto permite que las actualizaciones se realicen con un mayor grado de certeza siempre que pueda manejar la complejidad involucrada. Los sistemas de implementación podrán informar qué actualizaciones fallaron y por qué.

En una vista subjetiva, el parche funciona bien para 2 usos básicos : 1 ) pequeñas revisiones para productos entregados, y 2 ) parchear un producto instalado para corregir su secuencia de desinstalación defectuosa que impide una desinstalación limpia del producto.

Un parche es solo un mecanismo de entrega para una actualización que ya está funcionando . Como tal, es solo un contenedor que es más complicado y propenso a errores que la configuración original en sí. La regla número uno para un parche es que debe ser más pequeño que el MSI original o no hay ninguna razón obvia para entregar un parche. Un parche puede ser enorme rápidamente si se dirige a múltiples versiones de productos.

Registro (detallado de hecho)

Windows Installer proporciona una característica de registro estandarizada que es muy superior a las encarnaciones anteriores, aunque casi excesivamente detallada. Los archivos de registro se pueden descifrar utilizando analizadores de registro , y se pueden usar niveles de registro personalizados para eliminar la generación de archivos de registro demasiado grandes con información innecesaria. Para fines de depuración, el registro detallado es extremadamente útil. Consulte el blog de Rob Mensching para obtener una buena forma manual de leer un archivo de registro de MSI (esencialmente busca el " valor 3 " en el archivo de registro). Aquí hay una línea de comando de muestra que realiza un registro detallado:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

Este artículo de Robert Macdonald del equipo de Windows Installer es muy recomendable como un vistazo práctico al registro de MSI: Cómo interpretar los registros de Windows Installer .

Conclusión

No todo es bueno sobre Windows Installer . Su complejidad puede ser desconcertante a veces, pero para las grandes corporaciones, los archivos MSI son muy superiores a cualquier otra forma de implementación cuando se tiene en cuenta la lista de beneficios anterior.

Nuevo paradigma de instalador (la gran instrucción SQL)

Para comprender el nuevo " paradigma ", es importante comprender que MSI pretende ser una descripción declarativa de lo que sucederá en el sistema de destino, en lugar de una secuencia fija de eventos. Supongo que puedes pensar en ello como una gran declaración SQL . Por ejemplo, declara elementos que desea agregar o modificar a un archivo INI. A medida que se ejecuta la instalación, los cambios se rastrean y la reversión está disponible para que los cambios se puedan revertir si la instalación falla. Esto realmente funciona como " automágico " y es confiable cuando se hace correctamente.

Acciones personalizadas (los sospechosos habituales)

Es un gran dolor de cabeza para los desarrolladores experimentados de MSI ver que las personas confían en acciones personalizadas complejas y poco confiables para una funcionalidad que se implementa mejor con las funciones integradas de MSI. Una parte significativa de todos los errores de MSI y problemas de reversión son causados ​​por acciones personalizadas erróneas, y la mayoría de los otros errores son causados ​​por el uso erróneo del diseño de MSI (consulte la respuesta por separado para obtener una lista de errores comunes de MSI).

Además de las características integradas de MSI, cada vez hay más funcionalidades personalizadas disponibles a través de un nuevo marco como Wix , la forma XML de compilar archivos MSI, por lo que cada vez se necesita menos lógica de acción personalizada compleja para la mayoría de las operaciones.

MSI ofrece soporte completo para manejar la fusión de configuraciones de archivos ini, fuentes, variables de entorno, claves de registro, información COM, accesos directos, extensiones de archivos, condiciones de inicio, instalación de GAC, ODBC, etc.

WIX va más allá con soporte para características muy avanzadas como extensiones de servidor SQL, instalación y configuración de IIS, contadores de rendimiento, verificación de DirectX y otras tareas relacionadas con el juego, generación de imágenes nativas .NET, COM +, controladores, reglas de firewall, extensiones de PowerShell, cierre de aplicaciones, gestión de usuarios, grupos, acciones y mucho más. Algo complicado de tratar, pero mucho más confiable que sus propias acciones personalizadas.

Evite acciones personalizadas a toda costa si es posible

Para tratar de ponerlo en perspectiva: estas incorporados y soluciones prefabricadas están hechas por el mejor despliegue de expertos disponibles , y son probados por miles, decenas de miles o tal vez incluso millones de usuarios (para una función de cosas en MSI sí mismo). ¿Realmente crees que puedes hacerlo mejor haciendo tus propias acciones personalizadas? El uso de una acción personalizada debería ser un evento raro, y debería ser absolutamente necesario para lograr algo único para el producto que instala . Y también debe escribir el soporte de reversión adecuado, lo cual es bastante complicado.

Escribir una acción personalizada casi siempre es un error , pero hay casos genuinos en los que realmente también necesitas la flexibilidad. Como siempre, es importante elegir bien tus batallas. Al principio puede ser una tarea divertida, pero es probable que enfrente muchos problemas inesperados y pierda mucho tiempo costoso. Me refiero a esto muy en serio. He escrito un conjunto de acciones personalizadas de C ++ para uso corporativo yo mismo (para eliminar acciones personalizadas de VBScript propensas a errores): no es nada fácil, y aunque la codificación puede no ser la más difícil del mundo, la depuración y las pruebas y La conexión a un archivo MSI real es extremadamente complicada. Un poco de tiempo investigando qué opciones listas para usar están disponibles probablemente le ahorrará semanas de trabajo de desarrollo y le brindará una confiabilidad de implementación mucho mayor.

Use la secuencia de inicio de la aplicación

Un punto muy importante es que se debe realizar una gran cantidad de configuraciones de aplicaciones en el inicio de la aplicación cuando tiene un contexto de tiempo de ejecución predecible y un buen manejo de errores disponible, y no en la configuración, que solo se ejecuta una vez y presenta una suplantación , secuenciación , condicionamiento y tiempo de ejecución muy complicados complejidad .

Su configuración no debe configurar la aplicación, debe preparar la aplicación para la configuración en el primer inicio . Específicamente, su configuración debe escribir todas las configuraciones que requieren derechos elevados : escribir en HKLM, registrar servicios, instalar en rutas por máquina y cualquier cosa que una aplicación no pueda escribir por sí sola con derechos de usuario normales.

Si es un desarrollador de configuración, debe ofrecer participar en la codificación de la secuencia de inicio de la aplicación en lugar de escribir acciones personalizadas de configuración . Por lo menos, para evitar parecer que está tratando de "pasar el dinero" a otra persona. En esta secuencia de lanzamiento, puede escribir un código mucho más confiable y comprobable que es más fácil de obtener ayuda del personal de control de calidad para probar (a menudo no entienden las pruebas de implementación y las pruebas de aplicaciones).

Complejidad de configuración

El núcleo de la complejidad de la configuración se centra en el hecho de que los errores son acumulativos (está administrando un proceso de entrega, no solo una compilación rápida), los errores son muy difíciles de depurar (no hay acceso a los sistemas donde ocurren los errores) y el sistema de destino Los estados difieren en casi todos los sentidos imaginables . Consulte esta respuesta para una discusión más exhaustiva de esta complejidad y cómo los sistemas de destino pueden desconfiar de una sorprendente cantidad de formas: Windows Installer y la creación de WiX, y La complejidad de la implementación (ver abajo).

WiX (la mejor solución MSI para algunos propósitos)

Lea esta introducción rápida de WiX para obtener una descripción de la nueva forma basada en XML para compilar archivos MSI. Los archivos de origen basados ​​en texto proporcionan un control de origen mucho mejor que antes. Este es un kit de herramientas gratuito y de código abierto que es muy recomendable .

NB : Vea en otra parte del hilo un resumen rápido de los problemas de diseño comunes con los archivos MSI: está muy incompleto, pero merece la pena leerlo. No quería agregar eso a esta respuesta, ya que no está 100% relacionado, pero para el uso en el mundo real es un tema crucial.

Parte de la información principal de MSI para administradores de sistemas:

(perdón por la descarada "promoción" - es para facilitar el acceso y la recuperación)

Aquí hay algunos enlaces a temas que pueden ser útiles para los administradores de sistemas en su esfuerzo por controlar la implementación en sus redes:

• ¿Cómo puedo eliminar los enormes archivos MSI en caché en C: \ Windows \ Installer? (alto uso de disco por MSI)
• Cómo acelerar las instalaciones de MSI (solo un par de opciones)
• Cómo extraer archivos de setup.exe (vale la pena leer para cualquier administrador, probablemente noticias antiguas)
• Diferentes formas de desinstalar un MSI (referencia de desinstalación, popular - gran cantidad de vistas)
• Cómo omitir msiexec.exe cuando se trata de paquetes MSI (automatización y scripts MSI)
• ¿Por qué MSI requiere el archivo .msi original para continuar con la desinstalación? (pregunta común)
• ¿Por qué hay varios procesos msiexec.exe en la lista de procesos durante la instalación? ¿Qué están haciendo todos?

Temas especiales de procedimientos:

• Forzar una actualización de un archivo que se modifica durante su instalación inicial (pregunta común)
• ¿Hay alguna forma de hacer que msiexec haga eco en stdout en lugar de iniciar sesión en un archivo (tema avanzado, uso de interfaz gráfica de usuario externa para MSI, más contenido de desarrollador)
• Quiero instalar un MSI dos veces (transformaciones de instancia o virtualizar, en serio :-)).
• Cómo actualizar cada perfil de usuario usando ActiveSetup (algo peligroso, pero útil)
• Errores comunes en paquetes MSI (más para desarrolladores, pero también para administradores de sistemas)
• Cómo depurar la reparación automática cíclica (tema importante)

Temas conceptuales / mejores prácticas:

• ¿Cuál es el beneficio y el propósito real de la instalación del programa? (conceptos básicos de implementación)
• Propósito de las instalaciones administrativas (operación principal de MSI para administradores de sistemas)
• Por qué no debe usar MSI para ajustes de registro (lectura recomendada)
• ¿Qué producto de instalación usar? (Fortalezas y debilidades de diferentes herramientas)
• Por qué el auto registro se considera perjudicial en MSI

Esta respuesta es en gran medida un trabajo en progreso y un bosquejo aproximado. Adiciones, preguntas y actualizaciones bienvenidas. Esta lista no es de ninguna manera exhaustiva. Agregue un comentario con información sobre paquetes problemáticos.

Problemas típicos y defectos de diseño vistos en paquetes MSI

También debo advertir que muchos archivos MSI contienen errores, a veces graves, pero los empaquetadores de aplicaciones capacitados podrán detectar esto y, en la mayoría de los casos, eliminar el problema. Estoy agregando esto como una respuesta separada, ya que esencialmente responde una pregunta diferente, pero siento que es relevante en el mismo hilo.

Los detalles técnicos involucrados en MSI son muy complicados . En el nivel básico, se trata de descomponer sus archivos y configuraciones de registro en componentes (instalación atómica) y características (partes de aplicación seleccionables por el usuario para instalar, por ejemplo, una función de diccionario). Hay una serie de reglas de mejores prácticas para dividir los componentes, y los errores en los archivos MSI aquí son abundantes. Estos errores generalmente se manejan estandarizando el uso de "actualizaciones importantes".

La instalación real se realiza en varias secuencias de instalación, algunas con derechos elevados . Todas estas cosas se definen en las tablas de la base de datos, y aquí es donde MSI es terriblemente complicado de entender y tratar. La distribución a lo largo de las secuencias de instalación son acciones estándar y personalizadas. Las acciones estándar están diseñadas por Microsoft y deben llevarse a cabo (la secuencia a veces se puede modificar). Las acciones personalizadas están disponibles para que los proveedores realicen una lógica personalizada que MSI no cubre. Estos pueden estar en script o en forma compilada. Las acciones personalizadas pueden ser inmediatas (ejecutarse a la vez, no deberían cambiar el sistema pero a menudo lo hacen) o diferidas (escritas en un script de ejecución que luego se ejecuta como una transacción y, por lo tanto, admite la reversión).

Los errores típicos en un MSI son (sin ningún orden en particular, y se presentan realmente como un verdadero desastre):

• errores de creación de componentes (no siguiendo las mejores prácticas) Esto puede causar problemas para parches y actualizaciones con síntomas misteriosos, como archivos y configuraciones faltantes o parches que bombardean con errores sin sentido. Para simplificar demasiado, uno debe usar un archivo por componente a menos que el número de archivos sea enorme.
• problemas de actualización relacionados con la sobreescritura o restablecimiento de los datos del usuario. Ver más detalles a continuación.
• la programación incorrecta de acciones personalizadas fuera de la "sección de transacciones" de las secuencias de instalación o las acciones personalizadas del tipo incorrecto se colocan incorrectamente. Esto a menudo hace que las acciones fallen (sin derechos elevados) cuando se ejecutan de forma remota a través de sistemas de implementación y la reversión se paraliza efectivamente porque solo las acciones transaccionadas se revierten. La transacción de Windows Installer (think commit de transacción de base de datos) se ejecuta entre las acciones estándar InstallInitialize e InstallFinalize en la secuencia de instalación principal y se ejecuta con derechos elevados . Todos los cambios en el sistema se realizarán en esta transacción; cualquier otra cosa es errónea (pero desafortunadamente bastante común).
• uso de acciones personalizadas en modo inmediato para realizar cambios en el sistema fuera de la secuencia de instalación transaccionada . Esto rompe el soporte de reversión y generalmente desencadenará errores de seguridad ya que las acciones personalizadas en modo inmediato no se ejecutan con derechos de usuario elevados, sin importar dónde se coloquen en las secuencias de instalación.
• diseños erróneos que causan ciclos repetitivos de auto reparación sin razón obvia. Aquí hay otro artículo sobre este tema, de installsite.org
• Las acciones personalizadas que no obedecen a la supresión de la GUI en el modo de instalación desatendida pueden mostrar cuadros de diálogo modales que provocan que la implementación falle por completo cuando se ejecuta de forma silenciosa. Este problema, junto con la diferencia general entre el modo silencioso y el modo interactivo, se describe con más detalle aquí (algo detallado y extenso): la desinstalación del panel de control es diferente de la eliminación de .msi
• algunas acciones personalizadas en paquetes creados erróneamente se insertan solo en la secuencia de la interfaz de usuario . Esto hace que no se ejecuten en modo de instalación silenciosa. Esto es grave para la implementación corporativa, ya que la instalación silenciosa se usa aquí casi exclusivamente. Este problema también puede afectar la desinstalación, lo que significa que es posible que deba ejecutar la desinstalación de forma interactiva para la desinstalación para garantizar que se ejecuten todas las acciones personalizadas de limpieza. Nuevamente, vea el enlace en el punto anterior para obtener una descripción más larga de los niveles de la interfaz de usuario.
• la configuración contiene archivos que no están destinados a implementarse en la ubicación en la que están instalando. Por lo general, los archivos del sistema deben instalarse uno al lado del otro en la carpeta de ensamblaje de winsxs.
• La baja velocidad de instalación es otro "problema" que muchos reportan con MSI. Aquí hay algunos consejos sobre el tema . En general, Windows Installer presenta bastante sobrecarga debido a los altos requisitos de registro en el registro de lo que se está instalando.
• sobrescritura de información personalizada o archivos de datos compartidos . Esto puede suceder si se instala un archivo INI a través de la tabla Archivo y no de la tabla IniFile, por ejemplo. En el último caso, se trata como una "transacción de cambio"; en el primer caso, es una operación de reemplazo de archivos, que generalmente es incorrecta, a menos que su archivo INI tenga un formato no estándar o secciones de comentarios grandes que desee implementar con su archivo (común para ciertos herramientas de desarrollo).
• Las reglas complejas para la sobrescritura de archivos pueden hacer que los archivos se sobrescriban involuntariamente o que no se actualicen en absoluto; este es un problema clásico de MSI. Consulte este artículo para saber cómo puede forzar la sobrescritura de un archivo que no se actualizará . Las reglas pueden modificarse ligeramente mediante configuraciones personalizadas para la propiedad REINSTALLMODE establecida en el nivel de línea de comando msiexec.exe (sobrescribir versiones anteriores, sobrescribir versiones iguales, sobrescribir cualquier versión, etc.) y funcionan de manera diferente para archivos de datos y archivos versionados. Detalles en el SDK . Comprender esto es crítico, y es un diseño a menudo mal visto incluso cuando se entiende.
• El auto registro de los archivos COM durante la instalación puede activar advertencias de seguridad o causar problemas de varias maneras. Consulte este artículo: el auto registro se considera perjudicial .
• Una variación en el problema de reemplazo de archivos es el caso cuando una actualización importante (que desinstala y reinstala el producto) desinstala los archivos modificados y reinstala las versiones predeterminadas. En estos casos, el contenido parece revertido o sobrescrito cuando en realidad se desinstaló primero y luego se reinstaló.
• los servicios que se ejecutan con credenciales de usuario personalizadas pueden perder sus credenciales durante los principales escenarios de actualización, así como también hacer que el archivo de configuración (parezca) vuelva al valor predeterminado (realmente se desinstalaron y reinstalaron). Solo para que conste: en mi opinión, los servicios que se ejecutan con credenciales de usuario son, en primer lugar, un defecto de diseño.
• Las propiedades públicas no se pasan correctamente del proceso del cliente al servidor, lo que impide que las acciones personalizadas se completen como se esperaba. Esto implica actualizar la propiedad SecureCustomActionProperties.
• Algunas aplicaciones no pueden ejecutarse correctamente para otros usuarios que el que instaló la configuración originalmente. Este es un error grave de diseño, pero generalmente puede ser solucionado por empaquetadores de aplicaciones experimentados que utilizan la recuperación automática o ActiveSetup para agregar claves de registro HKCU y archivos de perfil de usuario . Este es un tema bastante complejo y puede requerir un poco de arte negro para funcionar. Para el registro: la solución real, en mi opinión, es cambiar la aplicación en sí para poder inicializar todas las configuraciones por usuario en función de la configuración predeterminada y las plantillas copiadas desde una ubicación por máquina o en función de los valores predeterminados internos de la aplicación (desde código fuente).
• Algunos archivos MSI confunden la seguridad de los archivos instalados al establecer derechos de lectura / escritura completos para los no administradores aquí, allá y en todas partes. Otras veces, la aplicación deja de funcionar en versiones más nuevas de Windows debido a la falta de permisos. Los empaquetadores de aplicaciones enfrentan el análisis de las necesidades de permisos personalizados de una aplicación con bastante frecuencia. Por lo general, se requieren algunos permisos adicionales en HKLM o en algún lugar de% ProgramFiles%
• Algunos Installshield volver configuraciones en el día intentaría conectarse a Internet durante la instalación. Esto es horrible para los escenarios de implementación corporativos donde la implementación está estrictamente controlada, y el instalador nunca podrá descargar contenido nuevo directamente de Internet.
• Otro problema de red es cuando las configuraciones intentan mostrar una GUI donde las personas ingresan datos que se validan a través de Internet mientras se instalan, o simplemente para mostrar contenido en vivo desde su sitio web. Normalmente se trata de direcciones de correo electrónico, información de contacto, claves de licencia y demás. La conexión puede fallar completamente por muchas razones, a menudo debido a la falta de configuración de proxy en entornos corporativos (no hay conexión directa a Internet, todo el tráfico de Internet se enruta a través de un servidor de caché específico y cada proceso debe proporcionar credenciales para atravesar el firewall) . Aquí hay un artículo sobre los peligros de validar licencias a través de la configuración .
• Installshield solía instalar un tiempo de ejecución para su lenguaje Installscript . Esta configuración de requisitos previos generalmente se incluía en setup.exe, y era una fuente legendaria de problemas . Hubo muchas versiones, varias incompatibilidades y una serie de errores de tiempo de ejecución . Desde la versión 12 (o por ahí), este tiempo de ejecución ahora está instalado de manera confiable, y se está compilando en modo sandbox nativo o en ejecución (no estoy seguro de cuál, uno u otro, probablemente sandboxed) de manera confiable. Sin embargo, las configuraciones antiguas de Installshield pueden mostrar este problema de implementación. Hay un sitio de soporte heredado de Installshield para problemas como estos: http://consumer.installshield.com/common.asp
• Varias configuraciones pueden mostrar un comportamiento de instalación errático o errores intermitentes cuando se ejecuta en máquinas configuradas para idiomas diferentes al inglés, o incluso cuando ejecuta versiones localizadas (traducidas) de configuraciones en máquinas en inglés. Esto puede ser simplemente un error de tiempo de ejecución, o casos en los que los cuadros de diálogo localizados presentan texto cortado o formato erróneo o traducción defectuosa o muchos otros tipos de errores relacionados con la localización del idioma- un área completa de experiencia por sí sola (traducir texto en imágenes, traducir el software en sí, traducir material de marketing, atender solicitudes de soporte internacional, adaptación a la configuración del idioma en el sistema operativo, etc.). Algunos idiomas necesitan que se cambie toda la aplicación para tener en cuenta sus peculiaridades de idioma: los problemas típicos son las macros de cadena y la configuración de la página de códigos, siendo este último un problema menor con la introducción de Unicode. Vea una captura de pantalla de muestra de una herramienta de traducción .
• Casi todas las configuraciones fallan en varias de las pruebas de validación incorporadas que están disponibles para probar la calidad de los paquetes MSI. Vea este artículo para un ejemplo práctico de validación.
• A veces, las actualizaciones fallan para un MSI debido al hecho de que solo 3 dígitos del número de versión del MSI en realidad se verifican durante los escaneos de actualización principales.
• La instalación de archivos INI es una característica incorporada de Windows Installer. Las entradas se pueden agregar, eliminar, fusionar o tratar de cualquier manera requerida. Sin embargo, es bastante común que los archivos INI se instalen como un archivo en lugar de como valores segmentados. Esto puede hacer que el archivo INI se sobrescriba durante la reinstalación, en lugar de actualizarse. Un problema muy común de MSI.
• El problema anterior también es el caso de las aplicaciones .NET y sus archivos Config.xml. En este caso, MSI NO tiene una forma integrada de actualizar el contenido de manera detallada, y debe codificar la actualización mediante una acción personalizada o reemplazar todo el archivo en la instalación. Wix puede tener nuevas características para esto, pero el motor de Windows Installer no tiene esto incorporado.

Hay una serie de errores más sutiles y varios problemas más grandes y típicos que habré olvidado.

Consulte el artículo sobre las mejores prácticas de Windows Installer de MSDN .

El uso de MSI también facilita la aplicación de parches (archivos MSP) y las actualizaciones. Los MSI utilizan el concepto de códigos únicos de productos y actualizaciones que facilitan todo el proceso.

Algunos sistemas de implementación (CA Unicenter Software Delivery es un ejemplo) también pueden entender los MSI de una manera especial, lo que les permite integrarse mucho mejor en el sistema de implementación. Por ejemplo, puede alimentar un MSI en la biblioteca de software del sistema de implementación y detectará automáticamente las diversas características dentro del producto y permitirá automáticamente acciones personalizadas mucho más granulares (Instalación local, Verificación, Reparación, etc.) y el registro.

La autocuración / reparación también es una ventaja importante para los MSI.

Además, consulte el código abierto de Windows Installer XML , "un conjunto de herramientas que crea paquetes de instalación de Windows a partir del código fuente XML. El conjunto de herramientas admite un entorno de línea de comandos que los desarrolladores pueden integrar en sus procesos de compilación para crear paquetes de configuración MSI y MSM". MS lo utiliza para preparar varios de sus principales paquetes de software.

puede hacer transformaciones; en teoría, puede personalizar mucho, si el proveedor empaquetó el programa correctamente, puede realizar una implementación totalmente automatizada sin ninguna interacción con el usuario final, lo cual es muy útil cuando desea estandarizar su entorno de Windows y tener más de un puñado de computadoras.

para ver qué hacen las personas con msis [o implementación desatendida] visite, por ejemplo, este sitio y sus foros.