Quels sont les avantages d'utiliser des fichiers .msi par rapport aux fichiers setup.exe habituels?

J'ai l'impression que le déploiement est plus facile sur les ordinateurs sur lesquels les utilisateurs disposent de peu d'autorisations, mais ne sont pas certains des détails.

Quelles sont les fonctionnalités de msiexec.exe qui facilitent le déploiement par rapport à l’utilisation de scénarios setup.exe?

Des conseils ou des astuces lors du déploiement d'applications .msi?

Quelques avantages:

• Peut être annoncé (afin que l'installation à la demande puisse avoir lieu).
• Comme les publicités, les fonctionnalités peuvent être installées dès que l'utilisateur essaie de les utiliser.
• La gestion des états étant conservée, Windows Installer permet aux administrateurs de savoir si une application est installée sur un ordinateur.
• Possibilité de revenir en arrière si une installation échoue.

Je pense que lorsque je déploie un logiciel dans une entreprise: déployer un logiciel via MSI est presque agréable. En revanche, je crains presque toujours de déployer un logiciel dans un autre conteneur.

Pour des informations supplémentaires sur la manipulation des installations MSI, tapez msiexecdans la boîte de dialogue Exécuter.

MISE À JOUR, juillet 2018 : Un résumé extrêmement compressé des informations ci-dessous est disponible sur stackoverflow: Les principaux avantages de MSI ( "executive summary"- de la sorte).

J'ai travaillé dans le développement en tant que responsable des versions , ingénieur de construction , développeur d'installation , et en tant qu'emballeur d'applications et ingénieur de déploiement dans de grandes entreprises.

Ceci est une revue des meilleures (et des pires) caractéristiques conceptuelles et du monde réel de MSI. Les problèmes de conception les plus courants rencontrés dans les fichiers MSI sont présentés dans une réponse distincte ci-dessous . Ne pas prétendre être complet - vraiment juste un "dépotoir" en désordre - conçu comme "ce genre de choses qu'on ne trouve pas dans les livres" (probablement pour une bonne raison)

Je souhaite également suggérer que cet article MSDN soit une bonne lecture: Windows Installer: avantages et implémentation pour les administrateurs système .

Standardisation:

En un mot, MSI concerne la normalisation et la gestion des " odeurs de déploiement " des technologies d’installateur classiques . Toute une collection de mauvaises conceptions d'architecture d'installation qui ont causé des problèmes de déploiement répétés.

Globalement, MSI fournit un programme complet et normalisé pour l’installateur, qui inclut également les fonctions et options de désinstallation et intégrées pour une exécution silencieuse avec une interface graphique standard pouvant être déclenchée à distance .

Ces fonctionnalités représentent à elles seules une amélioration considérable par rapport aux technologies d’installation antérieures qui traitaient la désinstallation et le fonctionnement silencieux de manière aléatoire. C’est peut-être les fonctionnalités les plus importantes pour le déploiement en entreprise, avec la gestion fiable des packages à distance via Active Directory ou des outils d’administration à distance dédiés tels que Microsoft SCCM (anciennement SMS), IBM Tivoli , CA Unicenter et similaire.

Quelqu'un a dupliqué une version antérieure de cette réponse . Peut-être une lecture plus rapide?

Anciens installateurs "Odeurs de déploiement"

MSI décourage activement les odeurs de déploiement héritées par conception. Ces sujets sont abordés dans les sections suivantes, mais voici une liste rapide des problèmes les plus reconnaissables avec les programmes d’installation hérités et les technologies de déploiement plus anciennes:

• 1) ils ont parfois déclassé et écrasé des fichiers partagés et versionnés avec peu d’inquiétude pour l’ enfer de la DLL qui en résultait
• 2) souvent, la procédure de désinstallation fournie avec l’installateur n’était pas correcte, ou elle ne s’effectuait pas correctement et de manière fiable, en particulier si elle était exécutée en mode silencieux. C'est un très gros problème pour la gestion des entreprises d'État
• 3) l' installation silencieuse était rarement prise en charge correctement. La fiabilité était médiocre et il fallait souvent enregistrer une exécution de l'installation avec des sélections de boîte de dialogue, ce qui ne permettait pas de faire face à des conditions inattendues, telles que des boîtes de dialogue d'erreur ou d'avertissement qui n'étaient pas enregistrées lors de l'exécution d'origine.
• 4) le programme d’installation n’a gardé aucune trace de ce qui était installé et il n’existait donc aucun moyen automatique de vérifier les fichiers sur le disque afin de vérifier s’il s’agissait toujours des versions installées à l’origine par le programme d’installation.
• 5) ils comportaient des paramètres de ligne de commande imprévisibles, non fiables et non standard pour l'exécutable de l'installation
• 6) suite à une ligne de commande non standard et à l'absence de normes, il était difficile de personnaliser les installateurs avec des valeurs spécifiques nécessaires au déploiement en entreprise de manière fiable et prévisible
• 7) Les utilisateurs normaux ne pouvaient pas exécuter ces installations et il leur arrivait souvent de perdre leur temps avec des droits d'administrateur temporaires (utiliser "exécuter comme" si cela suffisait ou se connecter en tant qu'administrateur, installer puis se déconnecter - cette connexion complète et la génération de profil était parfois nécessaire pour que l’installation se termine)
• 8) le setup.exe installateur ne souvent pas renvoyer un code d'erreur approprié ou un code de succès, et il lui arrivait de sortir immédiatement et coup d'un autre processus qui terminerait l'installation il est difficile de déterminer si l'installation a été achevée - en particulier par l' intermédiaire d' un lot fichier
• 9) la plupart des fichiers setup.exe ont permis d'extraire des fichiers, mais pas de manière fiable et prévisible - vous avez généralement dû passer beaucoup de temps à trouver les bons commutateurs pour le faire.
• 10) L’ exploitation forestière était généralement médiocre et plutôt aléatoire dans certains outils. Le débogage avec les fichiers journaux produisait rarement de la clarté, mais aidait un peu
• 11) il n'y avait aucune transparence dans ce que faisait le programme d'installation et aucune annulation ou peu fiable pour annuler les modifications après une installation échouée
• 12) il n’existait aucun moyen standard de l’industrie de déployer des composants d’exécution partagés, qu’il s’agisse de composants de système d’exploitation, de composants tiers ou des vôtres

