Windows Installer et la création de WiX

je veux juste ajouter un peu plus spécifique informations techniques sur la technologie Windows Installer lui-même, et certains de la histoire menant à la création de la boîte à outils WiX depuis ce post peut être trouvé par des gens qui se trouvent juste dans le domaine des installateurs, WiX et Windows Installer.

il s'agit d'une introduction rapide à WiX et MSI à partir d'un point de vue du développeur . Il y a aussi un peu populaire serverfault.com article qui pourrait être utile pour saisir les avantages de L'installateur de Windows: les avantages pour l'entreprise de l'utilisation des fichiers MSI " (de nombreux développeurs n'aiment pas Windows Installer, mais les avantages du déploiement d'entreprise sont en fait assez important - peut-être vaut-il la peine d'un coup de pouce si vous pensez que MSI est plus de problèmes qu'il ne vaut la peine).

L'origine de la WiX boîte à outils

les fichiers MSI sont essentiellement des bases de données SQL Server stockées sous la forme de COM - fichiers de stockage structurés. c'est le format de fichier utilisé dans Microsoft Office (notez que MS Office utilisé pour utiliser OLE / COM fichiers - mais les nouvelles versions utilisent maintenant Office Open XML ), et il a été conçu comme un moyen de stocker des données hiérarchiques au sein d'un seul fichier. Essentiellement un système de fichiers dans un fichier avec des flux de stockage de différents types - dont l'un est les fichiers à installer à l'intérieur d'un ou plusieurs cab files .

au début, les fichiers / bases de données MSI ont été le mieux modifiés directement en utilisant des outils tiers tels que InstallShield , Advanced Installer et Wise Package Studio (plus disponible en raison de problèmes juridiques - voir une comparaison des outils MSI actuellement disponibles ).Ces outils stockaient le fichier MSI dans son format natif "installable" comme un fichier de stockage structuré COM. Cela signifiait que votre fichier MSI était à la fois source et exécutable - et en format binaire. Cela a rendu difficile le contrôle à la source de votre projet d'installation. Diffs binaires sur différentes bases de données MSI étaient difficiles, et en raison de la base de données intégrité référentielle même les plus des changements fondamentaux dans le MSI se répercuteront à travers des douzaines de tables et il sera difficile de voir ce qui a changé, même pour les yeux formés.

WiX est venu comme un moyen pour les développeurs de permettre la création d'un fichier MSI binaire à partir de fichiers source de texte réguliers. tout comme un binaire EXE régulier, un binaire MSI est" compilé " à partir de fichiers Wix text XML. Il s'agit d'un quantum leap en termes de gestion de votre processus de libération et de comprendre les changements dans le fichier MSI. La boîte à outils est très complète et beaucoup plus intuitive pour un développeur et présente un certain "automagique" en ce qu'elle protège le développeur de certaines des complexités du schéma de base de données MSI puisque les changements sont faits dans un format XML avec son propre schéma et pas la base de données elle-même. en effet WiX prend MSI de ses origines de base de données dans l '"âge XML" d'aujourd'hui afin que les développeurs travaillent avec des fichiers texte, et les fichiers MSI peuvent être considérés comme des exécutables compilés comme par opposition aux fichiers sources de la base de données.

il est en fait possible de faire de bons fichiers MSI sans en savoir trop sur le fonctionnement interne du fichier MSI - à condition que vous suiviez les meilleures pratiques de WiX - et croyez-moi en tant que développeur, vous voudrez rester en dehors des fichiers MSI. Ils sont complexes, et typiquement peu orthodoxes et contre-intuitifs pour un État d'esprit développeur. Cela a à voir avec la complexité de stocker un installateur entier comme un seul la base de données. Elle est presque entièrement déclarative et non procédurale - mais certaines parties sont séquentielles et définissent l'ordre d'installation. Beaucoup de pièces mobiles et une horloge de " complexité conspiratoire " (gotchas que vous découvrez comme vous pensiez que tout allait bien).

ces constructions de séquençage sont quelques-unes des parties les plus complexes d'un MSI impliquant " droits élevés "et les opérations du système de fichiers fonctionnent comme une base de données opération . Quand vous apprenez MSI comme un développeur, vous êtes lié à sentir que "quelque chose ne va pas avec ce design", et la vérité est que l'ensemble de la technologie a été conçu autour des exigences de déploiement pour le bureau à l'époque - et il est devenu aussi complexe qu'il devait l'être. En outre, les fichiers MSI peuvent être un aperçu des choses à venir - peut-être Windows utilisera SQL Server comme sa solution de stockage principale à l'avenir, et MSI est la première étape dans la déploiement dans un" langage déclaratif " ou une énorme déclaration SQL pour ce qui va se passer sur le système cible pendant le déploiement? Ce n'est que spéculation.

Certaines pratiques WiX avis

