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.