Bonnes pratiques relatives à Windows Installer

  • Article

Cette section énumère les astuces liées à la documentation principale du Kit de développement logiciel (SDK) Windows Installer, pour aider les développeurs d’applications, les auteurs d’installation, les professionnels de l’informatique et les développeurs d’infrastructure à découvrir les meilleures pratiques quant à l’utilisation de Windows Installer :

Mettez à jour la version de Windows Installer.

  • Utilisez Windows Installer 5.0 sur Windows Server 2008 R2 et Windows 7. Il s’agit de la version de Windows Installer fournie avec le système d’exploitation.
  • Utilisez Windows Installer 4.5 sur Windows Server 2008, Windows Server 2003 avec Service Pack 1 (SP1), Windows Vista avec Service Pack 1 (SP1) ou Windows XP avec Service Pack 2 (SP2). Pour plus d’informations sur l’obtention de la dernière version de Windows Installer, consultez Redistribuables Windows Installer.
  • Utilisez Windows Installer 3.1 sur Windows 2000 avec Service Pack 3 (SP3). Windows Installer version 3.1 offre des fonctionnalités qui facilitent la maintenance des applications et la mise à jour corrective.
  • De nombreuses fonctionnalités importantes ont été introduites avec la version 3.0 et sont répertoriées dans la section Non pris en charge dans Windows Installer version 2.0. Les packages d’installation et les mises à jour créés pour Windows Installer 2.0 peuvent être installés à l’aide de Windows Installer 3.0 et versions ultérieures. Les packages de correctifs qui contiennent les nouvelles tables utilisées par Windows Installer 3.0 peuvent toujours être appliqués à l’aide de versions antérieures de Windows Installer, mais sans la fonctionnalité de mise à jour corrective de Windows Installer 3.0. Il est également possible de créer des correctifs qui exigent explicitement Windows Installer 3.0 et qui ne peuvent pas être appliqués par les versions antérieures de Windows Installer. Si un utilisateur ne parvient pas à mettre à jour la version du programme d’installation, vérifiez que votre application ou mise à jour sera compatible avec une prochaine mise à jour de Windows Installer.
  • Pour obtenir la liste des fonctionnalités de Windows Installer non prises en charge par les versions antérieures de Windows Installer, voir Nouveautés de Windows Installer.

Répondez aux exigences de certification du logo Windows.

  • Même si vous n’avez pas l’intention de soumettre votre application au programme de logo, suivez les recommandations de certification de logo pour améliorer votre package Windows Installer. Pour obtenir une vue d’ensemble des exigences de logo et des liens vers des programmes de certification de logo spécifiques, consultez Configuration requise pour Windows Installer et les logos.

Préparez le package pour la localisation.

  • Il est recommandé de préparer la localisation future lors de la création du package d’installation d’origine. Vous pouvez suivre la procédure de localisation de package suggérée dans Localisation d’un package Windows Installer.

Mettez à jour vos outils de développement et votre documentation Windows Installer.

  • Les outils de développement Windows Installer ne sont pas redistribuables et vous devez uniquement utiliser leurs versions disponibles auprès de Microsoft. Ceux-ci sont disponibles dans les composants du SDK Windows pour les développeurs Windows Installer dans le Kit de développement logiciel Windows (Kit SDK Windows) de Microsoft.
  • Plusieurs fournisseurs de logiciels indépendants proposent des outils pour créer ou modifier des packages Windows Installer. Ces outils peuvent fournir un environnement de création de package qui peut être plus facile à utiliser que les outils fournis dans le Kit de développement logiciel (SDK) Windows Installer. Vous pouvez en apprendre plus sur ces outils à partir des ressources d’informations présentées dans Autres sources d’informations sur Windows Installer.
  • La fonctionnalité de création d’un package à partir de fichiers texte peut être plus intuitive pour certains développeurs. L’ensemble d’outils XML de Windows Installer (WiX) disponible sur Sourceforge.net génère des packages d’installation Windows à partir de code source XML.
  • La documentation du Kit de développement logiciel (SDK) Windows Installer publiée dans MSDN Online Library est mise à jour le plus fréquemment.
  • Utilisez la version récente de Msizap.exe (version 3.1.4000.2726 ou ultérieure) disponible dans les composants du SDK Windows pour les développeurs Windows Installer pour Windows Vista ou version ultérieure. Les versions antérieures de Msizap.exe peuvent supprimer des informations sur toutes les mises à jour appliquées à d’autres applications sur l’ordinateur de l’utilisateur. Si ces informations sont supprimées, ces autres applications doivent peut-être être supprimées et réinstallées pour recevoir des mises à jour supplémentaires.
  • L’éditeur de table de base de données Orca.exe sert à créer et à modifier des packages Windows Installer et des modules de fusion. Il dispose d’une interface utilisateur graphique de base, mais il prend en charge la modification avancée des bases de données Windows Installer. Même si vous utilisez une autre application comme outil de développement principal, vous pourriez estimer que l’utilisation d’Orca.exe est pratique lors du dépannage et du test d’un package.
  • Consultez Autres sources d’informations sur Windows Installer pour obtenir les informations récentes de Windows Installer disponibles dans les blogs, les conversations avec un agent du support technique, les groupes de discussion, les articles techniques et les sites Web.