La liste continue avec de nombreuses autres failles de déploiement cruciales et reconnues . C’est bien évidemment dans le monde du déploiement en entreprise que ces problèmes sont apparus le plus souvent. Cela a abouti au métier de « reconditionnement d’application », dans lequel un programme d’ installation hérité est capturé avec les technologies d’analyse de disque et de registre afin de créer un fichier MSI conforme aux normes. pour un déploiement fiable.

Le reconditionnement d’applications est un travail de spécialiste. Il permet généralement d’obtenir des fichiers MSI d’excellente qualité s’il est correctement effectué par des spécialistes , mais il n’est pas possible de reconditionner toutes les applications en raison de la logique d’enregistrement complexe qui doit être exécutée de manière interactive pour que certaines applications fonctionnent.

Avantages MSI - Résumé court

En clair, les avantages les plus importants de MSI sont (sans ordre particulier):

• 1) la désinstallation est toujours disponible pour chaque paquet, sauf s'il est désactivé activement
• 2) il en va de même pour la journalisation , ce qui est excellent et standardisé, bien que verbeux (des outils tels que WiLogUtl.exe peuvent être utilisés pour analyser les fichiers journaux)
• 3) ce qu'un fichier MSI fait est (semi) transparent ou "inspectable" pour la plupart. L'exception concerne les actions personnalisées - (voir la section sur la transparence ci - dessous)
• 4) la personnalisation de l'installation se fait de manière standardisée ( transforme )
• 5) il n’est pas nécessaire de jouer avec les droits d’administrateur temporaires puisque l’installation s’effectue de manière élevée via une publication Active Directory, une stratégie de groupe ou une administration à distance. Quelques qualifications ici. Reportez-vous également à cette capture d'écran de l'éditeur d'objets de stratégie de groupe.
• 6) L’ installation / désinstallation silencieuse à l’aide d’outils de gestion ou à l’aide de msiexec.exe fonctionne bien
• 7) la prise en charge de l' annulation est complète pour les installations ayant échoué. Si vous installez manuellement sur la boîte, vous devez connaître certaines qualifications .
• 8) le fichier MSI se prête à la fois à l'inspection et à la validation pour des raisons de cohérence et de validité logique puisqu'il est conforme à un schéma de base de données ( voir exemple de validation )
• 9) les mises à jour sont des types normalisés, bien que complexes et souvent sujets aux erreurs pour les utilisateurs peu expérimentés
• 10) l’ extraction de fichiers à partir du MSI est une fonctionnalité intégrée (vérifiez l’article lié pour un bon aperçu rapide)
• 11) La ligne de commande de Windows Installer, msiexec.exe , offre un contrôle très détaillé de la manière dont la séquence d'installation doit être effectuée et toutes les options fonctionnent avec tous les fichiers MSI conformes aux normes (définir au niveau du journal, s'exécuter en mode silencieux / interactif / semi-silencieux). , définissez les paramètres d’installation, appliquez les transformations, etc.).
• 12) Les modules de fusion constituent le mécanisme MSI permettant de livrer des fichiers partagés avec plusieurs packages MSI. Il s'agit d'un module consommable ou d'un ensemble de logique d'installation fusionnable avec n'importe quel package MSI au moment de la compilation. Wix a étendu et amélioré ce concept en utilisant les fichiers Wix include - un concept qui, à mon avis, est supérieur à la fusion de modules - en particulier pour vos propres fichiers (c'est-à-dire non les fichiers OS)
• 13) le moteur d’installateur Windows comporte lui-même un mécanisme permettant d’ empêcher l’écrasement des fichiers versionnés ou modifiés lors de l’installation. Ceci est contrôlé par une logique de remplacement de fichier assez complexe . Bien que efficace et efficace, la logique peut devenir un problème en soi, car de nombreux développeurs sont confrontés au problème de ne pas pouvoir écraser leurs fichiers de configuration modifiés lors de la mise à niveau. La solution à ces problèmes consiste généralement à apporter des modifications mineures à la conception des applications afin d'éviter les anti-modèles de déploiement courants , bien qu'il s'agisse d'une discussion importante.

Dans le monde réel , j'ai trouvé des aspects moins réussis d'inclure rapiéçage (très complexe), MSI-GUI (Caractéristiques simples, assez complexes, manque de souplesse), la résilience (peut causer difficile de debug répéter les problèmes d' auto-réparation ), et la complexité globale pour traiter avec la technologie pour les débutants (grande complexité des opérations de base parfois - par exemple, les mises à niveau, l'interface graphique et les nombreux détails en interaction provoquent des résultats inattendus, etc.). La rapidité du processus d’installation a également considérablement ralenti en raison de l’augmentation des frais généraux de MSI. Voir quelques astuces pour améliorer la vitesse d'installation de MSI .

Le reste du texte traite plus en détail de certains de ces aspects de la RSM.