Keep it simple, suivez les meilleures pratiques et quoi que vous fassiez, ne pas lutter contre la conception qu'il se bat . Si WiX ne peut pas le faire, il est probable qu'il essaie de vous aider à éviter les problèmes de déploiement. Luttez contre votre manager pour simplifier ou changer exigences, pas MSI - pour une fois c'est plus facile :-).

la plupart du temps, nous trouvons que les conceptions de configuration inhabituelles et l'utilisation d'actions personnalisées causent beaucoup de complexité inutile, ou déploiement anti-patterns si vous aimez , et le problème peut souvent être évité par petits changements dans la conception de l'application , ou l'utilisation des constructions MSI intégrées . Un bon manager permettra des efforts pour simplifier le déploiement, mais ils doivent comprendre pourquoi il est nécessaire. J'aime licence comme un exemple de comment vous pouvez faire les choses différemment et de déploiement de plus simple en évitant à l'ancienne ou inutilement compliqué d'application et de déploiement des solutions.

éviter les actions personnalisées inutiles (lire/écrire) à tout prix - elles quadruplent la complexité et le risque d'une configuration. Demander ici sur le débordement de la pile et la recherche pour voir s'il y a une alternative intégrée. Dans la plupart des cas, ou du moins dans de nombreux cas, il existe des concepts intégrés équivalents dans MSI pour faire le travail.

