Condividi tramite

Procedure consigliate per Windows Installer

  • Articolo

Questa sezione enumera un elenco di suggerimenti, collegati alla documentazione principale di Windows Installer SDK, per aiutare sviluppatori di applicazioni, autori di installazione, professionisti IT e sviluppatori dell'infrastruttura a individuare le procedure consigliate per l'uso di Windows Installer:

Aggiornare la versione di Windows Installer.

  • Usare Windows Installer 5.0 in Windows Server 2008 R2 e Windows 7. Questa è la versione di Windows Installer fornita con il sistema operativo.
  • Usare Windows Installer 4.5 in Windows Server 2008, Windows Server 2003 con Service Pack 1 (SP1), Windows Vista con Service Pack 1 (SP1) o Windows XP con Service Pack 2 (SP2). Per informazioni su come ottenere la versione più recente di Windows Installer, vedere Windows Installer Redistributables.
  • Usare Windows Installer 3.1 in Windows 2000 con Service Pack 3 (SP3). Windows Installer versione 3.1 include funzionalità che facilitano la manutenzione e l'applicazione di patch migliori.
  • Molte funzionalità importanti sono state introdotte con la versione 3.0 e sono elencate nella sezione Non supportata in Windows Installer versione 2.0. I pacchetti di installazione e gli aggiornamenti creati per Windows Installer 2.0 possono essere installati con Windows Installer 3.0 e versioni successive. I pacchetti patch che contengono le nuove tabelle usate da Windows Installer 3.0 possono comunque essere applicati usando versioni precedenti di Windows Installer, ma senza la funzionalità di applicazione di patch di Windows Installer 3.0. È anche possibile creare patch che richiedono esplicitamente Windows Installer 3.0 che non possono essere applicate dalle versioni precedenti di Windows Installer. Se un utente non è in grado di aggiornare la versione del programma di installazione, assicurarsi che l'applicazione o l'aggiornamento siano compatibili con un aggiornamento futuro di Windows Installer.
  • Per un elenco delle funzionalità di Windows Installer non supportate dalle versioni precedenti di Windows Installer, vedere Novità di Windows Installer.

Soddisfare i requisiti di certificazione logo Windows.

  • Anche se non intendi inviare la tua applicazione al programma logo, seguendo le linee guida per la certificazione del logo puoi migliorare il pacchetto di Windows Installer. Per una panoramica dei requisiti del logo e collegamenti a programmi di certificazione logo specifici, vedere Requisiti per Windows Installer e Logo.

Preparare il pacchetto per la localizzazione.

  • È consigliabile prepararsi per la localizzazione futura durante la creazione del pacchetto di installazione originale. È possibile seguire la procedura di localizzazione dei pacchetti suggerita in Localizzazione di un pacchetto di Windows Installer.

Aggiornare gli strumenti di sviluppo e la documentazione di Windows Installer.

  • Gli strumenti di sviluppo di Windows Installer non sono ridistribuibili ed è consigliabile usare solo le versioni di questi strumenti disponibili da Microsoft. Questi sono disponibili nei componenti di Windows SDK per sviluppatori Windows Installer in Microsoft Windows Software Development Kit (SDK).
  • Diversi fornitori di software indipendenti offrono strumenti per creare o modificare pacchetti di Windows Installer. Questi strumenti possono fornire un ambiente di creazione di pacchetti che può essere più semplice da usare rispetto agli strumenti forniti in Windows Installer SDK. Per altre informazioni su questi strumenti, vedere altre informazioni sulle risorse descritte in Altre origini delle informazioni di Windows Installer.
  • La possibilità di creare un pacchetto da file di testo può essere più intuitiva per alcuni sviluppatori. Il set di strumenti XML (WiX) di Windows Installer disponibile in Sourceforge.net compila pacchetti di installazione di Windows dal codice sorgente XML.
  • La documentazione in Windows Installer SDK viene aggiornata più frequentemente.
  • Usare la versione recente di Msizap.exe (versione 3.1.4000.2726 o successiva) disponibile nei componenti di Windows SDK per sviluppatori di Windows Installer per Windows Vista o versione successiva. Le versioni minori di Msizap.exe possono rimuovere informazioni su tutti gli aggiornamenti applicati ad altre applicazioni nel computer dell'utente. Se queste informazioni vengono rimosse, potrebbe essere necessario rimuovere e reinstallare queste altre applicazioni per ricevere aggiornamenti aggiuntivi.
  • L'editor di tabelle di database Orca.exe è un editor di tabelle di database per la creazione e la modifica di pacchetti di Windows Installer e moduli di merge. Dispone di un'interfaccia GUI di base, ma supporta la modifica avanzata dei database di Windows Installer. Anche se si usa un'altra applicazione come strumento di sviluppo principale, è possibile che l'uso di Orca.exe sia utile per la risoluzione dei problemi e il test di un pacchetto.
  • Per informazioni aggiornate su Windows Installer, vedere Altre origini di Windows Installer disponibili in blog, chat tecniche, newsgroup, articoli tecnici e siti Web.

Se si decide di creare nuovamente un pacchetto di un'applicazione di installazione legacy, seguire le procedure di repackaging consigliate.

