Dependencias en MS Installer/Wix

Question

Actualmente estoy aprendiendo los caprichos del instalador de WiX y Windows y he topado con un obstáculo.

El proyecto que estoy empacando actualmente se compone de seis trozos discretos. Por ahora vamos a llamarlos A, B, C, D, E y F.

El fragmento A es un conjunto de bibliotecas y utilidades comunes que se utilizan en cualquier otro proyecto. No presenta ninguna funcionalidad de usuario final.

El trozo B es otro conjunto de bibliotecas y utilidades comunes que requieren funcionalidad proporcionada por el trozo A. Esto parece extraño, pero la arquitectura está más allá de mi capacidad de influenciar o controlar.

El trozo C es un tercer conjunto de bibliotecas y utilidades comunes que requieren funcionalidad proporcionada por los trozos A y B. Esto parece aún más extraño que antes, pero todavía no tengo la capacidad de cambiar esto.

Trozos D, E, y F, todos requieren la funcionalidad proporcionada por trozos A, B, y C.

Si es posible, me gustaría asegurarse de que sólo hay una instalación de trozos A, B y C, que se comparten a través de las instalaciones de D, E y F. Se me ha asegurado que los fragmentos A, B y C retendrán API estables para que puedan actualizarse sin romper la funcionalidad de D, E o F.

Mi idea inmediata es crear módulos de fusión para los componentes en A, B y C, y luego hacer referencia a ellos en las características proporcionadas por los instaladores separados para D, E y F. Esto se hincha los instaladores, pero garantizaría que Los componentes necesarios están instalados. Lamentablemente, me temo que podría causar problemas dentro de la validación de Windows Installer al realizar la actualización.

Otra idea que tuve fue crear un único instalador para A, B y C y requerirlo en los instaladores para D, E y F a través de ComponentSearch.

¿Alguna idea tiene sentido? Si ninguna idea tiene sentido, ¿tiene alguna recomendación para una forma correcta de hacerlo?

Answer 1

Incluya A + B + C con cada instalador e instálelos en archivos comunes. Windows Installer manejará el recuento de referencias para que solo exista una copia en el disco y permanezca hasta que se elimine el último producto. La actualización estará bien, instalador de Windows está diseñado para este tipo de cosas :)

Sin embargo, en lugar de Módulos de combinación, se sugiere emplear Wixlibs

Answer 2

Se me ha dado la seguridad de que trozos A, B, y C retendrá APIs estables para que puedan ser actualizados sin romper la funcionalidad de D, e, enter code here o F.

Una puñalada le API puede no ser suficiente. ¿Qué ocurre si una aplicación se basa accidentalmente en un comportamiento que es una coincidencia no documentada (como el orden de los elementos en una lista devuelta) o, lo que es peor, en un comportamiento que en realidad es un error? Una actualización de los componentes compartidos puede romper su aplicación porque no fue probada contra los componentes actualizados.

Mi pensamiento inmediato es crear fusionar módulos ...Me temo que podría causar problemas dentro de Windows Validación del instalador al realizar la actualización.

Es posible que tenga problemas de mantenimiento con los módulos de combinación. Microsoft ya no distribuye nuevos módulos de combinación. También es notoriamente difícil crear componentes actualizables y seguir el Windows Installer Component Rules.

Prefiero instalar los componentes "compartidos" en la carpeta bin de cada aplicación por separado. Creo wixlibs para estos componentes, para que puedan ser compartidos entre los instaladores de la aplicación. Dentro de los archivos wixlib, puse el componente en un <DirectoryRef Id="SharedComponentFolder>. Esta referencia de directorio no está definida, lo cual no es un problema para lit.exe. En los instaladores de aplicaciones, que a continuación, alias la carpeta bin aplicación como esta:

<Directory Id="AppBinFolder" Name="bin"> 
    <Directory Id="SharedComponent1Folder" /> <!-- alias for AppBinFolder --> 
    <Directory Id="SharedComponent2Folder" /> <!-- another alias --> 
</Directory> 

Como resultado, las aplicaciones tienen sus dependencias en su propia carpeta bin y permanecen aislados unos de otros. Existe una compensación, por supuesto:

• gana estabilidad porque su aplicación siempre se ejecuta contra la versión exacta de las dependencias contra las que se prueba; no DLL Hell problemas.
• tiene más trabajo cuando se actualiza un componente compartido; cada instalador de la aplicación debe estar actualizado y redistribuido, en lugar de solo un instalador para el componente compartido.
• pierde espacio en disco (porque los componentes compartidos están instalados varias veces ).

Con ensamblados .NET, la historia puede llegar a ser aún más complicado con el GAC, strong names, policy file redirects etc, pero este post ya está funcionando demasiado tiempo :-)