Si vous décidez de repackager une application d’installation héritée, suivez les bonnes pratiques de repackaging.

De nombreux fournisseurs d’applications fournissent des packages Windows Installer natifs pour l’installation ou leurs produits. Un logiciel qui convertit une application d’installation héritée existante en package Windows Installer est appelé outil de repackaging. Le repackaging d’une application d’installation existante ne constitue pas la meilleure pratique de développement. Les applications qui ont été conçues à partir du début pour bénéficier des fonctionnalités de Windows Installer peuvent être plus faciles à installer et à utiliser pour les utilisateurs. Si vous décidez d’utiliser un logiciel de repackaging, les pratiques suivantes peuvent vous aider à produire un meilleur package Windows Installer.

  • Les outils de repackaging convertissent les installations héritées en package Windows Installer en prenant une photo d’un système de simulation avant et après l’installation. L’ensemble des modifications de registre, des modifications de fichier ou des paramètres système qui se produisent pendant le processus de capture sont incluses dans l’installation. Configurez le matériel et le logiciel de l’ordinateur utilisé pour repackager l’installation le plus près possible du système de l’utilisateur prévu. Créez un package distinct pour chaque configuration matérielle différente. Repackagez à l’aide d’un ordinateur de simulation propre. Supprimez toutes les applications inutiles. Arrêtez tous les processus inutiles. Fermez tous les services système non essentiels.
  • Effectuez toujours une copie de l’installation d’origine avant de commencer à travailler dessus. Travaillez toujours sur la copie. N’arrêtez jamais un repackager avant qu’il termine la génération du package. Si le repackager endommage le package, vous aurez toujours l’original.
  • Ne repackagez pas les mises à jour de logiciels Microsoft dans un package Windows Installer. Microsoft publie des mises à jour logicielles, telles que les Service Packs, comme les fichiers à extraction automatique qui exécutent automatiquement l’installation. Ces mises à jour utilisent des programmes d’installation différents de Windows Installer pour remplacer les ressources Windows protégées et ne peuvent pas être converties en package Windows Installer. Pour plus d’informations sur la manière de déployer des Service Packs Windows, consultez le guide de déploiement de Service Pack sur Microsoft TechNet.
  • N’utilisez pas d’outil de repackaging pour convertir un package Windows Installer en un nouveau package. Windows Installer ajoute des informations de configuration au système ainsi qu’aux ressources d’application. Lorsqu’un outil de repackaging compare le système avant et après l’installation, le repackager interprète mal les informations de configuration dans le cadre de l’application. Cela endommage généralement l’application repackagée. Utilisez plutôt des transformations de personnalisation pour modifier un package Windows Installer existant ou en créer un autre. Vous pouvez créer des transformations de personnalisation à l’aide de l’outil Msitran.exe.
  • N’utilisez pas d’outil de repackaging pour consolider plusieurs packages Windows Installer dans un seul package. Au lieu de cela, vous pouvez utiliser l’outil Msistuff.exe pour configurer l’exécutable d’amorçage Setup.exe afin d’installer les packages l’un après l’autre.
  • Créez votre package Windows Installer afin que le client puisse facilement le personnaliser. Les variables globales utilisées par Windows Installer pendant une installation peuvent être définies à l’aide de propriétés publiques ou de transformations de personnalisation. Fournissez de la documentation pour l’utilisation de ces propriétés et des valeurs par défaut pratiques pour toutes les valeurs personnalisables. Pour plus d’informations sur l’obtention et la définition de propriétés, consultez Utilisation des propriétés. Pour obtenir un exemple de transformation de personnalisation, consultez Un exemple de transformation de personnalisation.

N’essayez pas de remplacer des ressources protégées.