Transparence (format d'installation ouvert)

Un fichier MSI est essentiellement une base de données SQL-Server simplifiée, stockée sous la forme d'un fichier de stockage structuré par COM , essentiellement un système de fichiers dans un fichier ou une collection de flux de données. Il s’agit du type de fichier utilisé dans les documents Microsoft Office . Il en résulte un format standard pouvant être revu et inspecté - un problème de taille pour les grandes entreprises.

À l'exception des actions personnalisées compilées, un fichier MSI est une boîte blanche . Si la configuration change quelque chose de fou, tel que les paramètres réseau à l’échelle du système, vous pouvez le voir à l’ aide des outils appropriés . L'exception notable est les actions personnalisées compilées - qui sont une boîte noire . Les exigences du logo Windows nécessitent que des actions personnalisées soient annotées pour expliquer ce qu'elles font, mais cela est souvent ignoré par les développeurs d'installation. J'espère que l'avènement de Wix améliorera cela.

Pour déterminer ce que ces actions personnalisées compilées font réellement sur le plan technique, une capture de configuration est nécessaire. Ceci est rarement fait dans mon expérience. Il est plus courant de contacter le fournisseur pour obtenir des informations si le logiciel doit être approuvé pour le déploiement en entreprise. Il peut alors s'agir de l'application elle-même qui empêche son utilisation, et pas seulement de la configuration.

Personnalisabilité (transforme)

Un fichier MSI peut être personnalisé via des transformations pour répondre aux besoins et aux normes d'une entreprise tout en permettant une interopérabilité avec les mises à jour du programme d'installation du fournisseur. Vous ne modifiez pas le programme d'installation lui-même, vous créez votre personnalisation dans un fichier distinct, spécifique à l'organisation, appelé transformation (fichier .mst) (un fragment de base de données ou une transaction de modification, si vous le souhaitez). Vous êtes libre de désactiver les actions personnalisées et, en règle générale, de modifier, de remplacer ou de désactiver tout élément du programme d'installation. Vous pouvez même ajouter de nouveaux éléments, y compris des fichiers. Les fichiers de transformation sont également parfois utilisés pour localiser un fichier MSI dans différentes langues. Plusieurs transformations peuvent être appliquées à un seul MSI, voici un exemple avec des chemins tronqués :

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Explication rapide du paramètre:

/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.

Gestion et reporting

Windows Installer maintient une base de données complète de tous les éléments qu'un produit a installés dans le registre ( HKEY_CLASSES_ROOT \ Installer - ne changez jamais rien directement ici! Cela vaut aussi pour les experts).

Vous pouvez déterminer de manière fiable si un produit est installé, quelles fonctionnalités ont été installées et quelles versions de fichier ont été installées. De plus, vous pouvez obtenir une liste des correctifs éventuellement appliqués au produit de base. Vous pouvez accéder à cette base de données via des API prenant en charge Win32, COM ou .NET à l' aide de divers outils de script, de configuration et d'administration tels que Microsoft SCCM , IBM Tivoli , CA Unicenter, etc.

Sécurité (droits élevés temporaires)

MSI comprend également des principes de «droits élevés» qui permettent à un utilisateur restreint de déclencher l’installation d’un produit nécessitant l’installation de droits d’administrateur. Cela fait partie de la " fonctionnalité de publication " qui permet à un administrateur de mettre les installateurs à la disposition des utilisateurs sans les installer réellement sur tous les postes de travail. Le programme d'installation lui-même doit être créé correctement sur plusieurs comptes principaux pour que ce concept de droits élevés fonctionne correctement. Les utilisateurs peuvent déclencher eux-mêmes l’installation du produit, ou bien l’installation peut être contrôlée par un système de déploiement dédié tel que SCCM, Tivoli, Unicenter (les grandes entreprises en général). Il n'est pas nécessaire de jouer avec les droits d' administrateur temporaires pour faire fonctionner les choses ce qui est souvent le cas avec les installateurs hérités.

La base de données d'installation complète garantit également que vous disposez d'une vue d'ensemble complète des correctifs installés et donc d'une possibilité de détecter les vulnérabilités de sécurité via des outils d'automatisation et d'administration.

Validation

Les fichiers MSI peuvent être vérifiés avec des règles de validation pour s’assurer qu’ils respectent un certain nombre de règles de cohérence interne (appelées ICE).). Les entreprises peuvent créer leurs propres contrôles ICE pour appliquer des règles et des exigences spéciales. Cela aide grandement avec QA. La raison pour laquelle la validation est possible est due à la nature auto-référencée des bases de données relationnelles et du schéma de base de données associé. La base de données doit être cohérente en interne et conforme à son propre schéma en ce qui concerne les clés étrangères, les types de données, la largeur du champ, la version du schéma, etc. La validation va également au-delà et est capable de détecter les failles et les erreurs logiques réelles du paquet. , pas seulement le formatage et les défauts de type. Par exemple, il peut détecter des fichiers ou des types de fichiers en cours de déploiement vers des destinations cibles erronées.

Résilience (auto-réparation)

La fonction d' installation admin du programme d'installation de Windows fournit un moyen standard d'extraire les fichiers source d'un fichier MSI ( voici des informations supplémentaires sur ce sujet ). Ces fichiers sources peuvent ensuite être placés sur un partage et être disponibles pour tous les postes de travail pour l'installation. Cela garantit que les opérations de réparation, de désinstallation et de modification sont terminées sans demander le support d'installation sur CD ou similaire. Ceci est particulièrement important pour les opérations de correction et de mise à jour pouvant nécessiter un accès aux fichiers sources des anciennes versions dans des circonstances particulières.