Molti fornitori di applicazioni forniscono pacchetti nativi di Windows Installer per l'installazione o i relativi prodotti. Il software che converte un'applicazione di installazione legacy esistente in un pacchetto di Windows Installer viene definito strumento di repackaging. La ricompressione di un'applicazione di installazione esistente non è la procedura consigliata per lo sviluppo. Le applicazioni progettate fin dall'inizio per sfruttare i vantaggi delle funzionalità di Windows Installer possono essere più semplici per gli utenti per l'installazione e il servizio. Se decidi di usare un software di repackaging, le procedure seguenti possono aiutarti a produrre un pacchetto di Windows Installer migliore.

  • Gli strumenti di repackaging converte le installazioni legacy in un pacchetto di Windows Installer scattando un'immagine di un sistema di gestione temporanea prima e dopo l'installazione. Tutte le modifiche del Registro di sistema, le modifiche ai file o le impostazioni di sistema che si verificano durante il processo di acquisizione vengono incluse nell'installazione. Configurare l'hardware e il software del computer usato per ricompilazione dell'installazione il più vicino possibile al sistema dell'utente previsto. Creare un pacchetto separato per ogni configurazione hardware diversa. Eseguire nuovamente il pacchetto usando un computer di gestione temporanea pulito. Rimuovere eventuali applicazioni non necessarie. Arrestare tutti i processi non necessari. Chiudere tutti i servizi di sistema non essenziali.
  • Creare sempre una copia dell'installazione originale prima di iniziare a lavorare su di esso. Lavorare sempre sulla copia. Non arrestare mai un repackager prima di terminare la compilazione del pacchetto. Se il repackager danneggia il pacchetto, avrai comunque l'originale.
  • Non creare nuovamente pacchetti di aggiornamenti software Microsoft in un pacchetto di Windows Installer. Microsoft rilascia gli aggiornamenti software, ad esempio i Service Pack, come file autoestrainti che eseguono automaticamente l'installazione. Questi aggiornamenti usano programmi di installazione diversi rispetto a Windows Installer per sostituire le risorse di Windows protette e non possono essere convertiti in un pacchetto di Windows Installer. Per informazioni su come distribuire i Service Pack di Windows, vedere la guida alla distribuzione del Service Pack in Microsoft TechNet.
  • Non usare uno strumento di repackaging per convertire un pacchetto di Windows Installer in un nuovo pacchetto. Windows Installer aggiunge informazioni di configurazione al sistema e alle risorse dell'applicazione. Quando uno strumento di repackaging confronta il sistema prima e dopo l'installazione, il repackager interpreta erroneamente le informazioni di configurazione come parte dell'applicazione. Questo in genere danneggia l'applicazione ripacchetto. Usare invece trasformazioni di personalizzazione per modificare un pacchetto di Windows Installer esistente o creare un nuovo pacchetto. È possibile creare trasformazioni di personalizzazione usando lo strumento Msitran.exe .
  • Non usare uno strumento di repackaging per consolidare diversi pacchetti di Windows Installer in un singolo pacchetto. È invece possibile usare lo strumento Msistuff.exe per configurare l'eseguibile bootstrap Setup.exe per installare i pacchetti uno dopo l'altro.
  • Crea il pacchetto di Windows Installer in modo che possa essere facilmente personalizzato dal cliente. Le variabili globali usate da Windows Installer durante un'installazione possono essere impostate usando le proprietà pubbliche o le trasformazioni di personalizzazione. Fornire la documentazione per l'uso di tali proprietà e valori predefiniti pratici per tutti i valori personalizzabili. Per informazioni su come ottenere e impostare le proprietà, vedere Uso delle proprietà. Per un esempio di trasformazione di personalizzazione, vedere Esempio di trasformazione della personalizzazione.

Non provare a sostituire le risorse protette.

I pacchetti di Windows Installer non devono tentare di sostituire le risorse protette durante l'installazione o l'aggiornamento. Windows Installer non rimuove o sostituisce queste risorse perché Windows impedisce la sostituzione di file di sistema, cartelle e chiavi del Registro di sistema essenziali. La protezione di queste risorse impedisce errori del sistema operativo e dell'applicazione.

  • Quando si esegue in Windows Server 2008 o Windows Vista, Windows Installer ignora l'installazione di qualsiasi chiave del Registro di sistema o di file protetta da Windows Resource Protection (WRP), il programma di installazione immette un avviso nel file di log e continua con il resto dell'installazione senza errori. Per informazioni, vedere Uso di Windows Installer e Windows Resource Protection.
  • WRP è il nuovo nome per Windows File Protection (WFP). WRP protegge le chiavi e le cartelle del Registro di sistema, nonché i file di sistema essenziali. In Windows Server 2003, Windows XP e Windows 2000, quando Windows Installer ha rilevato un file protetto dal WFP, il programma di installazione richiederebbe che il WFP installi il file. Per informazioni, vedere Uso di Windows Installer e Windows Resource Protection.

Non dipendere da risorse non critiche.

L'installazione o l'aggiornamento non deve dipendere dall'installazione di risorse non critiche per i motivi seguenti.

  • Le azioni personalizzate possono avere esito negativo se dipendono da un componente appartenente a una funzionalità che l'utente annuncia anziché installare.
  • Le azioni personalizzate sequenziate prima che l'azione InstallFinalize non riesca se dipendono da un componente contenente un assembly in fase di installazione. Windows Installer non esegue il commit degli assembly nella Global Assembly Cache (GAC) fino al completamento dell'azione InstallFinalize.

Usare l'API per recuperare le informazioni di configurazione di Windows Installer.