Les packages Windows Installer ne doivent pas essayer de remplacer les ressources protégées pendant l’installation ou la mise à jour. Windows Installer ne supprime pas ou ne remplace pas ces ressources, car Windows empêche le remplacement des fichiers système, dossiers et clés de Registre essentiels. La protection de ces ressources empêche les défaillances de l’application et du système d’exploitation.

  • Lors de l’exécution sur Windows Server 2008 ou Windows Vista, Windows Installer ignore l’installation d’un fichier ou d’une clé de Registre protégé par Protection des ressources Windows (WRP). Le programme d’installation entre un avertissement dans le fichier journal et poursuit le reste de l’installation sans erreur. Pour plus d’informations, consultez Utilisation de Windows Installer et de Protection des ressources Windows.
  • WRP est le nouveau nom de Protection des fichiers Windows (PAM). WRP protège les clés de Registre et les dossiers ainsi que les fichiers Système essentiels. Dans Windows Server 2003, Windows XP et Windows 2000, lorsque Windows Installer a rencontré un fichier protégé par WFP, le programme d’installation devrait demander à PAM d’installer le fichier. Pour plus d’informations, consultez Utilisation de Windows Installer et de Protection des ressources Windows.

Ne dépendez pas des ressources non critiques.

Votre installation ou mise à jour ne doit pas dépendre de l’installation de ressources non critiques pour les raisons suivantes.

  • Les actions personnalisées peuvent échouer si elles dépendent d’un composant appartenant à une fonctionnalité que l’utilisateur publie plutôt que d’installer.
  • Les actions personnalisées séquencées avant action InstallFinalize peuvent échouer si elles dépendent d’un composant contenant un assembly en cours d’installation. Windows Installer ne valide pas les assemblys dans le cache d’assembly global (GAC) tant que l’action InstallFinalize n’est pas terminée.

Utilisez l’API pour récupérer les informations de configuration de Windows Installer.

L’installation de votre application ou mise à jour ne doit pas dépendre de l’accès direct aux informations de configuration de Windows Installer enregistrées sur votre ordinateur. Utilisez plutôt l’interface de programmation d’application de Windows Installer pour récupérer les informations de configuration. L’emplacement et le format des informations de configuration sont gérés par le service Windows Installer et peuvent changer.

Organisez l’installation de votre application autour de composants.

Le service Windows Installer installe ou supprime des collections de ressources appelées composants. Étant donné que les composants sont généralement partagés, l’auteur d’un package d’installation doit suivre les règles lorsqu’il spécifie des composants d’une fonctionnalité ou d’une application.

  • Respectez les règles de composant lors de l’organisation d’applications en composants pour vous assurer que de nouveaux composants, ou de nouvelles versions de composants, peuvent être installés et supprimés sans endommager d’autres applications. Vous pouvez suivre la procédure décrite dans Définition des composants du programme d’installation.
  • Le programme d’installation effectue le suivi de chaque composant par le GUID d’ID de composant respectif spécifié dans la table des composants. Il est essentiel pour l’opération du mécanisme de comptage de référence Windows Installer que le GUID de l’ID de composant soit correct. Suivez les instructions de Modification du code de composant.
  • Si votre package doit enfreindre les règles de composant, tenez compte des conséquences possibles et assurez-vous que votre installation n’installe jamais ces composants là où ils peuvent endommager des composants sur le système de l’utilisateur. Pour plus d’informations, voir Que se passe-t-il en cas de rupture des règles de composant ?.
  • Sachez comment Windows Installer applique les règles de contrôle de version des fichiers lors du remplacement des fichiers existants. Windows Installer détermine d’abord si le fichier de clé du composant est déjà installé avant de tenter d’installer les fichiers du composant. Si le programme d’installation trouve un fichier portant le même nom que le fichier de clé du composant installé à l’emplacement cible, il compare la version, la date et la langue des deux fichiers de clés et utilise des règles de contrôle de version de fichier pour déterminer s’il faut installer le composant fourni par le package. Si le programme d’installation détermine qu’il doit remplacer la base du composant sur le fichier de clé, il utilise les règles de contrôle de version de fichier sur chaque fichier installé pour déterminer s’il faut le remplacer.

Réduisez la taille des packages Windows Installer volumineux.

Les packages Windows très volumineux prennent des ressources système et peuvent être difficiles à installer pour les utilisateurs. Il est recommandé de réduire la taille des packages Windows Installer très volumineux en procédant comme suit.

  • Compressez les fichiers dans l’installation et stockez-les dans un fichier .cab. Le programme d’installation permet au fichier .cab d’être stocké en tant que fichier externe distinct ou en tant que flux de données dans le package MSI lui-même. Pour plus d’informations, consultez Utilisation de Cabinets et de sources compressées.
  • Supprimez l’espace de stockage perdu dans le fichier .msi à l’aide de l’une des options décrites dans Réduction de la taille d’un fichier .msi.
  • Si votre package Windows Installer contient plus de 32 767 fichiers, vous devez modifier le schéma de la base de données. Pour plus d’informations, consultez Création d’un package volumineux.

