Come da oggetto, sto litigando con questa magnifica feature inclusa nei pacchetti di installazione creati con windows installer.

Di per sé la possibilità di recuperare l\'applicazione anche se l\'utente ha distrattamente cancellato alcuni componenti fondamentali è molto utile, se però fosse flessibile in base alle esigenze del programmatore.
La mia esigenza è quella di poter scegliere quali file devono essere resilient. Ho notato infatti che WI ha qualche problema di gestione dei files che non hanno un numero di versione. Su di essi, infatti, il controllo viene fatto tramite hash o data di creazione/modifica ed in base a quello viene deciso se sostituirli.

La mia app, però, maneggia in modo particolare alcuni file unversioned e questo provoca, al successivo lancio dell\'app, l\'apertura automatica del WI che ripara automaticamente l\'applicazione copiando i file originari del pacchetto... E questo non è cosa buona.

Mi sono scartebbellato tutta l\'msdn alla ricerca di un qualcosa che mi aiutasse ma ho trovato ben poco, e quel poco non funziona come dovrebbe.

L\'articolo sul quale mi sono soffermato, dopo tanto peregrinare è questo: http://support.microsoft.com/kb/290997/en-us
In esso si dice:


Bene.. mi son detto, anche se microsoft non lo raccomanda  cancello i valori di KeyPath della tabella Component per tutti i file per i quali non ho necessità di reinstallazione e dovrebbe andare.
Invece, ovviamente, no!

Non riuscendo a capire come applicare la seconda possibilità che mi viene offerta, ovvero applicare più componenti ad uno stesso file, ho deciso di postare qui nella speranza che qualcuno abbia qualche idea sul come poter raggiungere il mio scopo!!

Grazie in anticipo....

Continuo con i tentativi di autorisoluzione del problema.

Approfondendo il discorso \"componenti legati\" ho notato che ho maggiori vantaggi utilizzando il fake componente o uno reale come companion file degli altri file unversioned. In questo modo riesco a gestire anche gli aggiornamenti su di essi avendo come riferimento la versione del file di appoggio.

Pian pianino sto arrivando alla fine del tunnel, ma ancora non ci sono. Avendo trovato questi sistemi per controllare il servizio di self repair in modo migliore ora sto cominciando ad essere esigente e quindi voglio che questa feature si comporti bene.

Spiego lo scenario in cui ho ancora qualche problema:

Installo un minor upgrade del mio prodotto seguendo le indicazioni presentate sull\'MSDN ( cambio il product code, lascio gli stessi compenent id e upgradecode) che aggiorna proprio il companion file e tutti i suoi associati.
WI e l\'utility di self repair però non adotta il comportamento giusto in caso di problemi.

1) Se cancello i file associati e costringo l\'utility di self repair ad aggiustare il pacchetto essa ripara tutto tranne quei file perché giustamente nel paccheto originale il companion file ha una versione precedente.

2) Se cancello il companion file aggiornato l\'utility di self repair ripristina quello precedente.

Seguendo la logica, però, il self repair dovrebbe prendere in considerazione il fatto che i file sono stati aggiornati e ripristinarli prendendoli dall\'installer dell\'upgrade, cosa che invece non fa.

Sempre in attesa di conforto.. continuo con gli studi.

Ciao LucaTo, i miei studi ele mie soluzioni si sono fermate a questo post, nel senso che ho cercato di farmi andare bene le soluzioni che avevo trovato usando quindi i companion files..