L'installazione dell'applicazione o dell'aggiornamento non deve dipendere dall'accesso diretto alle informazioni di configurazione di Windows Installer salvate nel computer. Usare invece l'interfaccia di programmazione dell'applicazione Windows Installer per recuperare le informazioni di configurazione. Il percorso e il formato delle informazioni di configurazione vengono gestiti dal servizio Windows Installer e possono cambiare.

  • Le funzioni di installazione e configurazione dell'API di Windows Installer sono descritte in Informazioni di riferimento sulle funzioni del programma di installazione.
  • Le proprietà di configurazione sono descritte in Informazioni di riferimento sulle proprietà.
  • I metodi e le proprietà di automazione sono descritti in Riferimento all'interfaccia di automazione. Lo script di esempio WiLstPrd.vbs si connette a un oggetto Installer ed enumera i prodotti registrati e le informazioni sul prodotto. Per informazioni, vedere Elencare prodotti, proprietà, funzionalità e componenti.

Organizzare l'installazione dell'applicazione intorno ai componenti.

Il servizio Windows Installer installa o rimuove raccolte di risorse denominate componenti. Poiché i componenti sono comunemente condivisi, l'autore di un pacchetto di installazione deve seguire le regole quando si specificano i componenti di una funzionalità o di un'applicazione.

  • Rispettare le regole dei componenti quando si organizzano le applicazioni nei componenti per assicurarsi che i nuovi componenti o le nuove versioni dei componenti possano essere installati e rimossi senza danneggiare altre applicazioni. È possibile seguire la procedura descritta in Definizione dei componenti del programma di installazione.
  • Il programma di installazione tiene traccia di ogni componente in base al RISPETTIVo GUID ID componente specificato nella tabella Component. È essenziale per il funzionamento del meccanismo di conteggio dei riferimenti di Windows Installer corretto. Seguire le linee guida in Modifica del codice del componente.
  • Se il pacchetto deve interrompere le regole del componente, tenere presente le possibili conseguenze e assicurarsi che l'installazione non installi mai questi componenti in cui potrebbero danneggiare i componenti nel sistema dell'utente. Per informazioni, vedere Cosa accade se le regole del componente sono interrotte?
  • Tenere presente come Windows Installer applica le regole di controllo delle versioni dei file durante la sostituzione di file esistenti. Windows Installer determina innanzitutto se il file di chiave del componente è già installato prima di tentare di installare uno dei file del componente. Se il programma di installazione trova un file con lo stesso nome del file di chiave del componente installato nel percorso di destinazione, confronta la versione, la data e la lingua dei due file chiave e usa regole di controllo delle versioni dei file per determinare se installare il componente fornito dal pacchetto. Se il programma di installazione determina che deve sostituire la base del componente sul file di chiave, usa le regole di controllo delle versioni dei file in ogni file installato per determinare se sostituire il file.

Ridurre le dimensioni dei pacchetti di Windows Installer di grandi dimensioni.

I pacchetti Windows di grandi dimensioni accettano risorse di sistema e possono essere difficili da installare per gli utenti. È consigliabile ridurre le dimensioni dei pacchetti windows Installer di dimensioni molto grandi tramite i metodi seguenti.

  • Comprimere i file nell'installazione e archiviarli in un file cab (.cab). Il programma di installazione consente di archiviare il file .cab come file esterno separato o come flusso di dati nel pacchetto MSI stesso. Per informazioni, vedere Uso di archivi e origini compresse.
  • Rimuovere lo spazio di archiviazione sprecato nel file .msi usando una delle opzioni descritte in Riduzione delle dimensioni di un file .msi.
  • Se il pacchetto di Windows Installer contiene più di 32767 file, è necessario modificare lo schema del database. Per informazioni, vedere Creazione di un pacchetto di grandi dimensioni.

Se si usano azioni personalizzate, seguire le procedure consigliate per le azioni personalizzate.