Il existe également des problèmes courants liés à cette fonctionnalité de résilience. La plupart des administrateurs ont expérimenté des machines avec des cycles d'auto-réparation cycliques qui semblent ne jamais s'arrêter. Suivez le lien pour une longue liste de causes de ce problème. Et encore une fois, voici une version plus courte qui pourrait être plus facile à lire.

Retour en arriere

L'installation d'un fichier MSI déclenchera normalement la création d'un point de restauration . En outre, tous les fichiers et éléments de registre remplacés ou écrasés lors de l'installation seront sauvegardés et restaurés en cas d'échec de l'installation, à l'exception des modifications apportées dans les actions personnalisées.

Les actions personnalisées doivent implémenter leur propre prise en charge de l'annulation pour la conformité du logo Windows. Ceci est souvent ignoré, mais implique la création d'une deuxième action personnalisée pour annuler les modifications apportées par l'action personnalisée principale.

La restauration garantit que le poste de travail reste dans un état stable, même en cas d'échec de l'installation. Le script d'annulation réel est stocké dans un dossier caché directement sur le lecteur système - généralement C: \ Config.MSI - et contient des fichiers avec les extensions .RBS et .RBF - Fichiers de script d'annulation . Comme vous vous en doutez, les fichiers MSI mal conçus peuvent violer les fonctionnalités intégrées de Windows ici. Consultez mon autre article dans ce fil de discussion pour plus de détails.

Il existe des moyens de désactiver la restauration et d'accélérer l'installation. Non recommandé en général, mais voici des détails sur les propriétés MSIFASTINSTALL et DISABLEROLLBACK . Ceci est une fonctionnalité compliquée, mais voici un aperçu rapide des restaurations .

Mise à jour et correctifs

Bien que très complexe, les correctifs dans le programme d'installation Windows sont entièrement gérés et enregistrés sur le système, ce qui permet de déterminer l'état de sécurité du système en vérifiant ce qui a été installé. Les mises à jour sont normalisées selon quelques variantes de base, ce qui permet d'effectuer les mises à jour avec un degré de certitude supérieur, à condition que vous soyez en mesure de gérer la complexité impliquée. Les systèmes de déploiement pourront signaler les mises à jour ayant échoué et pourquoi.

Dans une vue subjective, l'application de correctifs fonctionne bien pour 2 utilisations de base : 1 ) de petits correctifs pour les produits livrés, et 2 ) l'application d'un correctif à un produit installé pour corriger sa séquence de désinstallation défectueuse empêchant une désinstallation propre du produit.

Un correctif est simplement un mécanisme de livraison pour une mise à jour qui fonctionne déjà . En tant que tel, il s’agit simplement d’un conteneur qui est plus compliqué et sujet aux erreurs que la configuration initiale elle-même. La règle numéro un pour un correctif est qu'il doit être plus petit que le MSI d'origine ou il n'y a aucune raison évidente de fournir un correctif. Un correctif peut devenir énorme rapidement s'il cible plusieurs versions du produit.

Journalisation (en effet verbeuse)

Windows Installer fournit une fonctionnalité de journalisation normalisée , bien supérieure aux versions précédentes, bien que très verbeuse. Les fichiers journaux peuvent être déchiffrés à l'aide d'analyseurs de journaux et des niveaux de journal personnalisés peuvent être utilisés pour éviter de générer des fichiers journaux trop volumineux contenant des informations inutiles. À des fins de débogage, la journalisation détaillée est extrêmement utile. Consultez le blog de Rob Mensching pour une méthode manuelle efficace pour lire un fichier journal MSI (vous devez essentiellement rechercher " valeur 3 " dans le fichier journal). Voici un exemple de ligne de commande qui effectue une journalisation détaillée:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

Cet article de Robert Macdonald de l’équipe Windows Installer est vivement recommandé. Il offre un aperçu pratique de la journalisation MSI: Comment interpréter les journaux Windows Installer .

Conclusion

Tout ne va pas bien pour Windows Installer . Sa complexité peut parfois être déconcertante , mais pour les grandes entreprises, les fichiers MSI sont nettement supérieurs à toute autre forme de déploiement lorsque l’on prend en compte la liste des avantages ci-dessus.

Nouveau paradigme de l'installateur (l'énorme instruction SQL)

Pour comprendre le nouveau " paradigme ", il est important de comprendre que MSI est conçu comme une description déclarative de ce qui va se passer sur le système cible, plutôt que comme une séquence d'événements fixe. Je suppose que vous pouvez y voir une énorme instruction SQL . Par exemple, vous déclarez les éléments que vous souhaitez ajouter ou modifier dans un fichier INI. Au fur et à mesure que l'installation s'exécute, les modifications sont suivies et une restauration est disponible afin que les modifications puissent être annulées en cas d'échec de l'installation. Cela fonctionne vraiment comme " automagique ", et est fiable quand c'est bien fait.

Actions personnalisées (les suspects habituels)

C’est un casse-tête énorme pour les développeurs MSI expérimentés de voir des personnes s’appuyer sur des actions personnalisées complexes et peu fiables pour une fonctionnalité mieux mise en œuvre avec les fonctionnalités MSI intégrées. Une part importante de toutes les erreurs MSI et de tous les problèmes d'annulation est provoquée par des actions personnalisées erronées, et la plupart des autres erreurs sont causées par une utilisation erronée de la conception MSI (voir la réponse séparée pour la liste des erreurs MSI courantes).