Si vous utilisez des actions personnalisées, suivez les bonnes pratiques d’action personnalisée.

Windows Installer a de nombreuses actions standard intégrées pour l’installation et la maintenance des applications. Les développeurs doivent tenter de s’appuyer sur les actions standard autant que pratiques, plutôt que de créer leurs propres actions personnalisées. Toutefois, il existe des situations où le développeur d’un package d’installation trouve qu’il est nécessaire d’écrire une action personnalisée.

Si vous utilisez des assemblys, suivez les bonnes pratiques d’assembly.

Si votre package utilise des assemblys logicielles, suivez les recommandations pour ajouter des assemblys à un package, mettre à jour des assemblys et installer et supprimer des assemblys.

N’expédiez pas d’installations simultanées.

Les installations simultanées, également appelées installations imbriquées, installent un autre package Windows Installer pendant une installation en cours d’exécution. L’utilisation d’installations simultanées n’est pas recommandée, car elles sont difficiles à gérer pour les clients. La mise à jour corrective et la mise à niveau peuvent ne pas fonctionner avec les installations simultanées. L’alternative recommandée à l’utilisation d’installations simultanées consiste à préférer une application d’installation et un gestionnaire d’IU externe pour installer plusieurs packages Windows Installer de manière séquentielle.

Pour plus d’informations sur l’utilisation d’un gestionnaire d’IU externe, consultez Surveillance d’une installation à l’aide de MsiSetExternalUI. Pour plus d’informations sur l’utilisation d’un gestionnaire externe basé sur des enregistrements, consultez Surveillance d’une installation à l’aide de MsiSetExternalUIRecord.

Les installations simultanées sont parfois utilisées dans des environnements d’entreprise contrôlés pour installer des applications qui ne sont pas destinées au public. Suivez ces recommandations si vous décidez d’utiliser des installations simultanées.

  • N’utilisez pas d’installations simultanées pour installer ou mettre à jour un produit d’expédition.
  • Les installations simultanées ne doivent pas partager de composants.
  • Une installation administrative ne doit pas contenir d’installation simultanée.
  • Les barres de progression intégrées ne doivent pas être utilisés avec des installations simultanées.
  • Les ressources à publier ne doivent pas être installées par une installation simultanée.
  • Un package qui effectue une installation simultanée d’une application doit également désinstaller l’application simultanée lorsque le produit parent est désinstallé. Une installation imbriquée existe dans le contexte du produit parent dans Ajouter/Supprimer des programmes, dans le panneau de contrôle.

Assurez la cohérence des noms de package et des codes de package.

Le fichier .msi peut recevoir n’importe quel nom permettant aux utilisateurs d’identifier le package, mais le nom ne doit pas être modifié sans que le code du produit ne le soit également.

  • Donnez à votre fichier .msi un nom convivial qui permet à l’utilisateur d’identifier le contenu du package Windows Installer.
  • Le code de produit est l’identification principale d’une application et doit changer chaque fois qu’il existe une mise à jour complète de l’application. Pour plus d’informations, consultez ProductCode et Modification du code de produit. La modification du nom du fichier .msi de l’application est considérée comme une modification complète et nécessite toujours une modification correspondante du code de produit pour maintenir la cohérence.
  • Le code du package est l’identificateur principal utilisé par le programme d’installation pour rechercher et valider le package approprié pour une installation donnée. Aucun des deux fichiers .msi non identiques ne doit avoir le même code de package. Si un package est modifié sans que le code du package soit modifié, il se peut que le programme d’installation n’utilise pas le package le plus récent si le programme d’installation a toujours accès aux deux. Le code du package est stocké dans la propriété Résumé du numéro de révision du flux d’informations récapitulatives.
  • Notez que les lettres dans le code de produit et les GUID de code de package doivent toutes être en capitales.

N’utilisez pas les tables SelfReg et TypeLib.

  • Il est fortement déconseillé aux auteurs de packages d’installation d’utiliser l’auto-inscription et la table SelfReg. Au lieu de cela, ils doivent inscrire des modules en créant une ou plusieurs tables dans le groupe de tables du Registre. La plupart des avantages de Windows Installer sont perdus avec l’inscription automatique, car les routines d’inscription automatique ont tendance à masquer les informations de configuration critiques. Pour obtenir la liste des raisons d’éviter l’inscription automatique, consultez Table SelfReg.
  • Il est fortement déconseillé aux auteurs de packages d’installation d’utiliser la table TypeLib. Au lieu d’utiliser la table TypeLib, inscrivez des bibliothèques de types à l’aide de la table Registre. Si une installation utilisant la table TypeLib échoue et doit être restaurée, il se peut que l’ordinateur ne soit pas restauré dans le même état.