Windows Installer include molte azioni standard predefinite per l'installazione e la manutenzione delle applicazioni. Gli sviluppatori devono tentare di basarsi sulle azioni standard quanto più pratiche, invece di creare azioni personalizzate. Tuttavia, esistono situazioni in cui lo sviluppatore di un pacchetto di installazione trova necessario scrivere un'azione personalizzata.

  • Seguire le linee guida per l'uso di azioni personalizzate.
  • Seguire le linee guida per la protezione delle azioni personalizzate. Le azioni personalizzate che usano informazioni riservate non devono scrivere queste informazioni nel log. Per informazioni, vedere Sicurezza delle azioni personalizzate.
  • Le azioni personalizzate non devono tentare di impostare un punto di ingresso ripristino di sistema dall'interno di un'azione personalizzata. Per informazioni, vedere Impostazione di un punto di ripristino da un'azione personalizzata.
  • Restituire messaggi di errore da azioni personalizzate e scriverli nel log per facilitare la risoluzione dei problemi delle azioni personalizzate. Per informazioni, vedere Azioni personalizzate del messaggio di errore e restituzione di messaggi di errore da azioni personalizzate.
  • Non modificare lo stato del sistema da un'azione personalizzata immediata. Le azioni personalizzate che modificano direttamente il sistema o chiamano un altro servizio di sistema devono essere posticipate al momento in cui viene eseguito lo script di installazione. Ogni azione personalizzata di esecuzione posticipata che modifica lo stato del sistema deve essere preceduta da un'azione personalizzata di rollback per annullare la modifica dello stato del sistema in un rollback dell'installazione. Per informazioni, vedere Modifica dello stato del sistema tramite un'azione personalizzata.
  • Le azioni personalizzate che eseguono operazioni di installazione complesse devono essere un file eseguibile o una libreria a collegamento dinamico. Limitare l'uso di azioni personalizzate in base agli script a semplici operazioni di installazione.
  • Fare in modo che i dettagli dell'azione personalizzata funzionino facilmente al sistema individuabili per gli amministratori di sistema. Inserire i dettagli delle voci e dei file del Registro di sistema usati dall'azione personalizzata in una tabella personalizzata e fare in modo che l'azione personalizzata legga da questa tabella. Questo è illustrato nell'esempio in Uso di un'azione personalizzata per creare account utente in un computer locale. Per informazioni sull'aggiunta di tabelle personalizzate a un database, vedere Uso di query ed esempi di query di database tramite SQL e script.
  • Le azioni personalizzate non devono visualizzare una finestra di dialogo. Le azioni personalizzate che richiedono un'interfaccia utente possono usare invece la funzione MsiProcessMessage. Vedi Invio di messaggi a Windows Installer tramite MsiProcessMessage.
  • Le azioni personalizzate non devono usare alcuna delle funzioni elencate nella pagina: Funzioni non per l'uso nelle azioni personalizzate.
  • Se l'installazione è destinata all'esecuzione in un server terminal, verificare che tutte le azioni personalizzate siano in esecuzione in un server terminal. Per altre informazioni, vedere Proprietà TerminalServer .
  • Per eseguire un'azione personalizzata quando una determinata patch viene disinstallata, l'azione personalizzata deve essere presente nell'applicazione originale o essere in una patch per il prodotto sempre applicato. Per altre informazioni, vedere Patch Uninstall Custom Actions .For more information see Patch Uninstall Custom Actions.
  • Le azioni personalizzate non devono usare il livello di interfaccia utente come condizione per l'invio di messaggi di errore al programma di installazione perché ciò può interferire con la registrazione e i messaggi esterni. Per informazioni, vedere Determinazione del livello dell'interfaccia utente da un'azione personalizzata.
  • Usare le istruzioni condizionali e la sintassi dell'istruzione condizionale per garantire che il pacchetto esegua correttamente azioni personalizzate, non esegua azioni personalizzate o esegua un'azione personalizzata alternativa quando il pacchetto viene disinstallato. Verificare che il pacchetto funzioni come previsto durante la disinstallazione di azioni personalizzate. Per informazioni, vedere Azioni di condizionamento da eseguire durante la rimozione
  • Se l'installazione deve essere in grado di essere eseguita da utenti che non dispongono di privilegi di amministratore, verificare che tutte le azioni personalizzate possano essere eseguite con privilegi non di amministratore. Le azioni personalizzate richiedono privilegi elevati per modificare parti del sistema che non sono specifiche dell'utente. Il programma di installazione può eseguire azioni personalizzate con privilegi elevati se viene installata un'applicazione gestita o se i criteri di sistema sono stati specificati per privilegi elevati. Tutte le azioni personalizzate che richiedono privilegi elevati devono includere msidbCustomActionTypeInScript e msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options nel tipo di azione personalizzata. Questo è illustrato nell'esempio in Uso di un'azione personalizzata per creare account utente in un computer locale.

Se si usano assembly, seguire le procedure consigliate per l'assembly

Se il pacchetto usa assembly software, seguire le linee guida per l'aggiunta di assembly a un pacchetto, l'aggiornamento di assembly e l'installazione e la rimozione di assembly.

Non spedire installazioni simultanee.

Installazioni simultanee, dette anche installazioni annidate, installano un altro pacchetto di Windows Installer durante un'installazione attualmente in esecuzione. L'uso di installazioni simultanee non è una buona pratica perché sono difficili da gestire per i clienti. L'applicazione di patch e l'aggiornamento potrebbero non funzionare con installazioni simultanee. L'alternativa consigliata all'uso di installazioni simultanee consiste nell'usare invece un'applicazione di installazione e un gestore dell'interfaccia utente esterno per installare diversi pacchetti di Windows Installer in sequenza.

Per altre informazioni sull'uso di un gestore dell'interfaccia utente esterno, vedere Monitoraggio di un'installazione tramite MsiSetExternalUI. Per altre informazioni sull'uso di un gestore esterno basato su record, vedere Monitoraggio di un'installazione tramite MsiSetExternalUIRecord.

Le installazioni simultanee vengono talvolta usate in ambienti aziendali controllati per installare applicazioni non destinate al pubblico. Se si decide di usare installazioni simultanee, seguire queste linee guida.

  • Non utilizzare installazioni simultanee per installare o aggiornare un prodotto di spedizione.
  • Le installazioni simultanee non devono condividere i componenti.
  • Un'installazione amministrativa non deve contenere un'installazione simultanea.
  • Le barre di stato integrate non devono essere usate con installazioni simultanee.
  • Le risorse che devono essere annunciate non devono essere installate da un'installazione simultanea.
  • Un pacchetto che esegue un'installazione simultanea di un'applicazione deve anche disinstallare l'applicazione simultanea quando il prodotto padre viene disinstallato. Un'installazione annidata esiste nel contesto del prodotto padre in Installazione applicazioni in Pannello di controllo.

Mantenere coerenti i nomi dei pacchetti e i codici dei pacchetti.

