Come evitare difetti di progettazione comuni nella mia soluzione di distribuzione WiX / MSI?

Come evitare difetti di progettazione comuni nella mia soluzione di distribuzione WiX / MSI?


La distribuzione è una parte cruciale della maggior parte dello sviluppo: la mancata implementazione significa che il tuo utente finale non potrà mai valutare il tuo prodotto. Questo potrebbe facilmente essere l’errore più costoso da fare nello sviluppo del software . Si prega di dare a questo contenuto una possibilità. Sono fermamente convinto che la qualità del software possa essere drasticamente migliorata da piccoli cambiamenti nella progettazione delle applicazioni per rendere l’implementazione più logica e più affidabile. Questa è la “risposta”, ovvero lo sviluppo del software .


Questa è una domanda in stile Q / A con una risposta che elenca solo alcune cose da non fare nel file MSI per evitare i difetti di progettazione più comuni.

Anti-pattern di distribuzione WiX / MSI

Esistono diversi anti-pattern di implementazione spesso visti nei file WiX / MSI . Di seguito è riportato un abbozzo di alcuni dei più comuni.

D’altra parte, prima di affrontare i problemi, ecco un rapido promemoria delle cose che hanno reso MSI un successo generale! (nonostante i suoi problemi).

Questa risposta è un work in progress

Cosa sai, ho raggiunto la dimensione massima per la risposta. Suppongo che sia un suggerimento già abbastanza :-). Alcune sezioni hanno bisogno di chiarimenti e miglioramenti.

Se riconosci alcuni di questi problemi, potresti voler continuare a leggere : questi sono tutti noti crimini e fastidi dello sviluppatore con Windows Installer / MSI:

  • Non è ansible sovrascrivere in modo affidabile un file di versione inferiore con la configurazione più recente.
  • Non è ansible sovrascrivere in modo affidabile i file senza versione (ad esempio per IIS).
  • I file sono misteriosamente mancanti dopo aver provato a installare un aggiornamento MSI.
  • I dati vengono cancellati durante gli (principali) scenari di aggiornamento. Esempi inclusi:
    • La chiave di licenza memorizzata del registro .
    • Dati nei file di configurazione come config.xml, settings.ini, ecc …
    • Le credenziali del servizio per il servizio che non vengono eseguite come LocalSystem.
  • I dati non vengono aggiornati :
    • I file delle impostazioni non vengono aggiornati in modo affidabile durante l’installazione con le nuove impostazioni che si desidera applicare.
    • Problemi durante l’aggiornamento delle impostazioni nei file di dati memorizzati per utente (o HKCU). Si aggiorna per l’utente che installa, come si aggiorna per gli altri utenti?
  • Per il tuo pacchetto vedi un calcio di auto-riparazione inaspettatamente .
  • La tua azione personalizzata rende il setup bomba con errori misteriosi.
  • E questo è un grosso problema: usi inutilmente azioni personalizzate per cose che sono già pienamente supportate dallo stesso Windows Installer. Si tratta di un enorme anti-pattern di implementazione e la principale causa di errori di distribuzione.
    • Si installa Servizi Windows tramite azioni personalizzate . Questo è molto meglio fatto nello stesso MSI usando costrutti incorporati.
    • Si installa assembly .NET al GAC tramite un’azione personalizzata . Questo è pienamente supportato da Windows Installer stesso senza una riga di codice (rischioso).
    • Esegui le classi di installazione dell’Assembly .NET personalizzate . Questi devono essere usati solo per lo sviluppo e il test. Non dovrebbero mai essere eseguiti come parte della distribuzione. Piuttosto il tuo MSI dovrebbe usare costrutti integrati per distribuire e registrare il tuo assembly.
    • Esegui le impostazioni dei prerequisiti e i programmi di installazione runtime tramite un’azione personalizzata nel tuo MSI . Questo dovrebbe essere fatto in modo completamente diverso. Vedi la sezione 6.
  • Hai problemi nella distribuzione di file runtime condivisi .
  • L’installazione silenziosa dell’MSI sembra avere come risultato uno stato di installazione diverso rispetto all’installazione intertriggers.