Proposez l’option d’installation sans interface utilisateur.

Les administrateurs préfèrent souvent déployer des applications au sein d’une société sans nécessiter d’interaction utilisateur. Il est recommandé de permettre à votre application d’offrir la possibilité d’être installée avec le niveau d’interface utilisateur None.

  • Pour obtenir des informations de configuration, utilisez les propriétés publiques. Les administrateurs peuvent fournir ces informations sur la ligne de commande.
  • N’exigez pas que l’installation dépende des informations collectées à partir de l’interaction utilisateur avec des zones de dialogue. Ces informations ne sont pas disponibles pendant une installation sans assistance.
  • Ne redémarrez pas automatiquement l’ordinateur de l’utilisateur pendant une installation sans assistance.
  • Les administrateurs peuvent définir le niveau d’interface utilisateur lors de l’installation à l’aide de l’option de ligne de commande « /q ». Le niveau d’interface utilisateur peut également être défini programmatiquement avec un appel à MsiSetInternalUI.

Évitez d’utiliser la stratégie AlwaysInstallElevated.

Si la stratégie AlwaysInstallElevated n’est pas définie, les applications non distribuées par l’administrateur sont installées à l’aide des privilèges de l’utilisateur et seules les applications gérées obtiennent des privilèges élevés. La définition de cette stratégie permet à Windows Installer d’utiliser des autorisations système lorsqu’elle installe l’application sur le système. Cette méthode peut exposer un ordinateur à un risque de sécurité, car lorsque cette stratégie est définie, un utilisateur non-administrateur peut exécuter des installations avec des privilèges élevés et accéder à des emplacements sécurisés sur l’ordinateur. Il est recommandé d’utiliser une autre méthode que la stratégie AlwaysInstallElevated lors de l’installation d’un package avec des privilèges élevés pour un non-administrateur ou de la mise à jour corrective des applications gérées par utilisateur.

Activez la stratégie DisableMedia pour limiter les installations non autorisées.

La stratégie DisableMedia peut empêcher l’installation non autorisée des applications. Lorsque cette stratégie est activée, les utilisateurs et les administrateurs exécutant une installation de maintenance d’un produit ne peuvent pas utiliser la boîte de dialogue Parcourir pour parcourir les sources multimédias, telles que des CD-ROM, pour les sources d’autres produits installables. La navigation à la recherche d’autres produits est impossible, que l’installation soit ou non effectuée avec des privilèges élevés. Il est toujours possible pour l’utilisateur de réinstaller le produit à partir d’un média s’il dispose d’une source multimédia correctement étiquetée.

Assurez-vous que les fichiers source du package d’origine restent sécurisés et disponibles pour les utilisateurs.

Dans certains cas, la source d’origine du package Windows Installer peut être nécessaire pour installer à la demande, réparer ou mettre à jour une application. Si le programme d’installation ne parvient pas à localiser une source disponible, l’utilisateur est invité à fournir un média ou à accéder à un emplacement réseau contenant les sources nécessaires. Il est recommandé de s’assurer que le programme d’installation dispose des sources requises sans avoir à inviter l’utilisateur.

  • Utilisez des signatures numériques et des fichiers CAB externes pour vous assurer que les sources d’origine utilisées par le programme d’installation sont sécurisées. Une image source non compressée stockée dans un emplacement public n’est pas sécurisée.
  • Incluez une liste complète des chemins d’accès source réseau ou URL permettant d’accéder au package d’installation d’application dans la propriété SOURCELIST.
  • Utilisez un partage de système de fichiers (DFS) pour le chemin d’accès source.
  • Utilisez l’API Windows Installer pour récupérer et modifier les informations de liste source pour les applications et correctifs Windows Installer. Pour plus d’informations, consultez Gestion des sources d’installation.
  • Utilisez les méthodes et les propriétés de l’objet de programme d’installation, de l’objet de produit et de l’objet de correctif pour récupérer et modifier les informations de liste source pour les applications et correctifs Windows Installer.
  • Respectez les points répertoriés dans la section Empêcher un correctif d’exiger l’accès à la source d’installation d’origine afin de minimiser la possibilité que votre correctif exige l’accès à la source d’installation d’origine.
  • Stockez les fichiers source du package dans un emplacement qui n’est pas le dossier temporaire du système. Les fichiers source Windows Installer stockés dans le dossier temporaire peuvent devenir indisponibles pour les utilisateurs.