Al file .msi può essere assegnato qualsiasi nome che consenta agli utenti di identificare il pacchetto, ma il nome non deve essere modificato senza modificare anche il codice prodotto.

  • Assegnare al file .msi un nome descrittivo che consente all'utente di identificare il contenuto del pacchetto di Windows Installer.
  • Il codice prodotto è l'identificazione principale di un'applicazione e deve cambiare ogni volta che è presente un aggiornamento completo all'applicazione. Per informazioni, vedere ProductCode e Modifica del codice prodotto. La modifica del nome del file di .msi dell'applicazione viene considerata una modifica completa e richiede sempre una modifica corrispondente del codice prodotto per mantenere la coerenza.
  • Il codice del pacchetto è l'identificatore primario usato dal programma di installazione per cercare e convalidare il pacchetto corretto per una determinata installazione. Nessun file di .msi non deve mai avere lo stesso codice del pacchetto. Se un pacchetto viene modificato senza modificare il codice del pacchetto, il programma di installazione potrebbe non usare il pacchetto più recente se entrambi sono ancora accessibili al programma di installazione. Il codice del pacchetto viene archiviato nella proprietà Riepilogo numeri revisione del flusso di informazioni di riepilogo.
  • Si noti che le lettere nel codice prodotto e nei GUID del codice del pacchetto devono essere tutte maiuscole.

Non usare le tabelle SelfReg e TypeLib.

  • Gli autori di pacchetti di installazione sono fortemente sconsigliati di usare la registrazione automatica e la tabella SelfReg . Devono invece registrare i moduli creando una o più tabelle nel gruppo tabelle del Registro di sistema. Molti dei vantaggi di Windows Installer vengono persi con la registrazione automatica perché le routine di registrazione automatica tendono a nascondere le informazioni di configurazione critiche. Per un elenco dei motivi per cui si evita la registrazione automatica, vedere la tabella SelfReg.
  • Gli autori di pacchetti di installazione sono fortemente sconsigliati di usare la tabella TypeLib . Anziché usare la tabella TypeLib, registrare le librerie dei tipi usando la tabella del Registro di sistema . Se un'installazione che usa la tabella TypeLib ha esito negativo e deve essere eseguito il rollback, il rollback potrebbe non ripristinare il computer nello stesso stato esistente prima del rollback.

Specificare l'opzione per l'installazione senza un'interfaccia utente.

Gli amministratori spesso preferiscono distribuire applicazioni all'interno di un'azienda senza richiedere l'interazione dell'utente. È consigliabile abilitare l'applicazione per fornire l'opzione di installazione con il livello di interfaccia utente None.

  • Usare le proprietà pubbliche per le informazioni di configurazione. Gli amministratori possono fornire queste informazioni sulla riga di comando.
  • Non è necessario che l'installazione dipenda dalle informazioni raccolte dall'interazione dell'utente con le finestre di dialogo. Queste informazioni non sono disponibili durante un'installazione invisibile all'utente.
  • Non riavviare automaticamente il computer dell'utente durante un'installazione invisibile all'utente.
  • Gli amministratori possono impostare il livello di interfaccia utente durante l'installazione usando l'opzione della riga di comando "/q". Il livello dell'interfaccia utente può anche essere impostato a livello di codice con una chiamata a MsiSetInternalUI.

Evitare di usare il criterio AlwaysInstallElevated.

Se il criterio AlwaysInstallElevated non è impostato, le applicazioni non distribuite dall'amministratore vengono installate usando i privilegi dell'utente e solo le applicazioni gestite ottengono privilegi elevati. L'impostazione di questo criterio indica a Windows Installer di usare le autorizzazioni di sistema quando installa l'applicazione nel sistema. Questo metodo può aprire un computer a un rischio di sicurezza, perché quando questo criterio è impostato, un utente non amministratore può eseguire installazioni con privilegi elevati e accedere a percorsi sicuri nel computer. È consigliabile usare un altro metodo rispetto al criterio AlwaysInstallElevated durante l'installazione di un pacchetto con privilegi elevati per un'applicazione non amministratore o l'applicazione di patch ad applicazioni gestite per utente.

Abilitare il criterio DisableMedia per limitare l'installazione non autorizzata.

I criteri DisableMedia possono impedire l'installazione non autorizzata delle applicazioni. Quando questo criterio è abilitato, gli utenti e gli amministratori che eseguono un'installazione di manutenzione di un prodotto non possono usare la finestra di dialogo Sfoglia per esplorare le origini multimediali, ad esempio CD-ROM, per le origini di altri prodotti installabili. L'esplorazione di altri prodotti viene impedita indipendentemente dal fatto che l'installazione venga eseguita con privilegi elevati. È comunque possibile che l'utente reinstalli il prodotto dal supporto se l'utente ha un'origine multimediale etichettata correttamente.

Mantenere i file di origine del pacchetto originali protetti e disponibili per gli utenti.