Le sezioni seguenti non sono in alcun ordine particolare – a partire da ora.

Le sezioni sono continuamente ricercate per essere migliorate. Si prega di aggiungere commenti su ciò che non è chiaro o utile.

In attesa di aggiunta :

  • La disinstallazione non funziona per l’applicazione MSI – Errore 1722
    • Controllo del servizio : imansible interrompere i servizi prima della disinstallazione
    • Disinstallare CA : cercare di eseguire file batch / script che non sono più su disco durante la disinstallazione
    • Azioni personalizzate : condizionamento errato in modo che l’azione personalizzata venga eseguita in modo imprevisto. Spesso durante la disinstallazione o durante gli aggiornamenti principali.

1. Problemi di autoriparazione

Un problema particolarmente fastidioso è legato ai costrutti che spesso triggersno l’auto-riparazione indesiderata per l’applicazione installata.

  • A causa della natura multiforms di questo problema, ho creato una risposta separata per descrivere i costrutti di progettazione da evitare al fine di evitare che l’auto-riparazione colpisca senza preavviso e intenti per l’applicazione: Come evitare l’triggerszione dell’autoriparazione MSI con il mio pacchetto WiX / MSI? .

  • A volte l’autoriparazione viene utilizzata come metodo per popolare HKCU con le impostazioni dell’applicazione o per inserire file nel profilo utente di ciascun utente. Questo in genere funziona, ma a mio avviso non è la migliore prassi per la progettazione e l’implementazione delle applicazioni: vedere più dettagli di seguito nella sezione 9.

2. Installazione errata di file runtime condivisi, del fornitore o di Microsoft

Sebbene questo sia ampiamente spiegato nel link sopra (problemi di autoriparazione), va notato anche qui che uno degli errori più comuni in qualsiasi setup è l’inclusione di “copie locali” di file runtime condivisi – a volte anche globalmente registrati sul sistema se si tratta di file COM. I programmi di installazione per le vecchie applicazioni VB6 talvolta lo facevano per i controlli comuni richiesti, interrompendo il sistema per altre applicazioni.

  • Se è necessaria una versione particolare di un file condiviso per COM, e non è ansible aggiornare la propria applicazione per utilizzare il componente condiviso correttamente installato, è ansible utilizzare COM senza registrazione. In pratica, l’installazione delle copie locali dei binari è necessaria e impone il loro caricamento su file condivisi tramite file manifest forniti per i binari.

  • Vedere il collegamento relativo ai problemi di autoriparazione nell’articolo 1 sopra per ulteriori dettagli su questo argomento.

3. Gestione errata di file e dati condivisi (propri)

Se crei una suite di file MSI per distribuire prodotti diversi, potrebbero condividere determinati file tra di loro. Se si sceglie lo stesso percorso di file (percorso assoluto) da diversi file MSI, ognuno utilizzando un GUID del componente diverso, ogni installazione tratterà il file come se fosse “proprietario”, disinstallandolo felicemente alla disinstallazione o rimettendolo a posto tramite riparazione automatica.

  • La soluzione corretta per questo è capire che per ogni percorso assoluto scelto, ci deve essere un GUID a componente singolo. I percorsi assoluti sono conteggiati da un GUID del componente e devono essere condivisi tra tutte le impostazioni affinché funzioni correttamente.

  • Per ottenere l’utilizzo dello stesso componente GUID in tutte le configurazioni, è necessario creare un modulo unione da includere in ogni configurazione o utilizzare costrutti avanzati in WiX come “include file”, con GUID con codifica rigida per i componenti in essi contenuti.

  • Se il file in questione è un file di dati che non dovrebbe mai essere disinstallato o sostituito una volta aggiornato, si dovrebbe anche considerare di installarlo come “componente permanente” in modo che non venga disinstallato durante gli aggiornamenti principali o le disinstallazioni eseguite manualmente.