Activez la journalisation détaillée sur l’ordinateur de l’utilisateur lors de la résolution des problèmes de déploiement.

La journalisation Windows Installer inclut une option de journalisation détaillée qui peut être activée sur l’ordinateur d’un utilisateur. Les informations contenues dans un journal détaillé peuvent être utiles lors de la tentative de dépannage du déploiement de package Windows Installer.

  • Vous pouvez activer la journalisation détaillée sur l’ordinateur de l’utilisateur à l’aide des options de ligne de commande, de la propriété MsiLogging, de la stratégie de journalisation, de MsiEnableLog et de la méthode EnableLog.
  • Une ressource très utile pour interpréter les fichiers journaux Windows Installer est Wilogutl.exe. Cet outil aide à analyser les fichiers journaux et affiche des solutions suggérées pour les erreurs détectées dans un fichier journal.
  • L’option de journalisation détaillée doit être utilisée uniquement à des fins de dépannage et ne doit pas être conservée, car elle peut avoir des effets néfastes sur les performances du système et l’espace disque. Chaque fois que vous utilisez l’outil Ajouter/Supprimer des programmes dans Panneau de contrôle, un autre fichier est créé.

La désinstallation laisse l’ordinateur de l’utilisateur dans un état propre.

La suppression de l’application est aussi importante que l’installation. Lorsqu’un package Windows Installer est désinstallé, il ne doit laisser aucune partie inutile de lui-même sur l’ordinateur de l’utilisateur.

  • Si un fichier qui doit avoir été supprimé de l’ordinateur de l’utilisateur reste installé après l’exécution d’une désinstallation, il se peut que le programme d’installation ne supprime pas le composant contenant le fichier pour une ou plusieurs des raisons décrites dans Suppression de fichiers inexploités.
  • Si une application doit être inscrite, créez le package pour supprimer les informations de Registre lorsque l’application est désinstallée. Pour plus d’informations, consultez Ajout ou suppression de clés de Registre sur l’installation ou suppression des composants. Si une application n’est pas inscrite, elle n’est pas répertoriée dans la fonctionnalité Ajouter ou supprimer des programmes dans Panneau de contrôle et ne peut pas être gérée à l’aide de Windows Installer.
  • Pour masquer une application de la fonctionnalité Ajouter ou supprimer des programmes dans Panneau de contrôle et continuer à utiliser Windows Installer pour gérer l’application, suivez les recommandations décrites dans Ajout et suppression d’une application et ne laisser aucune trace dans le Registre.
  • Les actions personnalisées doivent être conditionnées pour s’exécuter ou non au besoin lors de la désinstallation. Différentes actions personnalisées peuvent avoir besoin d’être exécutées lors de l’installation et de la désinstallation.
  • Les informations de personnalisation propres à l’utilisateur peuvent être stockées dans un fichier texte sur l’ordinateur. Cela a pour avantage que le fichier peut être supprimé lorsque l’application est désinstallée, même si l’utilisateur de cette personnalisation n’est pas actuellement connecté.

Testez les packages pour le déploiement d’installation par utilisateur et par ordinateur.

Il est recommandé de permettre aux clients de décider s’il faut déployer un package pour l’installation dans un contexte d’installation par ordinateur ou par utilisateur.

  • Déterminez si l’application doit être disponible uniquement pour des utilisateurs particuliers ou tous les utilisateurs de l’ordinateur pendant le processus de développement.
  • Vérifiez que le package fonctionne correctement pour l’installation par utilisateur et les contextes d’installation par ordinateur.
  • Faites en sorte que le package soit facilement personnalisable et laissez les clients décider s’ils veulent le déployer par utilisateur ou par ordinateur.

Planifiez et testez une stratégie de maintenance avant d’expédier l’application.

Vous devez décider de la façon dont vous prévoyez de maintenir l’application avant de la déployer pour la première fois.

Réduisez la dépendance des mises à jour par rapport aux sources d’origine.

Si les fichiers source d’origine sont requis pour mettre à jour votre application, cela peut compliquer la maintenance de l’application. Les méthodes suivantes peuvent contribuer à réduire la dépendance des mises à jour par rapport aux sources d’origine.

Ne distribuez pas les modules de fusion inutilisables.

Les applications ne doivent pas dépendre des modules de fusion pour l’installation du composant si le propriétaire du module de fusion et le propriétaire de l’application sont différents. Cela peut compliquer la maintenance de l’application, car les deux propriétaires doivent se coordonner pour mettre à jour l’application ou le module. Sans connaître toutes les applications qui ont utilisé le module de fusion, le propriétaire de l’application ne peut pas mettre à jour le module de fusion sans risquer que la mise à jour soit incompatible avec une autre application. Le propriétaire du module de fusion ne dispose d’aucune méthode directe pour mettre à jour les packages Windows Installer qui ont déjà installé le module de fusion.

  • Envisagez de fournir les composants nécessaires aux utilisateurs sous la forme d’une autre installation de Windows Installer.

