Discussion :

[corwin]

Salut,

je débarque dans le monde windows en venant d'*nix. Et je sèche un peu sur un problème de configuration de visual c++ enfin je pense que c est un problème de conf.
Je suis entrain de faire un projet de test avec les MFC et celui si utilise une lib externe. Le projet compile par contre a l execution il me jette en me disant qu'il ne trouve pas la dll. J'ai beau cherché je ne voit pas ou je configure le chemin d'accès a la dll dans visual ?
Pour info la dll est déployé dans un répertoire de mon "home" je connais pas le terme sous windows et mon projet est dans le répertoire par défaut de visual sous programme file.
Es ce que j'ai loupé une optiond ans les ettings du projet ou dans les options (tool/options) de visual ?

merci d'avance pour votre aide.

(je sais pas si cela peu servir mais je suis sous XP, VC++6.0, SDK2003)

[mala92]

ton "home" n'est pas dans le PATH. Donc ton exe, s'il n'est pas dans ton "home" (c a d le meme répertoire que la dll), il ne la voit pas.

pour voir les problèmes de dépendances, je te conseille dependencies walker.

Quand tu parles d'exécution, tu fais quoi ?
tu lances l'exe (dans Windows) ou tu débugge ?

[corwin]

Je viens de modifier la variable PATH du compte plus celle du système. Et j'ai la même erreur : "Cette application n'a pas pu démarrer car toto.dll est introuvable"

Je démarre l'application depuis VC++ (menu build ou ctrl+F5)
La modif de la varaible d'environnement est valable immédiatement ou il y a une manip a faire sous XP ?

[corwin]

oula y a un truc que je ne comprend pas;
quand je lance l exe dans l explorateur ca marche mais pas dans VC++ ??

[EDIT]
ok j'ai relancé VC++ et ca marche.

merci pour le coup de main
[/EDIT]

[bacelar]

Le loader Windows utilise le DllPath (objet Kernel, pas variable d'environnement) pour trouver les fichiers des dll "statiquement lié" à l'exécutable lancé.
La variable d'environnement PATH fait partie des chemins utilisés par DllPath dont par le loader.

Les valeurs des variables d'environnement sont liées à un exécutable et ces valeurs sont héritées depuis le programme père (ayant lancé le programme courant).

Quand vous modifiez ces valeurs dans l'IHM du Windows, vous modifiez les valeurs pour le processus "explorer" en charge de la gestion du bureau Windows (il modifie aussi la base de registre pour qu'au prochain reboot, ces valeurs soient correctement renseignées).

Donc tous programmes que vous lancez depuis l'exploreur aura donc ces nouvelles valeurs dans les variables d'environnement.

Mais, si votre Visual Studio était déjà lancé lors des modifications des variables d'environnement, il n'aura que les valeurs correspondant à celles de l'"explorer" lors du lancement de VC++, donc les anciennes valeurs.

Il faut redémarrer VC++ pour que ces modifications soient prises en compte par VC++ et tous les outils qu'il lance (cf. héritage des valeurs au début du post).

Pour éviter toutes ces embrouilles, le plus simple est d'utiliser le fait que, par défaut, dans le DllPath, il y a le répertoire de l'exécutable ou le répertoire courant de l'instance de programme.

http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

Donc configurez votre projet VC++ pour que votre dll soit d'en l'un de ces répertoires.

[corwin]

Merci Bacelar pour les explications.
Je ne veux pas déplacer ma dll a coté de mon exe, j'aime bien ranger les choses
Du coup il me reste deux solutions si je comprend bien :
1) modifier le path pour y inclure le répertoire de la dll , c'est ce que j'ai fait actuellement, ca marche.
2) "le répertoire courant de l'instance de programme". Cela veux dire que dans le DllPath il y a le répertoire d'ou je lance l'exe. Donc je doit pouvoir dire a VC++ de lancer l exe de n'importe quel répertoire ? Cela correspond t il au "working directory" des project settings ?

[bacelar]

j'aime bien ranger les choses

Moi j'aime bien les choses simples et je n’aime pas le Dll Hell (le fait d'avoir des Dlls utiliser par plusieurs applications et que chacun installe leur versions différentes ou ne qui marchent pas avec d'autres versions que celles qu'elle installe).
Donc pour éviter ce merdier, le plus simple ; outre le déploiement en Side by side SxS et l'utilisation de manifeste faisant d'un simple Hello Word un projet de la NASA ; c'est de cloisonner chaque application et donc de déployer toutes les dll non-systèmes utilisées par le programme avec lui. Les MSI sont faits pour ça.

Cela correspond t il au "working directory" des project settings ?

Oui

J'insiste, en tant que développeur, vous devez maîtriser les dépendances en terme de dll de votre programme, et en faire un élément de votre projet VS permet de maîtriser leur monté de version et les mécanismes de déploiement.