Outre les fonctionnalités MSI intégrées, de plus en plus de fonctionnalités personnalisées sont désormais disponibles via un nouveau framework, tel que Wix - la méthode XML de compilation des fichiers MSI. La logique complexe des actions personnalisées est donc de moins en moins nécessaire.

MSI offre un support complet pour la gestion de la fusion des paramètres de fichier ini, des polices, des variables d’environnement, des clés de registre, des informations COM, des raccourcis, des extensions de fichier, des conditions de lancement, de l’installation de GAC, ODBC, etc.

WIX va encore plus loin avec la prise en charge de fonctionnalités très avancées telles que les extensions serveur SQL, les installations et la configuration IIS, les compteurs de performance, la vérification DirectX et autres tâches liées au jeu, la génération d’images natives .NET, COM +, les pilotes, les règles de pare-feu, les extensions PowerShell, la fermeture des applications, gestion des utilisateurs, des groupes, des partages et bien plus encore. Un peu compliqué à gérer, mais beaucoup plus fiable que vos propres actions personnalisées.

Évitez les actions personnalisées à tout prix si possible

Pour essayer de le mettre en perspective: ces intégrés et des solutions prêtes à l'emploi sont faites par les meilleurs experts de déploiement disponibles , et ils sont testés par des milliers, des dizaines de milliers voire des millions d'utilisateurs (pour intégré des choses dans MSI lui-même). Pensez-vous réellement pouvoir faire mieux vos propres actions personnalisées? L'utilisation d'une action personnalisée doit être un événement rare, et il est absolument nécessaire d'obtenir quelque chose d'unique pour le produit que vous installez . Et vous devez également écrire le support de restauration approprié, ce qui est très compliqué.

Écrire une action personnalisée est presque toujours une erreur , mais il existe de véritables cas dans lesquels vous avez également besoin de flexibilité. Comme toujours, il est important de bien choisir ses batailles. Cela peut sembler amusant au début, mais vous devrez probablement faire face à de nombreux problèmes inattendus et perdre beaucoup de temps coûteux. Je veux dire cela très sérieusement. J'ai moi-même écrit une série d'actions personnalisées C ++ à l'intention des entreprises (afin d'éliminer les actions personnalisées VBScript sujettes aux erreurs). le raccordement à un fichier MSI est extrêmement compliqué. La recherche d’options prédéfinies disponibles vous épargnera probablement des semaines de travail de développement et vous apportera une fiabilité de déploiement bien supérieure.

Utiliser la séquence de lancement de l'application

Un point très important est qu’une grande partie de la configuration de l’application doit se produire au lancement de l’application lorsque le contexte d’exécution est prévisible et que la gestion des erreurs est bonne, et non dans la configuration exécutée une seule fois et comportant des fonctions très complexes d’ emprunt d’emprunt , de séquençage , de conditionnement et d’ exécution. la complexité .

Votre configuration ne doit pas configurer l'application, elle doit préparer l'application pour la configuration lors du premier lancement . En particulier, votre configuration doit écrire tous les paramètres nécessitant des droits élevés - écriture sur HKLM, enregistrement des services, installation sur des chemins par machine et toute chose qu'une application ne peut pas écrire seule avec des droits d'utilisateur normaux.

Si vous êtes un développeur d'installation, vous devez proposer de participer au codage de la séquence de lancement de l'application au lieu d'écrire des actions d'installation personnalisées . Si rien d'autre, afin d'éviter de ressembler, vous essayez de "passer la balle" à quelqu'un d'autre. Dans cette séquence de lancement, vous pouvez écrire du code beaucoup plus fiable et testable, ce qui facilite le test du personnel d’assurance qualité (souvent, il ne comprend pas les tests de déploiement ainsi que les tests d’application).

Complexité d'installation

Le coeur de la complexité de la configuration est centré sur le fait que les erreurs sont cumulatives (vous gérez un processus de livraison, pas seulement une recompilation rapide), les erreurs sont très difficiles à déboguer (aucun accès aux systèmes sur lesquels elles se produisent) et le système cible. les états diffèrent à peu près de toutes les manières imaginables . Reportez-vous à cette réponse pour une analyse plus approfondie de cette complexité et de la défiance redoutable des systèmes cibles: Windows Installer et la création de WiX, et The Complexity of Deployment (voir en bas).

WiX (meilleure solution MSI pour certaines utilisations)

Lisez cette brève introduction à WiX pour une description de la nouvelle méthode de compilation de fichiers MSI basée sur XML. Les fichiers source basés sur du texte offrent un contrôle de la source bien meilleur qu'auparavant. Ceci est un toolkit gratuit et open source fortement recommandé .

NB : Voir ailleurs dans le sujet pour un bref récapitulatif des problèmes de conception courants avec les fichiers MSI. Il est très incomplet, mais mérite une lecture. Je ne voulais pas ajouter cela à cette réponse car ce n'est pas lié à 100%, mais pour une utilisation dans le monde réel, c'est un sujet crucial.

Quelques informations MSI essentielles pour les administrateurs système:

(pardonnez la "promotion" éhontée - c’est pour un accès et une récupération faciles)

Voici quelques liens vers des rubriques pouvant aider les administrateurs système à contrôler le déploiement sur leurs réseaux:

• Comment puis-je éliminer les énormes fichiers MSI mis en cache dans C: \ Windows \ Installer? (utilisation élevée du disque par MSI)
• Comment accélérer les installations MSI (quelques options seulement)
• Comment extraire les fichiers de setup.exe (ça vaut le coup d'être lu par n'importe quel administrateur, probablement de vieilles nouvelles)
• Différentes façons de désinstaller un fichier MSI (référence de désinstallation, populaire - nombre élevé de vues)
• Comment contourner msiexec.exe lors de l'utilisation de packages MSI (automatisation et script MSI)
• Pourquoi MSI a-t-il besoin du fichier .msi d'origine pour procéder à la désinstallation? (question commune)
• Pourquoi la liste de processus contient-elle plusieurs processus msiexec.exe lors de l'installation? Que font-ils tous?