4. Errori di creazione dei componenti – non seguendo le migliori pratiche

Non seguire le migliori pratiche per la creazione di componenti. I componenti MSI sono le unità di installazione di base per i file e le impostazioni del registro.

  • Esistono regole di best practice su come “comporre” i file dell’applicazione. La violazione di queste regole può causare problemi di patch e aggiornamenti con sintomi misteriosi quali file mancanti e impostazioni dopo gli aggiornamenti o patch che bombardano con errori privi di senso.

  • Per ovviare a questo problema, la semplificazione eccessiva è che dovresti usare un file per componente a meno che il numero di file nella tua configurazione sia veramente enorme. Questo evita ogni tipo di problema (leggi questo link per una spiegazione più approfondita del conteggio dei componenti).

5. Aggiorna i problemi relativi ai dati dell’utente che vengono sovrascritti o ripristinati

Questo non è meno che estremamente comune . Ho risposto a diverse domande StackOverflow su questo argomento, e continua a venire.

  • Leggere la sezione chiamata ” Uso eccessivo del file per utente e della distribuzione del Registro di sistema ” per una descrizione di come ridurre al minimo la dipendenza da Windows Installer per l’implementazione dei dati utente in generale. Se me lo chiedi, questa è la vera risposta a questi persistenti problemi di “reversione dei dati”.

  • Poiché gli aggiornamenti sono complessi in MSI, molti standardizzano su aggiornamenti importanti (la forma più semplice di aggiornamento). Un aggiornamento importante è essenzialmente una disinstallazione e una reinstallazione dello stesso prodotto (in diverse versioni).

  • Esistono diversi modi per configurare un aggiornamento così importante, ma se si disinstalla completamente la versione precedente prima di installare la nuova versione, è ansible disinstallare i file di dati utente che sono stati modificati dal momento dell’installazione . MSI non controlla se i file di dati sono stati modificati dopo l’installazione e li disinstallerà felicemente senza esitazione, a meno che non abbia contrassegnato il componente di hosting come ” permanente ” (non verrà mai disinstallato) o impostato un GUID del componente vuoto per il componente di hosting (a funzione speciale per installare il file e quindi ignorarlo completamente).

  • Un caso particolare da tenere presente è che anche se si condivide correttamente tale file utilizzando un modulo di unione o un file di inclusione WiX (per mantenere stabile il GUID del componente di installazione), sarà probabilmente disinstallato e reinstallato da un aggiornamento principale se è solo un prodotto sulla scatola a cui è stato fatto riferimento in quel momento (il conteggio dei riferimenti è 1).
  • Una volta completato l’aggiornamento principale, sembra che i file di dati siano stati sovrascritti o ripristinati, ma in realtà i file di dati modificati sono stati semplicemente disinstallati e reinstallati nelle loro “nuove versioni” (verranno aggiornati con alcune potenziali correzioni a breve) .

  • A mio parere, è necessario installare solo i file di dati che vengono utilizzati in sola lettura dopo l’installazione. Se i file devono essere scritti, dovrebbero essere generati dall’applicazione stessa a mio avviso e memorizzati nel profilo utente. Questo è un esempio di come la progettazione delle applicazioni può essere modificata per rendere l’implementazione più affidabile. La “vera soluzione” secondo me.

  • Se si installa il file di dati di lettura / scrittura con un componente, impostarlo come permanente (o utilizzare GUID vuoto). Le regole di sovrascrittura dei file assicureranno che il file sul disco non venga sovrascritto durante l’installazione (a meno che non si esegua qualcosa di stupido, come l’impostazione di REINSTALLMODE su amus per forzare la sovrascrittura di tutti i file – non dovrebbe mai essere consentito. così come – Hell vecchio stile DLL). Se si desidera cancellare il file e sovrascriverlo, è anche ansible utilizzare vari metodi, il migliore dei quali è probabilmente quello di utilizzare un file companion. (ulteriori dettagli saranno aggiunti in seguito).
  • Wix: talvolta il servizio Windows viene disinstallato durante l’aggiornamento

