Quelle est la meilleure pratique de génération de composants MSI?

Question

Visual Studio Installer indique qu'il est conseillé d'installer chaque fichier en tant que composant d'installation. L'utilitaire de chauffage fourni avec Wix semble également suivre la pratique de mettre chaque fichier dans son propre composant. L'assistant de composant d'InstallShield utilise la meilleure méthode d'installation de InstallShield pour placer des fichiers exécutables portables dans leur propre composant mais groupe tous les autres fichiers (par exemple, les fichiers non versionnés) par le dossier de destination commun. L'avantage de la pratique un (chaque fichier dans son propre composant) est que chaque fichier est configuré comme un fichier clé qui est important si vous voulez que ces fichiers déclenchent des réparations. Cela permet également de faciliter l'automatisation de la création des composants (par exemple, la chaleur) puisque vous créez un composant pour chaque fichier. Les inconvénients de la première pratique incluent la gestion de nombreux composants et la prolifération du registre après l'installation de l'application.

Un avantage de la pratique 2 peut être vu dans une installation qui installe des centaines de fichiers graphiques dans un répertoire. Si vous ne vous souciez pas de la fonctionnalité de réparation, y a-t-il une raison de créer des centaines de composants pour cette installation?

Ces 2 pratiques différentes sont contradictoires et je veux savoir lequel des gens utilise réellement et pourquoi.

Answer 1

J'utilise toujours l'approche Microsoft (quelque chose de semblable à ce que InstallShield fait): http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx

Je pense qu'il est le meilleur parce que: - fichiers importants (EXE, DLL, etc.) ont leur propre composant, de sorte qu'ils peut être réparé facilement - les fichiers de ressources sont regroupées - permet un des composants optimaux comptent (pas trop pour obtenir une longue installer, mais assez pour permettre une réparation facile)

J'ai aussi remarqué que la plupart des outils de création de configuration commerciale utiliser cette approche.

Answer 2

J'ai écrit à ce sujet dans le passé et je vais essayer de trouver un lien vers celui-ci. Je pense que vous comprenez déjà la question et qu'il est temps pour vous de décider ce qui est important pour vous. Pour moi, je travaille sur des installations avec plus de 15 000 fichiers et nous effectuons uniquement des mises à jour majeures. Pour "Program Executables" nous suivons les principes 1: 1 (un must pour COM, Services, ShortCuts et ainsi de suite) mais pour les fichiers de contenu/données, nous faisons un à plusieurs sans approche de fichier clé pour réduire notre nombre de Composants. Bien sûr, cela signifie que nous ne serons pas en mesure de créer un MSP qui ne gère qu'un ou deux fichiers de contenu ici et là, mais pour nos besoins métier qui ne sont tout simplement pas importants pour nous.

La résilience était un peu un mot de 4 lettres à nous donc avoir moins de fichiers clés nous rend plus heureux de toute façon. :-) BTW, VDPROJ rend également chaque clé de registre un fichier clé de son propre composant et cela a été assez douloureux pour nous de déclencher des réparations inutiles. Tout cela mis à part, pour ceux qui ne comprennent pas tout cela, je m'en tiens au schéma 1: 1 jusqu'à ce que vous tombiez sur une situation où vous ne voulez plus et vous comprenez l'impact de faire ce choix.