quel est le diff entre les dépendances et ajouter manuellement une dll / ocx dans vs installer 6?

Question

J'utilise vs installer pour créer un package d'installation pour mon application vb6. et le problème, c’est que je peux voir que, dans l’explorateur de projets, il y a une liste de dépendances attachées à mon fichier exe.

texte alternatif http://img505.imageshack.us/img505/9696/croppercapture259lr8 .png

et sous le système de fichiers sur l'arborescence de la machine cible, je peux réellement stocker la dll / ocx dans un dossier ou dans le dossier système Windows lui-même [fenêtre de gauche].

texte alternatif http://img101.imageshack.us/img101/9224/croppercapture251qm1 .png

donc ce que je ne comprends pas, c’est .. y at-il réellement une différence? si je viens de définir les dépendances et que je n’ai pas ajouté la dll ou l’ocx au dossier ou que je ne gagne pas le dossier sys, la dll est-elle automatiquement copiée aussi?

Answer 1

Il n’est pas garanti que toutes ces dll seront présentes sur le système sur lequel le logiciel est installé. Ils doivent donc être inclus dans votre installateur. De là, vous avez deux choix.

Vous pouvez les installer dans vos dossiers système Windows ou dans votre dossier d'application. La différence est que si vous les installez dans votre dossier d’application, vous pouvez configurer XP et Vista de manière à ce que les différentes versions du logiciel avec une version différente des composants puissent être lancées et exécutées côte à côte. En les installant dans le dossier système, toutes les anciennes versions dépendant d'anciennes versions des composants seront supprimées.

L'installation dans le dossier de l'application ne fonctionne rarement si un composant dépend d'autres composants qui ne peuvent pas être mis à jour. Lorsque cela se produit, c'est généralement avec les bibliothèques Microsoft. Ils se sont améliorés au fil des ans sur cette question.

Pour en savoir plus sur les problèmes liés à l'exécution côte à côte, ici

Enfin, les dépendances doivent figurer dans votre programme d'installation pour pouvoir être enregistrées dans le registre Windows. Contrairement à la plupart des assemblages .NET, toute application ActiveX / COM doit avoir le composant enregistré pour pouvoir l'utiliser même si vous utilisez des types CreateObject et Variant pour y accéder.

Je reconnais que tout le processus est idiosyncratique et qu’il est l’une des sources des histoires sur DLL Hell. Commencez par l’article MSDN, utilisez wikipedia et, bien sûr, posez des questions supplémentaires ici.

Answer 2

En règle générale, vous ne devriez pas avoir de "DLL" " sous le dossier de l'application pour un package d'installation normal, mais de nombreux facteurs sont en jeu (DLL standard privées, COM Reg-Free, etc.). Oui, les dépendances sont incluses (sauf si vous les excluez ). Chacun doit avoir une propriété qui détermine l’emplacement où il est installé sur les systèmes cibles.

Vous avez également dans cette liste un certain nombre de composants qui ne sont pas redistribuables de cette façon, car il s'agit de composants système dépendants du système d'exploitation, de composants MDAC ou non licenciés à redistribuer (fm20.dll par exemple).

Malheureusement, il s'agit d'un exemple du type de package pouvant directement mener à DLL Hell pour les systèmes de vos utilisateurs. Pour résoudre ce problème, vous pouvez rechercher chaque composant MS dans les articles MS KB afin de déterminer ce qui peut ou devrait être redistribué et comment.

Le déploiement peut être une entreprise complexe pour réussir.