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

Question

J'utilise vs installer pour construire un package d'installation pour mon application vb6. et le problème est que je peux voir que sous l'explorateur de projet il y a une liste de dépendances attachées à mon fichier exe.

alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8.png

et dans le cadre du système de fichiers sur la machine cible TreeView, je peux effectivement stocker les dll/ocx sur un dossier ou dans le dossier Windows du système lui-même [la fenêtre de gauche].

alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1.png

donc ce que je ne comprends pas .. est-il vraiment une différence? si je viens de définir les dépendances et n'a pas ajouté le dll ou ocx dans le dossier ou le dossier win 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 programme d'installation. De là, vous avez deux choix.

Vous pouvez les installer dans vos dossiers système Windows ou dans le dossier de votre application. La différence est que si vous les installez dans votre dossier d'application, vous pouvez configurer les choses sur XP et Vista afin que la version différente du logiciel avec la version différente des composants puisse être allumée et exécutée côte à côte. Les installer dans le dossier système va casser toute version plus ancienne qui dépend de l'ancienne version des composants.

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, il est généralement avec les bibliothèques Microsoft. Ils se sont améliorés au fil des ans sur cette question.

Vous pouvez en savoir plus sur les questions concernant l'exécution côte à côte here

Enfin, les dépendances doivent être dans votre installateur afin qu'ils soient enregistrés dans le Registre Windows. Contrairement à la plupart des assemblys .NET, toute application ActiveX/COM doit être enregistrée pour pouvoir l'utiliser même si vous utilisez des types CreateObject et Variant pour y accéder. Je vais admettre que l'ensemble du processus est idiosyncrasique et est l'une des sources pour les histoires sur DLL Hell. Commencez avec l'article MSDN, utilisez wikipedia, et bien sûr posez d'autres questions ici.

Answer 2

Vous ne devriez généralement pas avoir un dossier "dlls" dans le dossier de l'application pour un paquet d'installation normal, mais il y a beaucoup de facteurs impliqués (DLL standard privées, COM sans Reg, etc.). Oui, les dépendances sont incluses (sauf si vous excluez eux). Ils devraient chacun avoir une propriété qui détermine où ils installent sur les systèmes cibles.

Vous avez également un certain nombre de composants dans cette liste qui ne sont pas redistribuables de cette façon car ils sont des composants système MDAC-dépendants ou des composants MDAC non autorisés pour redist (fm20.dll par exemple). Malheureusement, il s'agit d'un exemple du type de package qui peut conduire directement à DLL Hell pour les systèmes de vos utilisateurs. Corriger cela peut signifier rechercher chaque composant MS dans les articles MS KB pour déterminer ce qui peut ou doit être redistribué et comment.

Déploiement peut être une entreprise compliquée à faire correctement.