6. Uso errato o non necessario di azioni personalizzate

L’uso (eccessivo) delle azioni personalizzate per i file MSI è un argomento enorme e questa sezione è diventata troppo ampia ed è stata suddivisa in una risposta separata: perché è una buona idea limitare l’uso di azioni personalizzate nelle mie configurazioni WiX / MSI? .

Le azioni essenzialmente personalizzate non sono spesso necessarie a causa del supporto integrato in MSI per ottenere lo stesso effetto o la disponibilità di soluzioni pronte all’uso in framework gratuiti come WiX o strumenti commerciali come Advanced Installer o Installshield.

E le azioni personalizzate sono per loro natura prone di errori e la causa principale di errori ed errori di distribuzione. Si prega di leggere il link sopra per i dettagli. Migliaia di persone, decine di migliaia di persone, persino milioni di persone hanno testato questi costrutti integrati. Perché mai lo fai da solo?

Alcuni “besserwissing” (consiglio che dovrei seguire me stesso): concentrati su ciò che distingue il tuo prodotto – ciò che è nuovo su di esso ed elimina tutte le altre fonti di errori . Una buona implementazione non renderà il tuo prodotto, ma una ctriggers implementazione può infrangerlo.

7. Mancata fusione dei file INI

È ansible installare un file INI tramite la tabella File, come faresti con qualsiasi altro file. Ciò non consente l’unione se esiste un file INI esistente nella posizione di destinazione.

  • Se si importano le voci INI nelle tabelle MSI appropriate, è ansible aggiornare un file INI esistente utilizzando “unione” con valori esistenti, e non limitarsi a sovrascrivere un file “cancellando” le voci esistenti o non aggiornando affatto il file.

  • “INI merging” è “auto-magic” che consente il corretto supporto per il rollback e aggiornamenti “pin-point” dei valori in qualsiasi file INI esistente. Se il programma di installazione viene interrotto, il file INI viene correttamente ripristinato allo stato iniziale.

  • Questa è una funzione eccellente che funziona davvero alla grande per quasi tutti i file INI che abbia mai visto. Tuttavia, ho visto alcuni casi in cui i file INI hanno una formattazione non standard. A volte hanno sezioni di commenti di grandi dimensioni che si desidera installare (strumenti per sviluppatori) o formattazioni strane che non possono essere supportate dalla fusione di MSI (file tripla delimitati da virgole e cose del genere). In questi casi è necessario installarlo come file anziché come “modifica transazione” per conservare il file INI formattato in modo univoco.

  • Se si sta sviluppando e si utilizza un file INI non standard, è consigliabile assegnare al file un’estensione diversa da * .INI per indicare la sua univocità e la necessità di una gestione speciale. In realtà non è più un file INI (formato valore-chiave). È vero anche il contrario: si ha un’estensione unica e si può cambiarla in INI per gestirla come un vero file INI se il contenuto del file è coppie chiave-valore.

8. Utilizzo errato della registrazione automatica per i file COM

Oppure installa la loro registrazione tramite la tabella del registro. Utilizzare le tabelle pubblicitarie COM appropriate. Ci sono molte ragioni, come spiegato qui: Autoregistrazione considerata dannosa .

  • Ho visto casi in cui l’autoregistrazione esegue altre azioni rispetto alla reale registrazione COM sul sistema in questione. Questo è generalmente un disegno orribile da parte dello sviluppatore in questione, ma conosco casi in cui le persone hanno scelto di utilizzare l’auto-registrazione piuttosto che ri-implementare ciò che viene fatto durante l’autoregistrazione come azione personalizzata appropriata.

  • Per consentire un’opinione personale: quando vedo che le impostazioni di rete sono influenzate dall’auto-registrazione, voglio immediatamente che il software venga rifiutato per l’uso. Questo è quanto è serio fare qualcosa di così “hacky” in un’operazione standardizzata come l’autoregistrazione. La domanda saggia da porsi è “che altro fanno a causa di quella scomoda registrazione COM”. Non è solo un costruttore di fiducia a fare affidamento su cose non standard e hacky.

