Quali sono i vantaggi dell'utilizzo dei file .msi rispetto ai normali file setup.exe?
Ho l'impressione che la distribuzione sia più semplice su macchine in cui gli utenti dispongono di poche autorizzazioni, ma non sono sicuro dei dettagli.
Quali caratteristiche ha msiexec.exe che rende la distribuzione più semplice rispetto all'utilizzo degli scenari setup.exe?
Suggerimenti o trucchi durante la distribuzione di applicazioni .msi?
Risposte:
Solo alcuni vantaggi:
Penso a quando sto distribuendo software in un ambiente aziendale: distribuire software tramite MSI è quasi divertente. Al contrario, mi trovo quasi sempre a temere di distribuire software quando si trova in un altro contenitore.
Per alcune informazioni aggiuntive sulla manipolazione delle installazioni MSI, digitare msiexecnella finestra di dialogo Esegui.
AGGIORNAMENTO, luglio 2018 : un riepilogo estremamente compresso delle informazioni seguenti è disponibile su StackOverflow: i principali vantaggi dell'MSI ( "executive summary"- di sorta).
Ho lavorato nello sviluppo come responsabile del rilascio , ingegnere di costruzione , sviluppatore di installazione e come impacchettatore di applicazioni e ingegnere di distribuzione in grandi aziende.
Questa è una recensione delle migliori (e peggiori) caratteristiche concettuali e reali dell'MSI. I problemi di progettazione più comuni riscontrati nei file MSI sono presentati come una risposta separata di seguito . Non pretendere di essere completo - in realtà solo una "confusione di cervelli" disordinata - intesa come "quella roba che non si trova nei libri" (probabilmente per una buona ragione).
Vorrei anche suggerire questo articolo MSDN come una buona lettura: Windows Installer: vantaggi e implementazione per gli amministratori di sistema .
In una parola, MSI riguarda la standardizzazione e la gestione degli " odori di distribuzione " delle tecnologie di installazione legacy. Un'intera raccolta di cattivi progetti di architettura di installazione che hanno causato ripetuti problemi di distribuzione.
Nel complesso MSI fornisce un framework completo e standardizzato per l'installatore, che include anche le funzionalità di disinstallazione e integrate e le opzioni per l' esecuzione silenziosa con la GUI standardizzata che può essere attivata da remoto .
Queste funzionalità da sole costituiscono un enorme miglioramento rispetto alle precedenti tecnologie di installazione che trattavano la disinstallazione e l'esecuzione silenziosa a casaccio - forse le funzionalità più importanti per l'implementazione aziendale insieme alla gestione affidabile dei pacchetti remoti tramite Active Directory o strumenti di amministrazione remota dedicati come Microsoft SCCM (precedentemente SMS), IBM Tivoli , CA Unicenter e simili.
Qualcuno ha duplicato una versione precedente di questa risposta . Forse una lettura più veloce?
MSI scoraggia attivamente gli odori della distribuzione legacy in base alla progettazione. Questi argomenti sono discussi nelle sezioni successive di seguito, ma come elenco rapido i problemi più riconoscibili con gli installatori legacy e la tecnologia di distribuzione precedente erano:
L'elenco continua con molti altri difetti di distribuzione cruciali e riconosciuti . Ovviamente è stato nel mondo della distribuzione aziendale che questi problemi sono emersi più spesso e ha portato al business del " reimballaggio dell'applicazione " in cui un installatore legacy viene catturato con tecnologie di scansione del disco e del registro al fine di creare un file MSI conforme agli standard per una distribuzione affidabile.
Il riconfezionamento delle applicazioni è un lavoro specialistico e generalmente genera file MSI di qualità eccellente se eseguiti da persone competenti, ma non è possibile riconfezionare tutte le applicazioni a causa della complessa logica di registrazione che deve essere eseguita in modo interattivo affinché determinate applicazioni funzionino.
In parole povere i vantaggi davvero importanti dell'MSI sono (in nessun ordine particolare):
Nel mondo reale ho trovato aspetti meno riusciti tra cui patching (molto complesso), MSI-GUI (funzionalità semplici, abbastanza complesse, prive di flessibilità), resilienza (può causare il debug difficile da ripetere ripetendo problemi di auto-riparazione ) e la complessità complessiva di gestire la tecnologia per i principianti (elevata complessità delle operazioni di base a volte - ad esempio aggiornamenti, GUI e i numerosi dettagli interagenti causano risultati imprevisti ecc ...). La velocità del processo di installazione ha anche rallentato notevolmente a causa del maggiore sovraccarico di MSI. Consulta alcuni suggerimenti per migliorare la velocità di installazione di MSI .
Il resto del testo tratta alcuni di questi aspetti dell'MSI in modo più dettagliato.
Un file MSI è essenzialmente un database SQL Server Server ridotto come un file di archiviazione strutturato COM, essenzialmente un file system in un file o una raccolta di flussi di dati. Questo è il tipo di file utilizzato nei documenti di Microsoft Office e produce un formato standard che può essere rivisto e ispezionato , un grosso problema per le grandi aziende.
Ad eccezione delle azioni personalizzate compilate, un file MSI è una casella bianca . Se l'installazione cambia qualcosa di folle come le impostazioni di rete a livello di sistema, puoi effettivamente vederlo utilizzando gli strumenti appropriati . L'eccezione notevole sono le azioni personalizzate compilate, che sono scatola nera . I requisiti del logo di Windows richiedono che le azioni personalizzate vengano annotate per spiegare cosa stanno facendo, ma questo viene spesso ignorato dagli sviluppatori dell'installazione. Spero che l'avvento di Wix migliorerà questo.
Per determinare cosa fanno effettivamente tali azioni personalizzate compilate in senso tecnico, è necessaria un'acquisizione di installazione . Questo non è quasi mai stato fatto nella mia esperienza. È più comune contattare il fornitore per informazioni se il software necessita dell'approvazione per l'implementazione aziendale e quindi potrebbe essere l'applicazione stessa a impedirne l'uso e non solo l'installazione.
Un MSI può essere personalizzato tramite trasformazioni per adattarsi alle esigenze e agli standard di un'organizzazione, pur consentendo l'interoperabilità con gli aggiornamenti del programma di installazione del fornitore. Non si modifica il programma di installazione stesso, si crea la personalizzazione in un file separato e specifico dell'organizzazione chiamato Transform (file .mst) (un frammento del database o modifica transazione se lo si desidera). Sei libero di disabilitare le azioni personalizzate e in generale di modificare, sovrascrivere o disabilitare qualsiasi cosa nel programma di installazione e puoi anche aggiungere nuove cose, inclusi i file. I file di trasformazione vengono talvolta utilizzati anche per localizzare un file MSI in diverse lingue. Diverse trasformazioni possono essere applicate a un singolo MSI, ecco un esempio con percorsi troncati :
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Spiegazione rapida dei parametri:
/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Windows Installer mantiene un database completo di tutti gli elementi che un prodotto ha installato nel registro ( HKEY_CLASSES_ROOT \ Installer : non modificare mai nulla qui direttamente! Lo stesso vale per gli esperti).
È possibile determinare in modo affidabile se un prodotto è installato, quali funzionalità sono state installate e quali versioni di file sono state installate. Inoltre, è possibile ottenere un elenco di eventuali patch che sono state applicate al prodotto di base, se presenti. È possibile accedere a questo database tramite API che supportano Win32, COM o .NET utilizzando una varietà di strumenti di scripting, configurazione e amministrazione come Microsoft SCCM , IBM Tivoli , CA Unicenter ecc ...
MSI comprende anche i principi dei "diritti elevati" che consentono a un utente con restrizioni di avviare l'installazione di un prodotto che richiede l'installazione dei diritti di amministratore. Questo fa parte della " funzione di annuncio " che consente a un amministratore di rendere disponibili gli installatori agli utenti senza installarli su tutte le workstation. L'installatore stesso deve essere correttamente creato su diversi account di base affinché questo concetto di diritti elevati funzioni correttamente. Gli utenti possono attivare autonomamente l'installazione del prodotto oppure l'installazione può essere controllata da un sistema di distribuzione dedicato come SCCM, Tivoli, Unicenter (normalmente le società più grandi). Non è necessario pasticciare con i diritti di amministratore temporanei per far funzionare le cose che è spesso il caso degli installatori legacy.
L'ampio database di installazione garantisce inoltre una panoramica completa delle patch installate e quindi la possibilità di rilevare vulnerabilità della sicurezza tramite strumenti di automazione e di amministrazione.
I file MSI possono essere controllati con regole di convalida per assicurarsi che sia conforme a una serie di regole di coerenza interne (denominate ICE). Le società possono creare i propri controlli ICE per applicare regole e requisiti aziendali speciali. Questo aiuta molto con il QA. Il motivo per cui la convalida è possibile è dovuto alla natura autoreferenziale dei database relazionali e allo schema del database associato. Il database deve essere internamente coerente e conforme al proprio schema per quanto riguarda le chiavi esterne, i tipi di dati, l'ampiezza del campo, la versione dello schema, ecc ... Anche la convalida va oltre questo ed è in grado di rilevare autentici difetti logici ed errori nel pacchetto , non solo formattare e digitare difetti. Ad esempio, è in grado di rilevare file o tipi di file che vengono distribuiti in destinazioni di destinazione errate.
La funzione di installazione dell'amministratore di Windows Installer fornisce un modo standard per estrarre i file di origine da un MSI ( ecco alcune informazioni aggiuntive su questo argomento ). Questi file di origine possono quindi essere inseriti in una condivisione ed essere disponibili per tutte le workstation per l'installazione. Ciò garantisce il completamento delle operazioni di riparazione, disinstallazione e modifica senza richiedere il supporto di installazione su CD o simili. Ciò è particolarmente importante per le operazioni di patching e aggiornamento che potrebbero richiedere l'accesso ai file sorgente delle vecchie versioni in circostanze speciali.
Esistono anche problemi comuni con questa funzionalità di resilienza. La maggior parte degli amministratori ha sperimentato macchine con cicli ciclici di autoriparazione che non sembrano mai fermarsi. Segui il link per un lungo elenco di cause di questo problema. E ancora, ecco una versione più breve che potrebbe essere più facile da leggere.
L'installazione di un file MSI normalmente attiverà la creazione di un punto di ripristino . Inoltre, tutti i file e gli elementi del registro sostituiti o sovrascritti durante l'installazione verranno salvati e ripristinati se l'installazione non viene completata, salvo eventuali modifiche apportate nelle azioni personalizzate.
Le azioni personalizzate devono implementare il proprio supporto di rollback per la conformità del logo Windows. Questo viene spesso ignorato, ma comporta la creazione di una seconda azione personalizzata per annullare le modifiche apportate dall'azione personalizzata principale.
Il rollback garantisce che la workstation rimanga in uno stato stabile anche se l'installazione non dovesse riuscire. Lo script di rollback effettivo viene archiviato in una cartella nascosta direttamente sull'unità di sistema, generalmente C: \ Config.MSI , e contiene file con estensione .RBS e .RBF - File di script di rollback . Come ci si potrebbe aspettare, i file MSI mal progettati possono violare le funzionalità integrate di Windows qui, vedere il mio altro post in questa discussione per maggiori dettagli.
Esistono modi per disabilitare il rollback e accelerare l'installazione. Non generalmente consigliato, ma qui ci sono dettagli sulla proprietà MSIFASTINSTALL e DISABLEROLLBACK . Questa è una funzionalità complicata, ma ecco una rapida panoramica del rollback .
Sebbene estremamente complesso, l'applicazione di patch in Windows Installer è completamente gestita e registrata sul sistema in modo che uno stato di sicurezza del sistema possa essere determinato controllando ciò che è stato installato. Gli aggiornamenti sono standardizzati in alcune varianti di base e ciò consente di eseguire gli aggiornamenti con un livello più elevato di certezza, purché tu sia in grado di gestire la complessità. I sistemi di distribuzione saranno in grado di segnalare quali aggiornamenti non sono riusciti e perché.
Dal punto di vista soggettivo, il patching funziona bene per 2 usi di base : 1 ) piccoli aggiornamenti rapidi per i prodotti consegnati e 2 ) patching di un prodotto installato per correggere la sequenza di disinstallazione difettosa che impedisce una disinstallazione pulita dei prodotti.
Una patch è solo un meccanismo di consegna per un aggiornamento che sta già funzionando . In quanto tale, è solo un contenitore che è più complicato e soggetto a errori rispetto all'impostazione originale stessa. La regola numero uno per una patch è che deve essere più piccola dell'MSI originale o non vi è alcuna ragione ovvia per consegnare una patch. Una patch può diventare enorme rapidamente se ha come target più versioni del prodotto.
Windows Installer offre una funzionalità di registrazione standardizzata che è notevolmente superiore alle precedenti incarnazioni, sebbene quasi eccessivamente dettagliata. I file di registro possono essere decifrati utilizzando gli analizzatori di registro e possono essere utilizzati livelli di registro personalizzati per eliminare la generazione di file di registro troppo grandi con informazioni non necessarie. Ai fini del debug la registrazione dettagliata è estremamente utile. Vedi il blog di Rob Mensching per un buon modo manuale per leggere un file di registro MSI (essenzialmente cerchi " valore 3 " nel file di registro). Ecco una riga di comando di esempio che esegue la registrazione dettagliata:
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
Questo articolo di Robert Macdonald del team di Windows Installer è altamente raccomandato come uno sguardo pratico alla registrazione MSI: Come interpretare i registri di Windows Installer .
Non tutto va bene con Windows Installer . La sua complessità può essere sconcertante a volte, ma per le grandi aziende i file MSI sono di gran lunga superiori a qualsiasi altra forma di distribuzione quando si prende in considerazione l'elenco dei vantaggi sopra.
Per comprendere il nuovo " paradigma " è importante capire che MSI è inteso come una descrizione dichiarativa di ciò che accadrà sul sistema di destinazione, piuttosto che una sequenza fissa di eventi. Suppongo che tu possa pensarlo come un'enorme istruzione SQL . Ad esempio, dichiari gli elementi che desideri aggiungere o modificare in un file INI. Durante l'esecuzione dell'installazione, le modifiche vengono monitorate e il rollback è disponibile in modo che le modifiche possano essere ripristinate se l'installazione non riesce. Funziona davvero come " automagic " ed è affidabile se fatto bene.
È un enorme mal di testa per gli sviluppatori MSI esperti vedere le persone fare affidamento su azioni personalizzate complesse e inaffidabili per funzionalità che è meglio implementata con le funzionalità MSI integrate. Una quota significativa di tutti gli errori MSI e i problemi di rollback sono causati da azioni personalizzate errate e la maggior parte degli altri errori sono causati da un uso errato del design MSI (vedere la risposta separata per l'elenco degli errori MSI comuni).
Oltre alle funzionalità MSI integrate, sono ora disponibili sempre più funzionalità personalizzate tramite un nuovo framework come Wix , il modo XML per compilare i file MSI, quindi c'è sempre meno bisogno di complesse logiche di azioni personalizzate per la maggior parte delle operazioni.
MSI offre il pieno supporto per la gestione della fusione di impostazioni di file ini, caratteri, variabili di ambiente, chiavi di registro, informazioni COM, collegamenti, estensioni di file, condizioni di avvio, installazione di GAC, ODBC, ecc ...
WIX va oltre con il supporto di funzionalità molto avanzate come estensioni del server SQL, installazioni e configurazione IIS, contatori delle prestazioni, controllo DirectX e altre attività correlate al gioco, generazione di immagini native .NET, COM +, driver, regole del firewall, estensioni di PowerShell, chiusura delle applicazioni, gestione di utenti, gruppi, condivisioni e molto altro. Un po 'coinvolto, ma molto più affidabile delle tue azioni personalizzate.
Per cercare di metterlo in prospettiva: queste soluzioni integrate e pronte sono realizzate dai migliori esperti di distribuzione disponibili e sono testate da migliaia, decine di migliaia o forse anche milioni di utenti (per roba integrata in MSI si). Pensi davvero di poter fare meglio facendo le tue azioni personalizzate? L'uso di un'azione personalizzata dovrebbe essere un evento raro e dovrebbe essere assolutamente necessario ottenere qualcosa di unico per il prodotto installato . E devi anche scrivere il supporto di rollback adeguato, il che è abbastanza coinvolto.
Scrivere un'azione personalizzata è quasi sempre un errore , ma ci sono casi autentici in cui anche tu hai davvero bisogno della flessibilità. Come sempre è importante scegliere bene le tue battaglie. All'inizio potrebbe essere un compito divertente, ma probabilmente dovrai affrontare molti problemi imprevisti e perdere molto tempo costoso. Lo dico molto sul serio. Ho scritto una serie di azioni personalizzate in C ++ per uso aziendale (per eliminare le azioni personalizzate VBScript soggette a errori): non è una passeggiata nel parco e, sebbene la codifica possa non essere la più difficile al mondo, il debug e i test e il collegamento a un vero file MSI è a dir poco estremamente coinvolto. Un po 'di tempo alla ricerca di quali opzioni pronte sono disponibili probabilmente ti farà risparmiare settimane di lavoro di sviluppo e produrrà un'affidabilità di implementazione molto maggiore.
Un punto molto importante è che molta configurazione dell'applicazione dovrebbe avvenire all'avvio dell'applicazione quando si dispone di un contesto di runtime prevedibile e di una buona gestione degli errori, e non nell'impostazione che viene eseguita una sola volta e presenta rappresentazione , sequenziamento , condizionamento e runtime molto complicati complessità .
La tua installazione non dovrebbe configurare l'applicazione, dovrebbe preparare l'applicazione per la configurazione al primo avvio . In particolare, l'installazione dovrebbe scrivere tutte le impostazioni che richiedono diritti elevati : scrittura su HKLM, registrazione dei servizi, installazione su percorsi per computer e qualsiasi cosa che un'applicazione non possa scrivere da sola con i diritti utente regolari.
Se sei uno sviluppatore dell'installazione, dovresti offrirti di impegnarti a codificare la sequenza di avvio dell'applicazione invece di scrivere azioni personalizzate di installazione . Se non altro, per evitare di sembrare come se stessi cercando di "passare il dollaro" a qualcun altro. In questa sequenza di lancio è possibile scrivere un codice molto più affidabile e testabile, che è più facile ottenere assistenza dal personale addetto al controllo qualità da testare (spesso non comprendono i test di distribuzione così come i test delle applicazioni).
Il nucleo della complessità dell'installazione è incentrato sul fatto che gli errori sono cumulativi (si sta gestendo un processo di consegna, non solo una rapida ricompilazione), gli errori sono molto difficili da eseguire il debug (nessun accesso ai sistemi in cui si verificano gli errori) e al sistema di destinazione gli stati differiscono in quasi tutti i modi immaginabili . Si prega di vedere questa risposta per una discussione più approfondita di questa complessità e di come i sistemi target potrebbero diffidare in un numero sconvolgente di modi: Windows Installer e la creazione di WiX e The Complexity of Deployment (vedi verso il basso).
Leggi questa rapida introduzione di WiX per una descrizione del nuovo modo basato su XML per compilare file MSI. I file di origine basati su testo forniscono un controllo del codice sorgente molto migliore rispetto a prima. Questo è un toolkit gratuito e open source altamente raccomandato .
NB : vedere altrove nel thread per una rapida panoramica dei comuni problemi di progettazione con i file MSI: è molto incompleto, ma vale la pena leggerlo. Non volevo aggiungerlo a questa risposta poiché non è correlato al 100%, ma per l'uso nel mondo reale è un argomento cruciale.
(scusate la "promozione" spudorata - è per un facile accesso e recupero)
Ecco alcuni link ad argomenti che potrebbero essere utili agli amministratori di sistema nel loro sforzo di controllare la distribuzione sulle loro reti:
Argomenti speciali:
Argomenti concettuali / Best practice:
Questa risposta è in gran parte un lavoro in corso e una struttura approssimativa. Aggiunte, domande e aggiornamenti sono benvenuti. Questo elenco non è affatto esaustivo. Aggiungi un commento con informazioni sui pacchetti problematici.
Devo anche avvertire che molti file MSI contengono errori, a volte gravi, ma i pacchetti di applicazioni addestrati saranno in grado di rilevare questo e nella maggior parte dei casi eliminare il problema. Sto aggiungendo questo come una risposta separata poiché essenzialmente risponde a una domanda diversa, ma ritengo sia rilevante nella stessa discussione.
I dettagli tecnici coinvolti nell'MSI sono molto complicati . A livello base si tratta di scomporre i file e le impostazioni del registro in componenti (installazione atomica) e funzionalità (parti dell'applicazione selezionabili dall'utente da installare, ad esempio una funzione di dizionario). Esistono numerose regole di best practice per la suddivisione dei componenti e gli errori nei file MSI qui sono numerosi. Questi errori vengono generalmente gestiti standardizzando l'uso di "aggiornamenti importanti".
L'installazione effettiva viene eseguita in diverse sequenze di installazione, alcune con diritti elevati . Tutte queste cose sono definite nelle tabelle del database, ed è qui che MSI è terribilmente complicato da capire e gestire. Diffusione nelle sequenze di installazione sono azioni standard e personalizzate. Le azioni standard sono progettate da Microsoft e devono essere eseguite (a volte la sequenza può essere modificata). Sono disponibili azioni personalizzate per i fornitori per eseguire logiche personalizzate non coperte dallo stesso MSI. Questi possono essere in forma di script o compilati. Le azioni personalizzate possono essere immediate (eseguite contemporaneamente, non devono cambiare il sistema ma spesso lo fanno) o differite (scritte in uno script di esecuzione che viene quindi eseguito come una transazione e quindi a supporto del rollback).
Gli errori tipici in un MSI sono (in nessun ordine particolare - e presentati come un vero casino):
Ci sono una serie di errori più sottili e molti problemi più grandi e tipici che avrò dimenticato.
Consulta l' articolo sulle migliori pratiche di Windows Installer da MSDN .
L'uso di MSI semplifica inoltre l'applicazione di patch (file MSP) e gli aggiornamenti. MSI utilizza il concetto di codici univoci di prodotto e aggiornamento che semplificano l'intero processo.
Alcuni sistemi di distribuzione (CA Unicenter Software Delivery è un esempio) possono anche comprendere gli MSI in un modo speciale, che consente loro di integrarsi molto meglio nel sistema di distribuzione. Ad esempio, è possibile inserire un MSI nella libreria software del sistema di distribuzione e rileverà automaticamente le varie funzionalità all'interno del prodotto e consentirà automaticamente azioni personalizzate molto più granulari (installazione locale, verifica, riparazione ecc.) E registrazione.
L'auto-cura / riparazione è anche un grande vantaggio per MSI.
Inoltre, controlla l' XML di Windows Installer open source ", un set di strumenti che crea pacchetti di installazione di Windows dal codice sorgente XML. Il set di strumenti supporta un ambiente a riga di comando che gli sviluppatori possono integrare nei loro processi di compilazione per creare pacchetti di installazione MSI e MSM". Questo viene utilizzato da MS per preparare molti dei suoi principali pacchetti software.
puoi fare trasformazioni - in teoria puoi personalizzare molto, se il programma è stato impacchettato correttamente dal fornitore puoi effettuare una distribuzione completamente automatizzata senza alcuna interazione con l'utente finale - il che è molto utile quando vuoi standardizzare il tuo ambiente Windows e avere più di una manciata di computer.
per vedere cosa fanno le persone con msis [o distribuzione automatica] visitare ad esempio questo sito e i suoi forum.