Évitez de retoucher les installations administratives.

Fournissez sur un réseau une installation administrative du package Windows Installer d’origine de votre application pour permettre aux membres d’un groupe de travail d’installer l’application. Les utilisateurs de cette image administrative doivent ensuite appliquer des mises à jour à l’instance locale de l’application se trouvant sur leur ordinateur. Cela permet aux utilisateurs de se synchroniser avec l’image administrative. L’application de mises à jour à l’installation administrative n’est pas recommandée pour les raisons suivantes.

  • La taille et la latence du téléchargement requis pour que les utilisateurs obtiennent une mise à jour sont augmentées par rapport au téléchargement d’un correctif. L’ensemble du package Windows Installer et des fichiers source mis à jour doit être téléchargé, remis en cache et réinstallé.
  • Les utilisateurs ne peuvent pas installer à la demande et réparer des applications à partir d’une installation administrative mise à jour jusqu’à ce qu’ils remettent en cache et réinstallent l’application.
  • L’application d’un correctif à une installation administrative supprime la signature numérique du package. Un administrateur doit à nouveau signer le package. Pour plus d’informations sur l’utilisation de signatures numériques, consultez Signatures numériques et Windows Installer.
  • De nombreux correctifs binaires ciblent l’image RTM de l’application et nécessitent une version de fichier précédente. L’instance locale d’une application installée à partir d’une installation administrative mise à jour peut ne pas fonctionner avec d’autres mises à jour. De nombreuses applications correctives binaires peuvent échouer.
  • L’application d’un correctif à une installation administrative met à jour les fichiers source et le fichier .msi, mais n’applique pas une empreinte à l’image réseau avec des informations sur la mise à jour. Les utilisateurs ne peuvent pas déterminer les mises à jour qu’ils ont reçues de l’installation administrative. Cela rend impossible la séquence des mises à jour appliquées côté utilisateur avec celles déjà appliquées côté image administrative.
  • Les correctifs appliqués à une installation administrative ne sont pas désinstallables. Cela peut empêcher le code du package mis en cache sur l’ordinateur de l’utilisateur de se différencier du code du package sur l’installation administrative. Si le code du package mis en cache sur l’ordinateur de l’utilisateur devient différent de celui de l’installation administrative, réinstallez l’application à partir de l’installation administrative, puis corrigez l’ordinateur client.
  • Si vous décidez d’appliquer de petites mises à jour en retouchant une image administrative, suivez les recommandations décrites dans la rubrique Application de petites mises à jour en retouchant une image administrative.

Enregistrez les mises à jour à exécuter avec des privilèges élevés.

À compter de Windows Installer 3.0, il est possible d’appliquer des correctifs à une application installée dans un contexte géré par utilisateur, une fois que le correctif a été inscrit comme ayant des privilèges élevés. Vous ne pouvez pas appliquer de correctifs aux applications installées dans un contexte géré par utilisateur à l’aide de versions de Windows Installer antérieures à la version 3.0.

Utilisez la table MsiPatchSequence pour séquencer des correctifs.

Incluez une table MsiPatchSequence dans votre package et ajoutez des informations de classement de correctifs. À compter de Windows Installer version 3.0, le programme d’installation peut utiliser la table MsiPatchSequence lors de l’installation de plusieurs correctifs pour déterminer la meilleure séquence d’application de correctifs. Utilisez les instructions décrites dans le livre blanc Classement de correctifs dans Windows Installer version 3.0 pour définir des familles de correctifs.

  • Si possible, spécifiez tous les correctifs comme appartenant à une seule famille de correctifs. Dans de nombreux cas, une seule famille de correctifs offre suffisamment de flexibilité pour séquencer les correctifs. La complexité de la création augmente lorsque plusieurs familles de correctifs sont utilisées. Attribuez un nom explicite à la famille de correctifs et des valeurs de séquence dans cette famille de correctifs qui augmentent au fil du temps. Suivez l’exemple de mise à jour corrective multiple pour appliquer des correctifs dans l’ordre dans lequel ils ont été émis.
  • Utilisez la table PatchSequence dans Patchwiz.dll pour générer les informations dans la table MsiPatchSequence. La version de PATCHWIZ.DLL publiée avec Windows Installer 3.0 peut générer automatiquement des informations de classement de correctifs. Pour plus d’informations sur l’ajout d’un nouveau correctif, consultez Génération d’informations sur la séquence de correctifs. Pour plus d’informations sur les scénarios de classement de correctifs, consultez le livre blanc Classement de correctifs dans Windows Installer version 3.0.