9. Uso eccessivo di file per utente e distribuzione del registro

AGGIORNAMENTO : nuova risposta relativa a questo argomento: Crea cartella e file su Profilo utente corrente, da Profilo amministratore .

Questa sezione è diventata troppo grande ed è stata divisa in una risposta separata: perché è una buona idea limitare la distribuzione di file al profilo utente o HKCU quando si utilizza MSI?

La distribuzione di file o impostazioni in HKCU in modo essenzialmente utente è tollerabile, ma potrebbe non essere la soluzione migliore e può essere complicata per garantire che tutte le impostazioni e i file vengano inseriti in ogni registro utente e registro utente sulla scatola. I problemi di distribuzione che risultano e alcune soluzioni proposte sono discussi nella risposta collegata sopra.

In sostanza, la distribuzione degli utenti può essere supportata mediante l’auto-riparazione MSI, l’installazione di Microsoft Active o le modifiche logiche di progettazione all’applicazione o alla soluzione in questione (l’opzione preferita: vedere la risposta collegata per i dettagli). In generale, la distribuzione non deve interferire con i dati e le impostazioni dell’utente poiché si tratta di dati utente reali e non deve essere distribuito, ma generato in fase di runtime dall’applicazione.

10. L’ installazione silenziosa non riesce a completare o è incompleta

Una funzionalità integrata di Windows Installer è che qualsiasi file MSI può essere installato in modalità silenziosa. Questa è una caratteristica fondamentale della tecnologia intesa ad aiutare la distribuzione aziendale, che generalmente viene sempre eseguita in modalità silenziosa. Assicurarsi che il tuo MSI sia in grado di completare e funzionare correttamente dopo un’installazione invisibile, non è meno che estremamente importante . Nella mia esperienza, le azioni personalizzate possono spesso causare problemi per l’installazione invisibile.

  • Non apportare mai modifiche al computer da InstallUISequence (dalle windows di dialogo di installazione). Questo problema è stato descritto sopra. Le azioni personalizzate utilizzate nella GUI intertriggers sono modalità immediata (senza elevazione per utenti regolari) e dovrebbero solo raccogliere e convalidare l’input dell’utente (sola lettura). Tutte le modifiche non standard apportate al computer devono essere eseguite tra InstallInitialize e InstallFinalize in InstallExecuteSequence: le operazioni transate e con privilegi elevati in cui è ansible eseguire solo la modalità differita e le azioni personalizzate elevate.

    • Tutte le modifiche apportate a InstallUISequence verranno ignorate interamente quando si esegue in modalità silenziosa e l’installazione risulterà probabilmente incompleta. L’installazione silenziosa è estremamente importante per la distribuzione aziendale: la GUI viene generalmente ignorata e le modifiche vengono applicate utilizzando le trasformazioni e / o impostando le proprietà dalla riga di comando.

    • Ecco una lunga discussione su come installazioni e disinstallazioni silenziose e interattive possono produrre risultati diversi (e come si tratta di un difetto di progettazione MSI grave): la disinstallazione dal Pannello di controllo è diversa da Rimuovi da .msi

  • Non mostrare mai le windows di dialogo all’interno delle azioni personalizzate in InstallExecuteSequence . Ciò potrebbe causare il fallimento dell’installazione non riuscita poiché queste windows di dialogo non eseguiranno automaticamente l’impostazione UILevel dell’installazione in esecuzione. Quando l’installazione viene eseguita in modalità silenziosa tramite i sistemi di distribuzione, è ansible visualizzare una finestra di dialogo modale e bloccare il completamento della configurazione, e non ci sarà alcun utente a chiudere la finestra di dialogo, ovviamente. È ansible utilizzare la proprietà UILevel per determinare se l’installazione viene eseguita automaticamente e quindi sopprimere la visualizzazione della finestra di dialogo, ma mostrare una finestra di dialogo come questa è solo una progettazione errata.