ce conseil particulier ne peut être surestimé . À mon avis, actions personnalisées en lecture seule (qui peut définir des propriétés) sont le contraire: ils sont recommandés. Ils ne causent pas de risque supplémentaire important dans la plupart des cas - les changements sur le système nécessitant le soutien de roll - back, et peuvent être utilisés très efficacement pour rassembler la logique de configuration dans un seul endroit-et de manière cruciale ils fonctionnent bien entre collègues pour permettre de ramasser le travail de l'autre lorsque écrit dans des langages de script simples tels que JavaScript (certains aspects clunky en traitant avec L'API MSI) ou VBScript (mauvaise gestion des erreurs et des fonctionnalités générales de langue, mais bien testé avec le MSI API. Franchement, il semble que Microsoft essaie de "tuer" le langage. JavaScript est au moins "vivant et bien" dans l'usage lourd pour le web-stuff).

pour récapituler les choses en ce qui concerne les scripts: il y a un accord général parmi les spécialistes de déploiement que les actions de script de tous types sont en général difficile à déboguer , vulnérable à l'interférence antivirus et manque de caractéristiques linguistiques nécessaire mettre en œuvre des constructions de codage avancées. en conclusion: il est difficile d'écrire du code robuste avec des scripts - de tout type. code Managé des actions personnalisées sont possibles.NET), mais en raison de leur exigence .NET installé, le coffre-fort de la recommandation est d'écrire des actions personnalisées en C++. Cela permet des dépendances minimales, un très bon Débogage et des constructions de langage avancées. Il y a une longue "discussion" sur cette question ici: pour et contre de différents types d'action personnalisée (pas grand, juste un dump d'expérience réelle). Il pourrait être utile de faire une petite analyse - les actions sur mesure sont la principale cause des échecs de déploiement (lien vers ma propagande contre eux), et cela nous amène au point suivant: la complexité globale du déploiement (et comment y faire face).

La Complexité de Déploiement

Déploiement est le processus complexe de la migration hétérogène ordinateurs cibles à partir d'un état stable à un autre, ce qui requiert un approche disciplinée puisque:

1. les erreurs sont de nature cumulative - vous causez souvent plus de problèmes plus vous essayez de corriger les choses avec une solution rapide. Bientôt vous disposez d'une impossibilité de maintenir sur vos mains, puisque le problème est généralement dans la "nature" (publié) et doit être traitée comme un processus de livraison - chaque itération avec sa propre, risque, et pas seulement un seul problème pour déboguer jusqu'à ce que vous avez un correctif.
2. les Erreurs sont extrêmement difficiles à déboguer quand vous avez pas d'accès au système en question . La journalisation peut aider quand elle est faite correctement, mais elle n'est souvent pas livrée quand vous en avez besoin pour le débogage, ou elle est dans le mauvais format ou verbosité, ou tout simplement inutile tout à fait puisque les actions personnalisées souvent ne consignent pas les choses correctement.
3. les systèmes cibles (et l'environnement cible) diffèrent à peu près de toutes les manières imaginables (c'est le cas, même s'il s'agit d'un environnement d'exploitation standard (SOE) que la plupart des entreprises utilisent avec des installations et des paquets OS normalisés): différences de matériel et de pilotes (grands et petits), gros client / client léger, serveur de terminal, plate-forme OS (x86/x64 / etc...), Version OS (Win7, Win10, WinXP,etc...), Édition du système d'exploitation (ultime, la maison, etc...), La version du langage OS, l'état de mise à niveau de L'OS et le niveau de correctif, la situation de logiciels malveillants, les problèmes d'espace disque, le schéma de partitionnement, les types de système de fichiers, les problèmes de cryptage (système de fichiers, réseau), la configuration des droits de l'utilisateur, la configuration UAC, la configuration des privilèges système ( NTRights ), le type de connexion, la vitesse de connexion, la configuration réseau (domaine, groupe de travail, etc...), sous-compensation, proxy configuration, système de messagerie et configuration (Exchange, Outlook, Novell, etc...), active directory, authentication scheme, network shares and drives, application estate, scripting quantity, scripting lock-down, all kinds of runtime versions (C, C++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, scripting runtimes), enregistrement et configuration des objets COM et DCOM, serveurs COM+, IIS et web, variables de chemin et variables environnementales, associations de fichiers et opérations shell, configuration du logiciel sans fil, Nombre de utilisateurs, versions et configuration. net, paquets de langues, état et configuration Gac et WinSxS (fichiers de politique), pare-feu logiciels, systèmes émulés / virtualisés, système de déploiement (SCCM, Tivoli, etc...). Il va sur et sur.

le déploiement est un concept simple, avec un mélange compliqué de variables qui peuvent causer les erreurs les plus mystérieuses - y compris le favori du développeur: le bogue intermittent . Comme nous le savons tous la la gravité de tels bogues ne peut pas être surestimée car ils sont souvent impossibles à déboguer correctement.

plus sur le déploiement et ce qu'un programme d'installation moderne pourrait avoir besoin de faire: Quel est l'avantage et le but réel de l'installation du programme? . Ceci est un résumé des tâches qu'une configuration peut être nécessaire de faire parsemé de divers détails techniques. Trop de détails ont pu être ajoutés, peut-être détruire la "qualité d'aperçu" de la réponse. Toutefois, l'intention est de rester pertinent pour les développeurs.

---

Liées MSI Outils

Un Visual Studio MSI fichier de projet est une lumière-poids moyen de créer un fichier MSI partie de Visual Studio, et il a été extrêmement limité dans ses fonctions. Il y a eu des discussions pour remplacer le type de projet MSI au sein de Visual Studio par un projet Wix XML, et ceci est généralement la façon dont les gens construisent leurs fichiers MSI maintenant. Ne pas utiliser ce type de projet. Il a causé de graves problèmes pour de nombreux utilisateurs en raison de son manque de flexibilité et de bogues graves.

Orca est le Windows SDK outil qui permet aux fichiers binaires MSI à être ouvert, édité et à un certain degré comparé. Il a été en fait écrit principalement par l'homme qui a créé plus tard le Wix toolkit lui-même. Rob Mensching alors qu'il travaillait dans L'équipe Windows Installer à Microsoft . L'outil permet également d'autres opérations telles que la génération de fichiers transform pour modifier les fichiers MSI et d'autres opérations techniques. Bien qu'il s'agisse d'un outil très basique sans la plupart des fonctionnalités avancées disponibles dans les outils commerciaux, il reste un application packager favorite à utiliser et avoir Disponible pour débogage et petits correctifs en raison de son fiabilité , simplicité et " propreté "- il n'ajoute pas" junk par défaut " à un MSI lors de son enregistrement (outils tiers ajouter des tables personnalisées et similaire junk). Je l'utilise pour petites mises à jour MSI , débogage , inspection du flux récapitulatif , la création de "151920920 de base" transforme , affichage des patchs , paquet de validation , et d'autres opérations importantes.

en fait, je suppose que c'est un outil avancé, avec une interface simple - et pas un outil de base du tout :-). Pour mettre la main sur Orca, vous devez installer le Windows SDK " (!). Un peu plus haut vraiment lorsque la taille de l'outil est si petit, mais au moins, il est facile de savoir où il est disponible, plutôt que de chasse pour un téléchargement séparé.

UPDATE : si vous avez Visual Studio et le SDK installé, recherchez Orca-x86_en-us.msi et installez-le. Si ce n'est pas le cas, peut-être qu'un ami de Visual Studio a installé search for it et vous l'a envoyé? C'est un fichier de petite taille.

il existe aussi d'autres outils gratuits disponibles comme décrit ici (vers le bas): Comment puis-je comparer le contenu de deux (ou plus) fichiers MSI?

DTF - Deployment Tools Foundation est une suite de classes .NET pour traiter les fichiers MSI de façon programmatique. Bien écrit, facile à utiliser et très puissant il est maintenant inclus avec le téléchargement principal de WiX . C'est un composante essentielle dans tout projet de automatiser des entreprises de MSI fichier. Voici une brève réponse sur serverfault.com discuter de son utilisation et décrire ses composants de base. Le fichiers d'aide inclus avec DTF vous permettra d'aller rapidement avec la boîte à outils, et vous ne regarderez jamais en arrière à l'aide des fonctions Win32 ou des classes COM pour accéder aux fichiers MSI.

Il ya beaucoup d'autres outils D'installateur de Windows sur le marché, et certains d'entre eux, vous pouvez trouver par rapport à WiX à quel produit d'installation utiliser? InstallShield, WiX, Wise, Advanced Installer, etc (même lien que ci-dessus).