Changer mon composant GUID dans Wix?

Question

Quand devrais-je changer ou ne pas changer le GUID de mon composant dans WIX? Les informations du SDK de Microsoft sont source de confusion .

Modification de Glytzhkof : pour clarifier, la question porte sur le moment où un GUID de composant doit être modifié pour un composant MSI. Un composant peut changer avec des aspects tels que: chemin de destination modifié, ajout ou suppression de fichiers vers / depuis le même composant, ajout de données de registre, etc. Cela pose des problèmes en ce qui concerne le référencement de composant, c'est-à-dire bonne pratique pour la création de composants dans MSI.

Answer 1

  

Le concept global de MSI est qu'il existe une correspondance 1: 1 entre   un GUID de composant (identifiant unique) et un chemin absolu   (emplacement d'installation / chemin de la clé). Le chemin complet, y compris le nom du fichier si   tout. Voir la mise à jour ci-dessous pour une nouvelle fonctionnalité Wix à traiter automatiquement   avec cela.

J'utilise certaines règles simples pour traiter les règles de composant trop complexes et absurdes:

• Utilisez toujours un composant distinct par fichier (même pour les non-binaires). Cela évite toutes sortes de problèmes. Il y a quelques exceptions:
  • Les assemblys multi-fichiers .NET doivent tous appartenir à un seul composant, car ils doivent toujours être installés / désinstallés en tant qu'unité unique.
  • Quelques autres types de fichiers généraux viennent par "paires correspondantes" : ils appartiennent ensemble. Il s’agit souvent de fichiers de contenu et d’index. A titre d'exemple, considérons les fichiers d'aide de Microsoft:
    • Les fichiers .HLP et .CNT vont de pair.
    • Les fichiers .CHM et .CHI vont de pair.
  • Plusieurs types de fichiers de ce type vont probablement de pair et doivent donc être placés dans le même composant afin d'être installés / désinstallés ensemble. Je suspecte que certains fichiers de certificat soient candidats. Il est difficile de dresser une liste définitive. Demandez-vous simplement "ces fichiers appartiennent-ils toujours ensemble" - afin qu'ils apparaissent toujours par paires chaque fois qu'une nouvelle version est disponible? Si oui, installez-les via le même composant. Définissez le fichier versionné, le cas échéant, en tant que fichier de clé.
  • Je souhaite ajouter des fichiers de pilote à titre d'exemple de groupe de fichiers appartenant toujours ensemble: SampleDriver.cat , < code> SampleDriver.inf , SampleDriver.sys , SampleDriver.cer . Ils doivent tous correspondre en tant qu '"unité". pour le déploiement.
• N'oubliez pas qu'une fois que vous avez affecté un GUID à un composant, il est défini en pierre pour le chemin de clé de ce composant (chemin absolu). Si vous déplacez le fichier vers un nouvel emplacement ou le renommez, attribuez-lui un nouveau GUID de composant (puisque le chemin absolu est différent, il s'agit en réalité d'une nouvelle identité).
• Dans le résumé, les GUID des composants sont liés à un emplacement d'installation absolu et non à un fichier spécifique. Le GUID ne suit pas le fichier s'il se déplace . La référence GUID compte un emplacement absolu, pas le fichier en tant que tel.
• N'ajoutez ni ne supprimez de fichiers d'un composant existant. Il en résulte toutes sortes de problèmes de mise à niveau et de correction. C’est pourquoi j’aime un fichier par composant en règle générale.
• Il y a beaucoup plus dans le référencement de composants, mais je vais en rester là pour un "aperçu".

Quelques exemples:

• Vous renommez le fichier C: \ Program Files \ MonCompany \ MyApp \ MonFichier.exe en C: \ Program Files \ MonCompany \ MyApp \ MonFichier_NEW.exe . Qu'est-ce que cela signifie pour la création de composants? Comme il s’agit d’un nouveau chemin d’installation absolu, vous générez un nouveau GUID pour le composant d’hébergement, OU vous ajoutez un nouveau composant et supprimez l’ancien (qui a le même effet).
• Votre MSI mis à jour fournit une nouvelle version de MyFile.exe. L'emplacement est le même qu'auparavant, cela signifie que le GUID du composant ne doit pas changer. C'est le même fichier (identité), mais dans une version différente.

MISE À JOUR : WIX dispose désormais d'un nouveau GUID du composant à génération automatique : fonctionnalité qui calcule un GUID tant que le chemin cible reste le même. Pour être honnête, je n'ai pas essayé cette solution, mais beaucoup semblent l'utiliser sans problèmes, et Rob Mensching (auteur de Wix) déclare qu'il est sans danger pour une utilisation normale . En tant que concept, je le recommande vivement, car il comporte des fonctionnalités de magie automatique et vous préserve de la complexité.

Notez également que vous pouvez omettre de nombreux attributs source de votre fichier xix Wix et utilisez les valeurs par défaut de Wix au lieu des valeurs de codage strictes.

Answer 2

Vous ne changez jamais le composant / @ Guid. Vous ne modifiez jamais non plus l'ensemble des ressources (Fichier, Clé de registre, Raccourci, TypeLib, etc.) dans le composant. Lorsque vous avez une nouvelle ressource, vous devez créer un nouveau composant avec un nouveau @Guid. La partie vraiment délicate est que le nouveau composant ne peut pas avoir de chevauchement (chemin du fichier, ou chemin de la clé de registre, ou typelib, etc.) avec l’ancien composant.

Ce sont essentiellement les règles de composant, consultez: http: //robmensching.com/blog/posts/2003/10/18/Component-Rules-101 .

Answer 3

Consultez le didacticiel WiX, The Files À l'intérieur , pour une explication détaillée des règles relatives aux composants. En gros, cela signifie que vous ne modifiez jamais le GUID d'un composant, car cela signifie qu'il faut orphelin de l'ancien composant et créer un nouveau composant.