Sujets spéciaux:

• Forcer la mise à niveau d'un fichier modifié lors de son installation initiale (question fréquente)
• Existe-t-il un moyen de faire en sorte que msiexec fasse écho à stdout au lieu de se connecter à un fichier (rubrique avancée, utilisation d'un interface graphique externe pour MSI, davantage de contenu destiné aux développeurs)
• Je veux installer un MSI deux fois (l'instance se transforme ou virtualise - sérieusement :-)).
• Comment mettre à jour chaque profil d'utilisateur à l'aide d'ActiveSetup (un peu dangereux, mais utile)
• Erreurs courantes dans les packages MSI (plus pour les développeurs, mais aussi pour les administrateurs système)
• Comment déboguer l'auto-réparation cyclique (sujet important)

Sujets conceptuels / meilleures pratiques:

• Quel est l'avantage et le but réel de l'installation du programme? (bases de déploiement)
• Objet des installations administratives (opération MSI principale pour les administrateurs système)
• Pourquoi vous ne devriez pas utiliser MSI pour les réglages de registre (lecture recommandée)
• Quel produit d'installation utiliser? (Forces et faiblesses de différents outils)
• Pourquoi l'auto-inscription est considérée comme nuisible dans MSI

Cette réponse est vraiment un travail en cours et une ébauche. Les ajouts, questions et mises à jour sont les bienvenus. Cette liste n’est nullement exhaustive. Ajoutez un commentaire avec des informations sur les packages problématiques.

Problèmes typiques et défauts de conception observés dans les packages MSI

Je dois également avertir qu'un grand nombre de fichiers MSI contiennent des erreurs, parfois graves, mais les développeurs d'applications qualifiés pourront le détecter et dans la plupart des cas éliminer le problème. J'ajoute ceci en tant que réponse séparée car cela répond essentiellement à une question différente, mais j'estime que c'est pertinent dans le même fil.

Les détails techniques impliqués dans MSI sont très compliqués . Au niveau de base, il s’agit de décomposer vos fichiers et vos paramètres de registre en composants (installation atomique) et en fonctionnalités (éléments d’application à sélectionner par l’utilisateur à installer, par exemple une fonctionnalité de dictionnaire). Il existe un certain nombre de règles de meilleures pratiques pour la scission des composants, et les erreurs dans les fichiers MSI sont nombreuses. Ces erreurs sont généralement traitées en normalisant l'utilisation de "mises à jour majeures".

L'installation proprement dite s'effectue dans un certain nombre de séquences d'installation, certaines avec des droits élevés . Toutes ces choses sont définies dans des tables de base de données, et c’est là que MSI est terriblement compliqué à comprendre et à traiter. Les actions réparties dans les séquences d'installation sont des actions standard et personnalisées. Les actions standard sont conçues par Microsoft et doivent avoir lieu (la séquence peut parfois être modifiée). Les fournisseurs peuvent utiliser des actions personnalisées pour exécuter une logique personnalisée non couverte par MSI. Ceux-ci peuvent être sous forme de script ou compilés. Les actions personnalisées peuvent être immédiates (exécutées en une fois, ne doivent pas modifier le système, mais le sont souvent) ou différées (écrites dans un script d'exécution qui est ensuite exécuté en tant que transaction et supporte donc la restauration).

Les erreurs typiques dans une MSI sont (sans ordre particulier - et présentées comme un véritable gâchis):

• erreurs de création de composants (non-respect des meilleures pratiques). Cela peut poser des problèmes de correctifs et de mises à niveau avec des symptômes mystérieux tels que des fichiers et des paramètres manquants ou des correctifs qui bombardent d'erreurs insensées. Pour simplifier à l'excès, il faut utiliser un fichier par composant, sauf si le nombre de fichiers est énorme.
• problèmes de mise à niveau liés au remplacement ou à la réinitialisation des données utilisateur. Voir plus de détails ci-dessous.
• une planification incorrecte des actions personnalisées en dehors de la "section transactée" des séquences d'installation ou des actions personnalisées de type incorrect sont mal placées. Cela provoque souvent l'échec des actions (pas de droits élevés) lorsqu'elles sont exécutées à distance via des systèmes de déploiement et l'annulation est effectivement invalidée, car seules les actions traitées sont annulées. La transaction Windows Installer (pensez à la validation de la base de données think) s'effectue entre les actions standard InstallInitialize et InstallFinalize dans la séquence d'installation principale et s'exécute avec des droits élevés . Toutes les modifications du système doivent avoir lieu dans cette transaction - tout le reste est erroné (mais malheureusement assez commun).
• utilisation d'actions personnalisées en mode immédiat pour apporter des modifications au système en dehors de la séquence d'installation transactée . Cela annule la prise en charge de l'annulation et entraîne généralement des erreurs de sécurité, car les actions personnalisées en mode immédiat ne s'exécutent pas avec des droits d'utilisateur élevés, où qu'elles soient placées dans les séquences d'installation.
• les conceptions erronées qui entraînent des cycles répétitifs d’autoréparation sans raison évidente. Voici un autre article sur ce sujet, de installsite.org
• Les actions personnalisées qui n'obéissent pas à la suppression de l'interface graphique en mode d'installation sans assistance peuvent afficher des boîtes de dialogue modales provoquant l'échec complet du déploiement lors d'une exécution en mode silencieux. Ce problème, ainsi que la différence globale entre le mode silencieux et le mode interactif, sont décrits plus en détail ici (quelque peu prolixe et compliqué): La désinstallation du Panneau de configuration est différente de celle de Supprimer de .msi.
• Certaines actions personnalisées dans des packages créés à tort sont insérées uniquement dans la séquence de l'interface utilisateur . Cela les empêche de s'exécuter en mode d'installation en mode silencieux. Cela est grave pour le déploiement en entreprise car l'installation silencieuse est utilisée ici presque exclusivement. Ce problème peut également affecter la désinstallation, ce qui signifie que vous devrez peut-être exécuter la désinstallation de manière interactive pour assurer la désinstallation afin de garantir l'exécution de toutes les actions personnalisées de nettoyage. Encore une fois, voir le lien dans la puce précédente pour une description plus détaillée des niveaux d'interface utilisateur.
• l'installation contient des fichiers qui ne sont pas destinés à être déployés à l'emplacement d'installation. En règle générale, les fichiers système devant être installés côte à côte dans le dossier de l'assembly de winsxs.
• La lenteur de l'installation est un autre "problème" que beaucoup signalent avec MSI. Voici quelques conseils sur le sujet . Globalement, Windows Installer est un peu fastidieux en raison des nombreuses exigences d’enregistrement dans le registre pour ce qui est en cours d’installation.
• écrasement d'informations personnalisées ou de fichiers de données partagés . Cela peut arriver si un fichier INI est installé via la table File et pas la table IniFile par exemple. Dans ce dernier cas, il est traité comme une "transaction de modification". Dans le premier cas, il s’agit d’une opération de remplacement de fichier, qui est généralement fausse si votre fichier INI ne comporte pas de sections de formatage non standard ou de commentaires volumineux que vous souhaitez déployer avec votre fichier (commun pour certains fichiers). outils de développement).
• les règles complexes pour l'écrasement des fichiers peuvent entraîner l'écrasement involontaire des fichiers, voire même la non mise à jour du tout - il s'agit d'un problème classique de MSI. Consultez cet article pour savoir comment forcer le remplacement d’un fichier qui ne sera pas mis à niveau . Les règles peuvent être légèrement modifiées par des paramètres personnalisés pour la propriété REINSTALLMODE définie au niveau de la ligne de commande msiexec.exe (écrasez les versions antérieures, écrasez les versions égales, écrasez toute version, etc.) et fonctionnent différemment pour les fichiers de données et les fichiers versionnés. Détails dans le SDK . Il est essentiel de comprendre cela, et cette conception est souvent mal vue, même lorsqu'elle est comprise.
• L'enregistrement automatique des fichiers COM lors de l'installation peut déclencher des avertissements de sécurité ou causer des problèmes de différentes manières. Consultez cet article: L’auto-inscription est considérée comme nuisible .
• Une variante du problème de remplacement de fichier est le cas lorsqu'une mise à niveau majeure (qui désinstalle et réinstalle le produit) désinstalle les fichiers modifiés et réinstalle les versions par défaut. Dans ces cas, le contenu semble renversé ou écrasé alors qu'en réalité, il a d'abord été désinstallé puis réinstallé.
• les services exécutant des informations d'identification d'utilisateur personnalisées risquent de perdre leurs informations d'identification lors de scénarios de mise à niveau importants, ainsi qu'un fichier de paramètres (semblant ressembler) à rétablir les valeurs par défaut (ils ont été réellement désinstallés et réinstallés). Pour mémoire, à mon avis, les services fonctionnant avec des informations d'identification d'utilisateur sont un défaut de conception.
• les propriétés publiques ne sont pas correctement transmises du processus client au processus serveur, empêchant ainsi l'exécution des actions personnalisées comme prévu. Cela implique la mise à jour de la propriété SecureCustomActionProperties.
• Certaines applications ne peuvent pas fonctionner correctement pour d'autres utilisateurs que celui qui a installé le programme d'installation à l'origine. Il s'agit d'une grave erreur de conception, mais peut généralement être corrigée par des concepteurs d'applications expérimentés utilisant l' auto-assistance ou ActiveSetup pour ajouter des clés de registre HKCU et des fichiers userprofile . C'est un sujet assez complexe et peut nécessiter un peu d'art noir pour travailler. Pour mémoire: la vraie solution, à mon avis, est de modifier l'application elle-même pour pouvoir initialiser tous les paramètres par utilisateur en fonction des paramètres par défaut et des modèles copiés à partir d'un emplacement par machine ou en fonction des paramètres par défaut internes de l'application (à partir du code source).
• Certains fichiers MSI gâchent la sécurité des fichiers installés en définissant des droits de lecture / écriture complets pour les non-administrateurs ici, là et partout. D'autres fois, l'application cesse de fonctionner sur les versions les plus récentes de Windows en raison d'un manque d'autorisations. Les développeurs d'applications doivent souvent analyser les besoins en autorisations personnalisées d'une application. En règle générale, une autorisation supplémentaire est requise dans HKLM ou quelque part dans% ProgramFiles%.
• Certaines configurations d’ Installshield du jour essayaient de se connecter à Internet pendant l’installation. C'est horrible pour les scénarios de déploiement en entreprise où le déploiement est étroitement contrôlé, et le programme d'installation ne sera jamais autorisé à télécharger du nouveau contenu directement à partir d'Internet.
• Un autre problème de réseau réside dans le fait que les installations essaient d’afficher une interface graphique dans laquelle les utilisateurs saisissent des données validées sur Internet au fur et à mesure de leur installation ou simplement pour afficher du contenu en direct à partir de leur site Web. Il s'agit généralement d'adresses e-mail, d'informations de contact, de clés de licence, etc. La connexion peut échouer complètement pour de nombreuses raisons, souvent en raison de la configuration du proxy manquante dans les environnements d'entreprise (il n'y a pas de connexion directe à Internet, tout le trafic Internet est acheminé via un serveur de cache spécifique et chaque processus doit fournir des informations d'identification pour passer à travers le pare-feu). . Voici un article sur les dangers de la validation des licences via la configuration .
• Installshield utilisé pour installer un runtime pour son langage InstallScript . Cette configuration préalable était généralement incluse dans le fichier setup.exe et constituait une source légendaire de problèmes . Il existait de nombreuses versions, plusieurs incompatibilités et un certain nombre d' erreurs d'exécution . Depuis la version 12 (ou à peu près), ce runtime est maintenant installé de manière fiable et compile en natif ou fonctionne en mode bac à sable (je ne suis pas sûr de savoir lequel, ou probablement - probablement bac à sable) de manière fiable. Les configurations Installshield plus anciennes peuvent toutefois afficher ce problème de déploiement. Il existe un site de support hérité d'Installshield pour des problèmes tels que ceux-ci: http://consumer.installshield.com/common.asp
• Plusieurs configurations peuvent afficher un comportement d'installation irrégulier ou des bogues intermittents lorsqu'elles sont exécutées sur des machines configurées pour une langue autre que l'anglais, ou même lorsque vous exécutez des versions localisées (traduites) de configurations sur des machines anglais. Cela peut être purement une défaillance d'exécution ou des cas où les boîtes de dialogue localisées comportent du texte coupé, un formatage erroné ou une traduction incorrecte, ou de nombreux autres types d'erreurs liées à la localisation linguistique.- tout un domaine d'expertise en soi (traduction de texte en images, traduction du logiciel lui-même, traduction de supports marketing, traitement des demandes d'assistance internationales, adaptation aux paramètres linguistiques du système d'exploitation, etc.). Certaines langues nécessitent que l'ensemble de l'application soit modifié pour tenir compte de leurs particularités. Les problèmes typiques sont les macros de chaîne et les paramètres de page de code, ce dernier étant moins un problème avec l'introduction de Unicode. Voir un exemple de capture d'écran d'un outil de traduction .
• Presque toutes les configurations échouent à plusieurs des tests de validation intégrés disponibles pour tester la qualité des packages MSI. Voir cet article pour un exemple pratique de validation.
• Parfois, les mises à niveau échouent pour un MSI en raison du fait que seuls 3 chiffres du numéro de version du MSI sont réellement vérifiés lors des analyses de mises à niveau majeures.
• L'installation des fichiers INI est une fonctionnalité intégrée de Windows Installer. Les entrées peuvent être ajoutées, supprimées, fusionnées ou traitées de la manière requise. Cependant, il est assez courant que les fichiers INI soient installés en tant que fichier au lieu de valeurs segmentées. Cela peut entraîner le remplacement du fichier INI lors de la réinstallation, au lieu de le mettre à jour. Un problème de MSI très commun.
• Le problème ci-dessus concerne également les applications .NET et leurs fichiers Config.xml. Dans ce cas, MSI N'A PAS de méthode intégrée pour mettre à jour le contenu de manière détaillée et vous devez coder la mise à jour via une action personnalisée ou remplacer le fichier entier lors de l'installation. Wix peut avoir de nouvelles fonctionnalités pour cela, mais le moteur Windows Installer n’a pas cette fonctionnalité intégrée.

Il y a un certain nombre d'erreurs plus subtiles et plusieurs problèmes plus grands et typiques que j'aurai oubliés.

Consultez l' article relatif aux meilleures pratiques Windows Installer de MSDN .

L'utilisation de MSI facilite également l'application de correctifs (fichiers MSP) et les mises à niveau. MSI utilise le concept de codes de produit et de mise à niveau uniques, ce qui facilite l'ensemble du processus.

Certains systèmes de déploiement (CA Unicenter Software Delivery en est un exemple) peuvent également comprendre les MSI de manière particulière, ce qui leur permet de mieux s'intégrer au système de déploiement. Par exemple, vous pouvez insérer un fichier MSI dans la bibliothèque de logiciels du système de déploiement. Il détectera automatiquement les différentes fonctionnalités du produit et autorisera automatiquement des actions personnalisées beaucoup plus granulaires (installation locale, vérification, réparation, etc.) et la journalisation.

L'auto-guérison / réparation est également un atout majeur pour les MSI.

Découvrez également le programme d' installation Windows source XML , un ensemble d'outils qui crée des packages d'installation Windows à partir d'un code source XML. Cet ensemble d'outils prend en charge un environnement de ligne de commande que les développeurs peuvent intégrer à leurs processus de création pour créer des packages d'installation MSI et MSM. MS l'utilise pour préparer plusieurs de ses principaux packages logiciels.

vous pouvez effectuer des transformations - en théorie, vous pouvez personnaliser beaucoup de choses; si le programme est correctement emballé par le fournisseur, vous pouvez effectuer un déploiement entièrement automatisé sans aucune interaction avec l'utilisateur final - ce qui est très utile lorsque vous souhaitez normaliser votre environnement Windows et disposer de plusieurs des ordinateurs.

pour voir ce que les gens font avec msis [ou un déploiement sans surveillance], visitez par exemple ce site et ses forums.