11. Si tenta di “forzare la sovrascrittura” di file con il programma di installazione MSI

MSI presenta alcune ” regole di controllo delle versioni dei file ” piuttosto complesse progettate per minimizzare l’impatto di ” Hell inferno “. In genere, i file non vengono sovrascritti come previsto, un classico problema MSI. Di conseguenza, le persone sentono di non riuscire a trovare un modo affidabile per forzare sempre la sovrascrittura dei file su disco durante l’installazione.

  • Ci sono modi per forzare i file di sovrascrittura, ma non nel modo in cui la maggior parte delle persone si presenta come logica. Francamente il design di sostituzione dei file è spesso disapprovato anche se capito.

  • La sovrascrittura dei file funziona in modo molto diverso per file con versioni e file di dati (testo, immagini, qualsiasi cosa senza proprietà di versione). In sostanza, i file con versioni più elevate sovrascrivono i file delle versioni inferiori quando i file sono versionati. I file di dati non vengono sostituiti se le date di creazione e modifica sono diverse per il file in questione. È stato quindi modificato da quando è stato installato.

  • Il comportamento di sovrascrittura dei file può essere leggermente modificato dalle impostazioni personalizzate per il set di proprietà REINSTALLMODE al livello della riga di comando msiexec.exe (sovrascrivere versioni precedenti, sovrascrivere versioni uguali, sovrascrivere qualsiasi versione ecc …). L’impostazione della proprietà REINSTALLMODE modifica la logica di sostituzione dei file per tutti i file dell’intero processo, inclusi i file distribuiti con moduli di unione che potrebbero indirizzare i file in percorsi condivisi. È quindi ansible eseguire il downgrade di file e componenti condivisi, esattamente a proposito di “DLL Hell”.

  • Tuttavia è fondamentale comprendere le “regole di sovrascrittura dei file” e il modo in cui possono essere influenzate dalle impostazioni, ma è un’impostazione che si applica a tutti i file dell’intera installazione. Ci sono anche alcuni “hack” per sovrascrivere solo i file specifici.

  • Controlla questo articolo per sapere come forzare la sovrascrittura di un file che non verrà aggiornato .

  • Questa sezione non è ancora finita.

12. Si installano servizi eseguiti con credenziali utente

A mio avviso, questa non è una buona pratica, e in genere la gente cancella le credenziali durante i principali scenari di aggiornamento e, in alcuni casi, anche i file delle impostazioni utilizzati dal servizio.

  • Per me questo è un primo esempio di come sono necessarie modifiche al design delle applicazioni per rendere l’implementazione affidabile e sana.

  • Nella mia esperienza, le persone insistono nell’usare queste soluzioni e finiscono con un sacco di azioni di hacking personalizzate per farlo funzionare.

  • Risparmia un sacco di problemi e progetta il tuo servizio per l’esecuzione come LocalSystem ( o forse meglio – un altro account che è inteso per l’utilizzo del servizio) – fai una rapida lettura di questo contenuto collegato e parla con il tuo team di sviluppo delle opzioni. potrebbe valere un errore: è sicuro eseguire un pool con NT AUTHORITY \ NETWORK SERVICE? ).

  • Vedere la sezione successiva sui privilegi NT per un problema comune riscontrato quando si utilizzano le credenziali dell’utente per eseguire un servizio.

  • AGGIORNAMENTO : dovrebbe essere menzionato anche il nuovo concetto di account di servizio gestito . Passo dopo passo ( vedi anche la sezione in questa risposta sugli account di servizio gestiti e di gruppo ).

13. La tua applicazione richiede ampi privilegi NT personalizzati

I privilegi NT sono diversi dal controllo di accesso discrezionale (controllo degli accessi di file system e oggetti di registro) e includono elementi come SeServiceLogonRight “accesso come servizio” (che deve essere impostato per qualsiasi account utente che tenta di eseguire un servizio – una configurazione molto comune problema per le impostazioni che cercano di eseguire servizi con credenziali utente).

