¿Cuál es la mejor práctica de generación de componentes MSI?

Question

Visual Studio Installer indica que es una mejor práctica instalar cada archivo como un componente de instalador. La utilidad de calor provista con Wix también parece seguir la práctica de poner cada archivo en su propio componente.

El asistente de componentes de InstallShield utiliza la mejor práctica de configuración de InstallShield para colocar archivos ejecutables portátiles en sus propios componentes pero agrupa todos los demás archivos (por ejemplo, archivos no versionados) por la carpeta de destino común.

La ventaja de practicar uno (cada archivo en su propio componente) es que cada archivo se configura como un archivo de clave que es importante si desea que estos archivos desencadenen reparaciones. También permite la automatización de la creación de los componentes (por ejemplo, calor) más fácil ya que está creando un componente para cada archivo.

Las desventajas de la práctica incluyen la sobrecarga de gestionar tantos componentes y la hinchazón del registro después de que se instala la aplicación.

Se puede ver una ventaja de la práctica 2 en una instalación que instala cientos de archivos de gráficos en un directorio. Si no le importa la funcionalidad de reparación, ¿hay alguna razón para crear cientos de componentes para esta instalación?

Estas 2 prácticas diferentes son contradictorias y quiero saber cuál usa realmente la gente y por qué.

Answer 1

siempre uso el enfoque de Microsoft (algo similar a lo que hace InstallShield): http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx

Creo que es el mejor porque: - archivos importantes (EXE, DLL, etc.) tienen su propio componente, por lo que puede ser reparado fácilmente - archivos de recursos se agrupan - permite un conteo de componentes óptimos (no demasiados para conseguir un tiempo de instalación, pero lo suficiente como para permitir una reparación fácil)

también he notado que la mayoría de las herramientas de creación de configuración comercial usa este enfoque

Answer 2

He escrito sobre esto en el pasado y voy a tratar de encontrar un enlace a él. Creo que ya entiendes la pregunta y es hora de que decidas qué es importante para ti.

Para mí, trabajo en instalaciones con más de 15,000 archivos y solo realizamos reparaciones importantes. Para "Program Executables" seguimos los principios 1: 1 (una necesidad para COM, Servicios, ShortCuts y demás) pero para los archivos de contenido/datos realmente hacemos un 1 a muchos sin un enfoque de archivo clave para reducir nuestro número de componentes. Claro, eso significa que no seremos capaces de crear un MSP que brinde servicios solo a uno o dos archivos de contenido aquí y allá, pero para nuestras necesidades de negocios eso simplemente no es importante para nosotros.

Resilency era una palabra de 4 letras para nosotros, así que tener menos archivos de claves nos hace más felices de todos modos. :-) Por cierto, VDPROJ también hace que cada clave de registro sea un archivo clave de su propio componente y eso fue muy doloroso para nosotros, ya que desencadenamos reparaciones innecesarias.

Dejando esto de lado, para cualquiera que no entienda completamente todo esto, me quedaré con el patrón 1: 1 hasta que encuentre una situación en la que ya no quiere y comprenderá el impacto de hacer esa elección.