In alcuni casi potrebbe essere necessaria l'origine originale del pacchetto di Windows Installer per installare, ripristinare o aggiornare un'applicazione. Se il programma di installazione non è in grado di individuare un'origine disponibile, all'utente viene chiesto di fornire supporti o di passare a un percorso di rete contenente le origini necessarie. È consigliabile assicurarsi che il programma di installazione disponga delle origini necessarie senza dover chiedere conferma all'utente.

  • Usare firme digitali e file cab esterni per assicurarsi che le origini origali usate dal programma di installazione siano sicure. Un'immagine di origine non compressa archiviata in una posizione pubblica non è sicura.
  • Includere un elenco completo dei percorsi di origine di rete o URL per il pacchetto di installazione dell'applicazione nella proprietà SOURCELIST .
  • Usare una condivisione DFS (Distributed File System) per il percorso di origine.
  • Usare l'API di Windows Installer per recuperare e modificare le informazioni sull'elenco di origine per le applicazioni e le patch di Windows Installer. Per informazioni, vedere Gestione delle origini di installazione.
  • Utilizzare i metodi e le proprietà dell'oggetto Installer, dell'oggetto Product e dell'oggetto Patch per recuperare e modificare le informazioni dell'elenco di origine per le applicazioni e le patch di Windows Installer.
  • Attenersi ai punti elencati in Impedire a una patch di richiedere l'accesso all'origine dell'installazione originale per ridurre al minimo la possibilità che la patch richieda l'accesso alle origini originali.
  • Archiviare i file di origine del pacchetto in un percorso diverso dalla cartella temporanea del sistema. I file di origine di Windows Installer archiviati nella cartella temporanea possono diventare non disponibili per gli utenti.

Abilitare la registrazione dettagliata nel computer dell'utente durante la risoluzione dei problemi di distribuzione.

La registrazione di Windows Installer include un'opzione di registrazione dettagliata che può essere abilitata nel computer di un utente. Le informazioni contenute in un log dettagliato possono risultare utili quando si tenta di risolvere i problemi di distribuzione del pacchetto di Windows Installer.

  • È possibile abilitare la registrazione dettagliata nel computer dell'utente usando opzioni della riga di comando, la proprietà MsiLogging, i criteri di registrazione, MsiEnableLog e il metodo EnableLog.
  • Una risorsa molto utile per interpretare i file di log di Windows Installer è Wilogutl.exe. Questo strumento consente di analizzare i file di log e di visualizzare le soluzioni suggerite per gli errori rilevati in un file di log.
  • L'opzione di registrazione dettagliata deve essere usata solo a scopo di risoluzione dei problemi e non deve essere lasciata perché può avere effetti negativi sulle prestazioni del sistema e sullo spazio su disco. Ogni volta che si usa lo strumento Installazione applicazioni in Pannello di controllo, viene creato un nuovo file.

La disinstallazione lascia il computer dell'utente in uno stato pulito.

La rimozione dell'applicazione è importante quanto l'installazione. Quando un pacchetto di Windows Installer viene disinstallato, non deve lasciare alcuna parte inutile di se stessa nel computer dell'utente.

  • Se un file che dovrebbe essere stato rimosso dal computer dell'utente rimane installato dopo l'esecuzione di una disinstallazione, il programma di installazione potrebbe non rimuovere il componente contenente il file per uno o più dei motivi descritti in Rimozione di file bloccati.
  • Se è necessario registrare un'applicazione, creare il pacchetto per rimuovere le informazioni del Registro di sistema quando l'applicazione viene disinstallata. Per informazioni, vedere Aggiunta o rimozione di chiavi del Registro di sistema per l'installazione o la rimozione di componenti. Se un'applicazione non è registrata, l'applicazione non è elencata nella funzionalità Installazione applicazioni in Pannello di controllo e non può essere gestita tramite Windows Installer.
  • Per nascondere un'applicazione dalla funzionalità Installazione applicazioni in Pannello di controllo ed essere ancora in grado di usare Windows Installer per gestire l'applicazione, seguire le linee guida descritte in Aggiunta e rimozione di un'applicazione e lasciare nessuna traccia nel Registro di sistema.
  • Le azioni personalizzate devono essere condizionali per l'esecuzione o non in base alle esigenze al momento della disinstallazione. Potrebbero essere necessarie azioni personalizzate diverse per l'installazione e la disinstallazione.
  • Le informazioni di personalizzazione specifiche dell'utente possono essere archiviate in un file di testo nel computer. Questo ha il vantaggio che il file può essere rimosso quando l'applicazione viene disinstallata, anche se l'utente di questa personalizzazione non è attualmente connesso.

Testare i pacchetti sia per la distribuzione di installazione per utente che per computer.

È consigliabile consentire ai clienti di decidere se distribuire un pacchetto per l'installazione nel contesto di installazione per computer o per utente.

  • Valutare se l'applicazione deve essere disponibile solo per utenti specifici o tutti gli utenti del computer durante il processo di sviluppo.
  • Verificare che il pacchetto funzioni correttamente sia per l'installazione per utente che per i contesti di installazione per computer.
  • Rendere il pacchetto facilmente personalizzabile e consentire ai clienti di decidere se distribuirlo per utente o per computer.

Pianificare e testare una strategia di manutenzione prima di spedire l'applicazione.

È necessario decidere come si intende gestire l'applicazione prima di distribuire l'applicazione per la prima volta.

  • Prendere in considerazione i tipi di aggiornamenti che si prevede di usare per gestire l'applicazione in futuro. Windows Installer offre tre tipi di aggiornamenti: aggiornamento piccolo, aggiornamento secondario e aggiornamenti principali. Le differenze tra queste sono descritte nell'argomento Applicazione di patch e aggiornamenti .
  • Prima di spedire l'applicazione, verificare che funzioni come previsto dopo la manutenzione con ogni tipo di aggiornamento.

Ridurre la dipendenza degli aggiornamenti sulle origini originali.

Se i file di origine originali sono necessari per aggiornare l'applicazione, questa operazione può rendere più difficile la manutenzione dell'applicazione. I metodi seguenti consentono di ridurre la dipendenza degli aggiornamenti dalle origini originali.

