Dipendenze in MS Installer/Wix

Question

Attualmente sto imparando i capricci del WiX e dell'installer di Windows e ho trovato un ostacolo.

Il progetto che sto attualmente pacchettizzando è composto da sei blocchi discreti. Per ora chiamiamoli A, B, C, D, E, e F.

Chunk A è un insieme di librerie e utilità comuni che vengono utilizzate da ogni altro progetto. Non presenta alcuna funzionalità per l'utente finale.

Chunk B è un altro insieme di librerie e utilità comuni che richiedono funzionalità fornite da Chunk A. Questo sembra strano, ma l'architettura è oltre la mia capacità di influenzare o controllare.

Chunk C è un terzo set di librerie e utilità comuni che richiedono funzionalità fornite dai blocchi A e B. Questo sembra ancora più strano di prima, ma non ho ancora alcuna possibilità di modificarlo.

Pezzi D, E e F, tutti richiedono le funzionalità fornite da blocchi A, B, e C.

Se possibile, vorrei fare in modo che ci sia una sola installazione di blocchi A, B e C, condivisi tra le installazioni di D, E e F. Mi è stata data la certezza che i pezzi A, B e C manterranno API stabili in modo che possano essere aggiornati senza interrompere la funzionalità di D, E , o F.

Il mio pensiero immediato è quello di creare moduli di unione per i componenti in A, B e C, quindi fare riferimento a loro nelle funzionalità fornite dagli installatori separati per D, E, e F. Questo sarebbe gonfiare gli installatori, ma garantirebbe che th I componenti necessari sono installati. Sfortunatamente, temo che causerebbe problemi nella convalida di Windows Installer durante l'aggiornamento.

Un altro pensiero che ho avuto è stato quello di creare un singolo programma di installazione per A, B e C e richiederlo nei programmi di installazione per D, E e F tramite ComponentSearch.

Un'idea ha senso? Se nessuna idea ha senso, hai qualche raccomandazione per un modo corretto di farlo?

Answer 1

Includere A + B + C con ogni programma di installazione e installare nei file comuni. Windows Installer gestirà il conteggio dei riferimenti in modo che sul disco rimanga una sola copia e rimanga fino alla rimozione dell'ultimo prodotto. L'aggiornamento andrà bene, Windows Installer è stato progettato per questo genere di cose :)

Tuttavia, invece di moduli unione, io suggerisco di usare Wixlibs

Answer 2

Mi è stato dato l'assicurazione che pezzi A, B, e C manterrà stabili API in modo che possano essere aggiornati senza rompere la funzionalità di D, e, F. enter code here o

A stab le API potrebbero non essere sufficienti. Cosa succede se un'applicazione si basa accidentalmente su un comportamento che è una coincidenza non documentata (come l'ordine degli elementi in una lista restituita) o, peggio, su un comportamento che è in realtà un bug? Un aggiornamento dei componenti condivisi può quindi interrompere l'applicazione perché non è stata testata rispetto ai componenti aggiornati.

Il mio pensiero immediato è quello di creare moduli unione ...Temo che sarebbe causare problemi all'interno della convalida Installatore Windows durante l'aggiornamento.

È possibile che ci siano problemi di servizio con i moduli unione. Microsoft non distribuisce più i nuovi moduli di unione. È anche notoriamente difficile creare componenti aggiornabili e seguire ancora lo Windows Installer Component Rules.

Preferisco installare i componenti "condivisi" nella cartella bin di ogni applicazione separatamente. Creo wixlibs per questi componenti, in modo che possano essere condivisi tra i programmi di installazione dell'applicazione. All'interno dei file wixlib, ho inserito il componente in un <DirectoryRef Id="SharedComponentFolder>. Questo riferimento alla directory non è definito, il che non è un problema per lit.exe. Nei installazione di applicazioni, ho poi alias nella cartella dell'applicazione bin come questo:

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

Di conseguenza, le applicazioni hanno le loro dipendenze nella propria cartella bin e rimangono isolati gli uni dagli altri. Naturalmente c'è un compromesso:

• si ottiene stabilità perché l'applicazione viene sempre eseguita rispetto alla versione esatta delle dipendenze su cui è stata eseguita la verifica; no problemi DLL Hell.
• si ha più lavoro quando un componente condiviso viene aggiornato; ciascun programma di installazione dell'applicazione deve essere aggiornato a , anziché un solo programma di installazione per il componente condiviso.
• si perde spazio su disco (poiché i componenti condivisi sono installati più volte ).

Con assembly .NET, la storia può diventare ancora più complicato con il GAC, strong names, policy file redirects ecc Ma questo post è già in esecuzione troppo a lungo :-)