MSI vs paquetes nuget: ¿cuál es mejor para la entrega continua?

Discutamos el siguiente tema. Existe una aplicación que se está implementando actualmente con un buen método para conocer el xcopy. Este enfoque hace que sea difícil administrar las dependencias, las actualizaciones de archivos, etc. Existe la idea de iniciar la implementación de aplicaciones con la ayuda de algunos paquetes, como hace en Linux con la ayuda de RPM , pero para Windows.

Así que tengo una pregunta: ¿qué sistema de paquete es mejor usar en windows classic windows installer ( msi ) o nuget o algo más?

MSI es el estándar de aplicación corporativa aceptado. Tiene algunos beneficios corporativos importantes en comparación con las técnicas de implementación heredadas. WiX es la nueva forma de código abierto para crear archivos MSI.

  • Descargar Wix Toolset .
  • Para familiarizarse con Wix , es posible que desee leer un resumen rápido y no oficial de la historia que lo respalda .
  • Entonces es posible que desee verificar otras formas de entregar un instalador, además de Wix, leyendo: ¿Qué producto de instalación usar? InstallShield, WiX, Wise, Advanced Installer, etc. ( una lista más de herramientas ).
  • Finalmente, vea un ejemplo completo de cómo se ve un archivo fuente Wix y sus componentes en CodeProject . Este es el “Hola mundo” de Wix.

Algunos buenos enlaces iniciales para aprender Wix:

  • Mis sugerencias de inicio rápido de Wix
  • Buenos recursos para aprender a crear instaladores MSI de WiX
  • ¿Cómo implementar la actualización del instalador de WiX? (actualización principal)
  • ¿Cuáles son las limitaciones de WiX y WiX Toolset?

Extraiga los archivos de Setup.exe WiX Bundle o de un archivo MSI:

  • Extraiga MSI de EXE , incluida la forma de extraer los archivos incrustados en un ejecutable del paquete WiX Burn.
  • ¿Cómo puedo comparar el contenido de dos (o más) archivos MSI? – Incluyendo cómo extraer archivos de un MSI utilizando la herramienta dark.exe de WiX

Como escribí en mi post sugerida ” Inicio rápido de Wix ” arriba: Wix es práctico . Solo concéntrese en muestras simples, pero completas del mundo real, como la de Codeproject ; leer la documentación sola es probable que sea meramente confusa .

Concéntrese en dividir su aplicación en componentes y configurar una actualización importante. Utilice un archivo por componente como regla general , y lea esta respuesta para una mejor comprensión de la creación de componentes: ¿ Cambiar mi GUID de componente en wix?

Una actualización importante es el mecanismo de actualización más utilizado para el software implementado (el otro tipo de actualización común es la actualización menor). Obviamente, es crucial que pueda actualizar lo que ya implementó. Obtenga escenarios de actualización que funcionen antes de implementar su primera versión de software para que tenga confianza en su solución de implementación.

Una vez que haya configurado los componentes y la solución de actualización esté funcionando, el rest de las piezas encajarán en su lugar a medida que avance en los requisitos de implementación de la aplicación y busque ejemplos en el sitio del tutorial de Wix : https: //www.firegiant. com / wix / tutorial / .

Para aquellos que escriben código Wix directamente (sin un editor de GUI), sugiero que comprueben esta respuesta para mantener la coherencia de los archivos de origen: ¿ Sintaxis para las guías en WIX?

Lea más:

  • Windows Installer y la creación de WiX
  • Capacidades del instalador, WIX vs InstallShield Express
  • Installshield o Wix

Estoy yendo por este camino ahora, donde he heredado el software usando MSI / WiX para el instalador, pero estoy mirando convertir nuestro proceso a entrega continua y eliminando las actualizaciones que se instalan sin la interacción del cliente. Creo que es incorrecto numerar el nuget hole como una herramienta de SDK, en esencia, es una herramienta para implementar conjuntos de archivos versionados. Además, si el software que está implementando ya responde en gran medida a nuget, y ya está empaquetando sus ensamblajes en paquetes nuget para uso interno, ¿por qué agregar tecnología adicional a la mezcla por el simple hecho de hacerlo? empaquete un nuget.exe en su msi, realice una actualización de llamadas periódicamente, listo.

Sé que WiX admite la creación de parches, pero parece que es una idea de último momento. Además, ¿qué sucede si su parche falla la instalación? ¿Instalando parches fuera de servicio? Su instalador principal requiere permisos de UAC, mientras que su parche no?

Creo que los tiempos están cambiando, y MSI representa una forma más antigua de pensar sobre las cosas. Chocolatey es un buen ejemplo, pero aún se encuentra en una etapa híbrida, mezclando ambas tecnologías.

MSI es más como tirar – obtienes un paquete, luego lo instalas. Nuget es más como una estratagem de empuje: obtienes el nombre de un paquete, lo instalas, luego periódicamente puedes llamar a la actualización y se descarga e instala una nueva versión.