In alcuni casi è richiesta una pletora di tali privilegi per eseguire un’applicazione o più probabilmente un servizio. Un “odore di dispiegamento” molto forte o in realtà un “odore di soluzione” – un anti-modello, se mai ce ne fosse uno.

Quasi tutti questi privilegi sono pericolosi da dissipare .

  • Suppongo che SeSystemtimePrivilege – l’impostazione del tempo di sistema non sia troppo critica – almeno al valore nominale, ma in realtà non vedo alcun privilegio totalmente innocuo e, a parte l’accesso al servizio sopra menzionato, pochi dovrebbero essere sempre necessari.

  • Nella mia esperienza i privilegi richiesti tendono a ruotare attorno a ” Logon User Rights “. SeNetworkLogonRight (computer di accesso dalla rete), SeInteractiveLogonRight (accesso locale), SeBatchLogonRight (accesso come processo batch) e il più grande: SeServiceLogonRight (accedere come servizio).

  • Alcuni privilegi NT come SeAssignPrimaryTokenPrivilege , SeBackupPrivilege , SeDebugPrivilege , SeIncreaseQuotaPrivilege , SeTchPrivilege (agiscono come parte del sistema operativo) e molti altri non dovrebbero mai essere applicati da alcun pacchetto sano .

  • L’account LocalSystem destinato all’esecuzione di servizi ha la maggior parte dei privilegi (compresi quelli pericolosi) e deve essere utilizzato per eseguire la soluzione anziché creare un account utente separato e assegnarvi tali privilegi. Seriamente .

  • Ecco una bella ” lista raggruppata di privilegi NT ” che fornisce un ulteriore contesto per capire a cosa serve ciascun privilegio e in che modo sono correlati.

14. Si applicano molte autorizzazioni personalizzate su disco e registro

Si tratta di un preciso “odore di dispiegamento” o di dispiegamento “anti-pattern”. In quasi tutti i casi questo può essere evitato ridisegnando l’applicazione in questione.

  • L’applicazione delle autorizzazioni personalizzate è stata tradizionalmente eseguita utilizzando vari strumenti da riga di comando. Ci sono anche funzionalità incorporate in MSI per fare ciò, ma non hanno la flessibilità.

  • Con l’avvento di WiX, l’applicazione delle autorizzazioni è ora relativamente affidabile perché è una soluzione testata in modo appropriato realizzata da sviluppatori che comprendono MSI. Gli strumenti commerciali supportano ovviamente anche le autorizzazioni personalizzate.

  • A mio parere, le autorizzazioni personalizzate sono ancora un segno che qualcosa non funziona nel software che si sta installando, ma ho applicato anche molte autorizzazioni personalizzate.

  • Ho visto spesso problemi ripetitivi di autoriparazione causati da autorizzazioni errate applicate al disco o al registro: come evitare l’triggerszione dell’autoriparazione MSI con il mio pacchetto WiX / MSI? (sezione 5).

  • Ho anche visto diversi casi in cui le autorizzazioni errate applicate creano una situazione in cui la disinstallazione diventa imansible senza qualche modifica seria alle autorizzazioni ACL fallite. Lavoro molto nodoso e molto facile da aggravare provando a distribuire e correggere automaticamente.

  • Un altro problema ovvio è il rischio per la sicurezza che si presenta aprendo l’accesso in scrittura ai percorsi per macchina sulla macchina.

15. La chiave di licenza nel registro viene ripristinata all’aggiornamento

Un disegno molto comune è scrivere una chiave di licenza nel registro usando un componente MSI. Questo può essere HKCU o più spesso HKLM – al fine di renderlo una licenza condivisa per tutti gli utenti sullo stesso computer.