Non distribuire moduli di merge non utilizzabili.

Le applicazioni non devono dipendere dai moduli di merge per l'installazione del componente se il proprietario del modulo di merge e il proprietario dell'applicazione sono diversi. Ciò può rendere difficile gestire l'applicazione perché entrambi i proprietari devono coordinare per aggiornare l'applicazione o il modulo. Senza conoscere tutte le applicazioni che hanno usato il modulo di merge, il proprietario dell'applicazione non è in grado di aggiornare il modulo di merge senza rischiare che l'aggiornamento non sia compatibile con un'altra applicazione. Il proprietario del modulo di merge non ha alcun metodo diretto per aggiornare i pacchetti di Windows Installer che hanno già installato il modulo di merge.

  • Valutare la possibilità di fornire i componenti necessari agli utenti come un'altra installazione di Windows Installer.

Evitare di applicare patch alle installazioni amministrative.

Fornire in una rete un'installazione amministrativa del pacchetto originale di Windows Installer dell'applicazione per consentire ai membri di un gruppo di lavoro di installare l'applicazione. Gli utenti di questa immagine amministrativa devono quindi applicare gli aggiornamenti all'istanza locale dell'applicazione che si trova nel computer. In questo modo gli utenti vengono sincronizzati con l'immagine amministrativa. L'applicazione degli aggiornamenti all'installazione amministrativa non è consigliata per i motivi seguenti.

  • Le dimensioni e la latenza del download necessarie per consentire agli utenti di ottenere un aggiornamento sono aumentate rispetto al download di una patch. L'intero pacchetto di Windows Installer aggiornato e i file di origine devono scaricare, riprogrammare e reinstallare.
  • Gli utenti non sono in grado di installare e ripristinare le applicazioni da un'installazione amministrativa aggiornata fino a quando non rechezzano e reinstallano l'applicazione.
  • L'applicazione di una patch a un'installazione amministrativa rimuove la firma digitale dal pacchetto. Un amministratore deve riassegnare il pacchetto. Per altre informazioni sull'uso delle firme digitali, vedere Firme digitali e Windows Installer.
  • Molte patch binarie hanno come destinazione l'immagine RTM dell'applicazione e richiedono una versione precedente del file. L'istanza locale di un'applicazione installata da un'installazione amministrativa aggiornata potrebbe non funzionare con altri aggiornamenti. Molte applicazioni di patch binarie possono avere esito negativo.
  • L'applicazione di una patch a un'installazione amministrativa aggiorna i file di origine e il file di .msi, ma non contrassegna l'immagine di rete con informazioni sull'aggiornamento. Gli utenti non possono determinare gli aggiornamenti ricevuti dall'installazione amministrativa. Ciò rende impossibile sequenziare gli aggiornamenti applicati sul lato utente con quelli già applicati sul lato immagine amministrativa.
  • Le patch applicate a un'installazione amministrativa non sono patch disinstallabili. Ciò può impedire che il codice del pacchetto memorizzato nella cache nel computer dell'utente diventi diverso dal codice del pacchetto nell'installazione amministrativa. Se il codice del pacchetto memorizzato nella cache nel computer dell'utente diventa diverso da quello nell'installazione amministrativa, reinstallare l'applicazione dall'installazione amministrativa e quindi applicare patch al computer client.
  • Se si decide di applicare piccoli aggiornamenti applicando patch a un'immagine amministrativa, seguire le linee guida descritte nell'argomento: Applicazione di piccoli aggiornamenti applicando patch a un'immagine amministrativa.

Registrare gli aggiornamenti per l'esecuzione con privilegi elevati.

A partire da Windows Installer 3.0, è possibile applicare patch a un'applicazione installata in un contesto gestito per utente, dopo la registrazione della patch come privilegi elevati. Non è possibile applicare patch alle applicazioni installate in un contesto gestito per utente usando versioni di Windows Installer precedenti alla versione 3.0.

  • Usare il metodo SourceListAddSource o la funzione MsiSourceListAddSourceEx per registrare un pacchetto patch come con privilegi elevati. Seguire le linee guida e gli esempi forniti in Applicazione di patch alle applicazioni gestite per utente.
  • Quando si esegue Windows Installer versione 4.0 in Windows Vista, è anche possibile usare l'applicazione di patch controllo dell'account utente per consentire agli autori di installazioni di Windows Installer di identificare le patch firmate digitalmente che possono essere applicate in futuro da utenti non amministratori. Questa opzione è disponibile solo con l'installazione dei pacchetti nel contesto di installazione per computer (ALLUSERS=1).
  • Assicurarsi che l'applicazione di patch con privilegi minimi non sia stata disabilitata impostando la proprietà MSIDISABLELUAPATCHING o il criterio DisableLUAPatching.

Usare la tabella MsiPatchSequence per sequenziare le patch.