Testez soigneusement le package d’installation.

Testez l’installation, la réparation et la suppression correctes de votre package Windows Installer. Vous pouvez diviser votre processus de test en plusieurs parties.

  • Test d’installation : testez l’installation avec toutes les combinaisons possibles de fonctionnalités d’application. Testez tous les types d’installation, notamment Installation administrative, Installation de restauration et Installation à la demande. Essayez toutes les méthodes d’installation possibles, notamment en cliquant sur le fichier .msi, les options de ligne de commande et l’installation à partir du panneau de contrôle. Vérifiez que le package peut être installé par les utilisateurs dans tous les contextes de privilèges possibles. Essayez d’installer le package une fois qu’il a été déployé par toutes les méthodes possibles. Activez Journalisation Windows Installer pour chaque test et corrigez toutes les erreurs trouvées dans le journal du programme d’installation et le journal des événements.
  • Test de l’interface utilisateur : testez le package lorsqu’il est installé avec tous les niveaux d’interface utilisateur possibles. Testez le package installé sans interface utilisateur et avec toutes les informations fournies via l’interface utilisateur. Vérifiez l’accessibilité de l’interface utilisateur et si l’interface utilisateur fonctionne comme prévu pour différentes résolutions d’écran et tailles de police.
  • Test de maintenance et de réparation : testez que le package peut gérer les mises à jour correctives et les mises à niveau proposées par une petite mise à jour, une mise à niveau mineure et des mises à niveau majeures. Avant de déployer le package, écrivez une mise à jour d’évaluation gratuite de chaque type et essayez de l’appliquer au package d’origine.
  • Désinstaller les tests : vérifiez que lorsque le package est supprimé, il ne laisse aucune partie inutile derrière lui-même sur l’ordinateur de l’utilisateur et que seules les informations appartenant au package ont été supprimées. Redémarrez l’ordinateur de test après avoir désinstallé le package et vérifié l’intégrité des outils système courants et d’autres applications standard. Vérifiez que le package peut être supprimé par les utilisateurs dans tous les contextes de privilèges possibles. Testez toutes les méthodes pour supprimer le package, cliquez sur le fichier .msi, essayez les options de ligne de commande et essayez de supprimer le package du panneau de contrôle. Activez Journalisation Windows Installer pour chaque test et corrigez toutes les erreurs trouvées dans le journal du programme d’installation et le journal des événements.
  • Test des fonctionnalités de produit : vérifiez que l’application fonctionne comme prévu après l’installation, la réparation ou la suppression du package.

Corrigez toutes les erreurs de validation avant de déployer un package d’installation neuf ou révisé.

Exécutez la validation du package sur un package Windows Installer neuf ou révisé avant d’essayer de l’installer pour la première fois. La validation vérifie la base de données Windows Installer afin de détecter des erreurs de création. Toute tentative d’installation d’un package qui ne satisfait pas aux critères de validation peut endommager le système de l’utilisateur.

  • Vous pouvez valider votre package à l’aide de Orca.exe ou de Msival2.exe. Les deux outils sont fournis avec le SDK Windows. Les fournisseurs tiers peuvent également intégrer le système de validation ICE dans leur environnement de création.
  • Vous pouvez utiliser l’ensemble standard d’évaluateurs de cohérence interne (ICE) inclus dans les fichiers .cub fournis avec le Kit de développement logiciel (SDK) ou personnaliser la validation en créant un ICE et en l’ajoutant au fichier .cub.
  • Vous pouvez utiliser le fichier Evalcom2.dll afin d’implémenter l’automatisation de la validation pour les packages d’installation et les modules de fusion.

Créez une installation sécurisée.

Suivez ces recommandations lors du développement de votre package pour maintenir un environnement sécurisé pendant l’installation.

Utiliser PMSIHANDLE au lieu de HANDLE

Les variables de type PMSIHANDLE sont définies dans msi.h. Il est recommandé que votre application utilise le type PMSIHANDLE, car le programme d’installation ferme les objets PMSIHANDLE à mesure qu’ils sortent de l’étendue, tandis que votre application doit fermer les objets MSIHANDLE en appelant MsiCloseHandle. PMSIHandle fournit un opérateur de cast à MSIHANDLE pour la compatibilité des signatures d’API.

Par exemple, si vous utilisez du code tel que le suivant :

MSIHANDLE hRec = MsiCreateRecord(3);

Remplacez-le par :

PMSIHANDLE hRec = MsiCreateRecord(3);