Se si utilizza una proprietà pubblica MSI per impostare questa chiave di licenza, è necessario leggere questo valore su una nuova installazione per assicurarsi di non sovrascrivere i dati esistenti con una stringa vuota. Le proprietà pubbliche MSI sono (sorprendentemente) non persistono e vengono automaticamente rilette dalla configurazione di aggiornamento nei principali scenari di aggiornamento. Dimenticare di farlo è una causa molto comune di persone che vedono la propria chiave di licenza cancellata durante l’aggiornamento principale.

Raramente, se non mai, consiglio di leggere / scrivere azioni personalizzate. Sono soggetti a errori e possono essere complessi per avere ragione – e la maggior parte delle persone non implementa correttamente il rollback (se l’installazione si interrompe e deve essere ripristinata). Tuttavia, hai anche più potere di controllare lo “stato attuale” del sistema con un’azione personalizzata, e puoi condizionare l’azione personalizzata in modo che funzioni sempre, anche durante la sequenza di patch, e puoi farlo fare cose diverse durante sequenze diverse se devi. La maggior parte delle volte può effettivamente essere un problema se le azioni personalizzate vengono eseguite quando non sono previste, ad esempio durante l’installazione di una patch. Poche persone si ricordano di condizionare la loro azione personalizzata con NOT PATCH (per impedire l’esecuzione durante il patching).

Nonostante tutto ciò, potrei semplicemente usare un’azione personalizzata per scrivere una chiave di licenza su HKLM durante l’installazione se mi viene richiesto di scrivere la licenza durante l’installazione. Tuttavia, e questo è importante, vorrei piuttosto rimuovere l’intero problema di licenza dal setup del tutto , per molte ragioni qui descritte: Installer con registrazione online per l’applicazione Windows (lettura consigliata – ci sono molti motivi per mantenere le licenze fuori del tuo setup).

16. GUID con hard coding indesiderati

Alcuni GUID possono essere codificati nel file sorgente WiX (o in altri strumenti di creazione MSI). Ad esempio GUID del componente: dovrebbero rimanere stabili per ciascun componente, a meno che non si cambi il percorso di installazione. Il fondamento logico per questo è stato tentato qui: Modifica il mio componente GUID in wix?

Tuttavia, non codificare il codice del pacchetto . Il codice del pacchetto di MSI dovrebbe sempre essere generato automaticamente per ogni build. Dovrebbe semplicemente essere unico. Più in dettaglio; l’idea di un GUID del pacchetto è che dovrebbe essere univoco per ogni file MSI compilato. È semplicemente lì per identificare univocamente un file. Due file MSI diversi con lo stesso pacchetto GUID verranno trattati da Windows Installer come lo stesso file per definizione. Ne derivano tutti i tipi di problemi con i file X. Di conseguenza, un GUID del pacchetto dovrebbe sempre essere generato automaticamente in quanto dovrebbe semplicemente essere unico.

Molti inoltre generano automaticamente il codice prodotto , poiché utilizzano solo aggiornamenti importanti per aggiornare le proprie applicazioni. Per questo i codici prodotto generati automaticamente del caso d’uso funzionano bene. Tuttavia, se è necessario supportare anche gli aggiornamenti secondari di Windows Installer, è necessario codificare a fondo il codice prodotto e aggiornarlo quando appropriato. Il codice di aggiornamento dovrebbe generalmente essere hardcoded e gestito manualmente. Vedi questa risposta

17. Inclusione errata di dati sensibili

Esiste ora un Q / A separato sul tema della prevenzione dei dati sensibili che finiscono nell’installer finale: come evitare di distribuire informazioni sensibili nel mio MSI per caso?

Fondamentalmente il consiglio è di dare ai tuoi file una volta sola per i peccati di dev-box hard codificati . Come controllare ? Non mi diverto, apro l’MSI con Orca – e sfoglio i tavoli . Le tabelle più vulnerabili sono probabilmente: Registry , Property , IniFile , forse Directory e se si utilizza la GUI MSI: all tables relating to GUI . Qualsiasi script (tabella CustomAction o tabella Binary , quest’ultimo che richiede di eseguire lo streaming di qualsiasi script o di controllarli nelle posizioni di origine).