Includere una tabella MsiPatchSequence nel pacchetto e aggiungere informazioni sulla sequenziazione delle patch. A partire da Windows Installer versione 3.0, il programma di installazione può usare la tabella MsiPatchSequence durante l'installazione di più patch per determinare la sequenza di applicazione patch migliore. Usare le linee guida descritte nel white paper Patch Sequencing in Windows Installer versione 3.0 per definire le famiglie di patch.

  • Se pratico, specificare tutte le patch come appartenenti a una singola famiglia di patch. In molti casi una singola famiglia di patch offre una flessibilità sufficiente per sequenziare le patch. La complessità della creazione aumenta quando vengono usate più famiglie di patch. Assegnare un nome significativo alla famiglia di patch e assegnare valori di sequenza in tale famiglia di patch che aumentano nel tempo. Seguire l'esempio di applicazione di patch multiple per applicare patch nell'ordine in cui sono state rilasciate.
  • Usare la tabella PatchSequence in Patchwiz.dll per generare le informazioni nella tabella MsiPatchSequence. La versione di PATCHWIZ.DLL rilasciata con Windows Installer 3.0 può generare automaticamente informazioni sulla sequenziazione delle patch. Per altre informazioni su come aggiungere una nuova patch, vedere Generazione di informazioni sulla sequenza di patch. Per altre informazioni sugli scenari di sequenziazione delle patch, vedere il white paper: Sequenziazione patch in Windows Installer versione 3.0.

Testare accuratamente il pacchetto di installazione.

Testare l'installazione, il ripristino e la rimozione corretti del pacchetto di Windows Installer. È possibile dividere il processo di test nelle parti seguenti.

  • Test di installazione: testare l'installazione con tutte le possibili combinazioni di funzionalità dell'applicazione. Testare tutti i tipi di installazione, tra cui Installazione amministrativa, Installazione rollback e Installazione su richiesta. Provare tutti i metodi di installazione possibili, inclusi i clic sul file .msi, le opzioni della riga di comando e l'installazione dal pannello di controllo. Verificare che il pacchetto possa essere installato dagli utenti in tutti i contesti di privilegio possibili. Provare a installare il pacchetto dopo che è stato distribuito da tutti i metodi possibili. Abilitare la registrazione di Windows Installer per ogni test e risolvere tutti gli errori rilevati nel log del programma di installazione e nel registro eventi.
  • Test dell'interfaccia utente: testare il pacchetto quando installato con tutti i livelli di interfaccia utente possibili. Testare il pacchetto installato senza interfaccia utente e con tutte le informazioni fornite tramite l'interfaccia utente. Assicurarsi che l'accessibilità dell'interfaccia utente e che l'interfaccia utente funzioni come previsto per risoluzioni dello schermo e dimensioni del carattere diverse.
  • Test di manutenzione e riparazione: verificare che il pacchetto possa gestire l'applicazione di patch e gli aggiornamenti recapitati da un piccolo aggiornamento, un aggiornamento secondario e aggiornamenti principali. Prima di distribuire il pacchetto, scrivere un aggiornamento della versione di valutazione di ogni tipo e provare ad applicarlo al pacchetto originale.
  • Uninstall Testing (Disinstalla test) - Verificare che quando il pacchetto viene rimosso non lasci parti inutili di se stesso nel computer dell'utente e che solo le informazioni appartenenti al pacchetto siano state rimosse. Riavviare il computer di test dopo aver disinstallato il pacchetto e verificare l'integrità degli strumenti di sistema comuni e di altre applicazioni standard. Verificare che il pacchetto possa essere rimosso dagli utenti in tutti i contesti di privilegio possibili. Testare tutti i metodi per rimuovere il pacchetto, fare clic sul file .msi, provare le opzioni della riga di comando e provare a rimuovere il pacchetto dal pannello di controllo. Abilitare la registrazione di Windows Installer per ogni test e risolvere tutti gli errori rilevati nel log del programma di installazione e nel registro eventi.
  • Test delle funzionalità del prodotto: assicurarsi che l'applicazione funzioni come previsto dopo l'installazione, il ripristino o la rimozione del pacchetto.

Correggere tutti gli errori di convalida prima di distribuire un pacchetto di installazione nuovo o modificato.

Eseguire la convalida del pacchetto in un pacchetto di Windows Installer nuovo o modificato prima di tentare di installarlo per la prima volta. La convalida controlla la presenza di errori di creazione nel database di Windows Installer. Il tentativo di installare un pacchetto che non supera la convalida può danneggiare il sistema dell'utente.

  • È possibile convalidare il pacchetto usando Orca.exe o Msival2.exe. Entrambi gli strumenti vengono forniti con Windows SDK. I fornitori di terze parti possono anche incorporare il sistema di convalida ICE nell'ambiente di creazione.
  • È possibile usare il set standard di analizzatori di coerenza interna - ICEs inclusi nei file con estensione cub forniti con l'SDK oppure personalizzare la convalida creando un ice e aggiungendolo al file con estensione cub.
  • È possibile usare il Evalcom2.dll per implementare l'automazione della convalida per i pacchetti di installazione e i moduli di merge.

Creare un'installazione sicura.

Seguendo queste linee guida durante lo sviluppo del pacchetto per mantenere un ambiente sicuro durante l'installazione.

Usare PMSIHANDLE anziché HANDLE

Le variabili di tipo PMSIHANDLE sono definite in msi.h. È consigliabile che l'applicazione usi il tipo PMSIHANDLE perché il programma di installazione chiude gli oggetti PMSIHANDLE quando escono dall'ambito, mentre l'applicazione deve chiudere gli oggetti MSIHANDLE chiamando MsiCloseHandle. PMSIHandle fornisce un operatore di cast a MSIHANDLE per la compatibilità delle firme API.

Ad esempio, se si usa codice simile al seguente:

MSIHANDLE hRec = MsiCreateRecord(3);

Sostituirlo con:

PMSIHANDLE hRec = MsiCreateRecord(3);