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.

[corwin]

Moi j'aime bien les choses simples ... donc de d�ployer toutes les dll non-syst�mes utilis�es par le programme avec lui. Les MSI sont faits pour �a.

ok mais justement si c'est bien rang� c est simple enfin c'est mon point de vue pour retrouver mes petits.
Mais j'en suis pas au stade du d�ploiement l� je d�couvre VC et je j'essaye de faire un pauvre hello world linker sur une dll qui ne d�pend pas de moi.

Du coup j'ai deux projet : un qui reg�n�re la dll dans un coin et l autre mon executable de test (le hello w).
Apr�s je veux juste pouvoir executer le hello dans VC et que ca marche sans d�placer cette fichu dll.

Pour le d�ploiement je verrais plus tard. Et si c'est conseill� de mettre la dll avec l exe ok. Moi cela me va mais ca c'est pour la phase d'install je verrais ca dans plusieurs mois � mon avis . Je note pour les MSI je suppose que cela correspond a un package avec les instruction d'install comme les rpm/deb dans le monde *nix.

Bref mon pb aujourd hui est de comprendre les multiples option de VC6 pour maitriser ce que je g�n�re. Du coup je pense que je risque de vous poser d'autre question de p'tit nouveau.

[bacelar]

ok mais justement si c'est bien rang� c est simple enfin c'est mon point de vue pour retrouver mes petits.

Moi, je trouve qu'avoir le r�pertoire system32 avec des milliers de dll copi�es � l'arrache (sans prendre la peine de v�rifier qu'une version plus r�cente y est d�j�, et sans ajouter au compteur d'utilisation de cette dll par une application dans la base de registre) ou avoir une variable d'environnement PATH avec ces centaines de chemins vers des r�pertoires de projet qui n'existent plus ou qui ne sont valides que sur la machine d'un des dizaines de d�veloppeurs du projet; c'est tr�s tr�s moyen.

Votre configuration est le cas typique d'un projet Windows.
Imaginez que vous deviez copier � la main la Dll apr�s chacune de ses g�n�rations dans system32.
Imaginez que vous deviez changer votre variable PATH � chaque nouveau projet, et sur les machines de tous les d�veloppeurs.

A votre configuration typique, il existe au moins une solution des plus simples et �l�gantes.

Je n'ai plus de VC++6.0 depuis bien des ann�es. Il est obsol�te depuis au moins 12 ans et plus support� par M$ depuis belles lurettes.
Sur les versions r�centes de Visual Studio, on peut d�finir des d�pendances entre des projets d'une solution Visual Studio. VS analyse le type des projets et copie automatiquement le r�sultat de la compilation d'un projet Dll (donc la Dll en Debug ou en Release, c'est selon) dans le r�pertoire utilis� par le projet d�pendant pour y stocker l'ex�cutable.
Donc la manipulation se r�sume � indiquer � VS, via des commandes dans le menu contextuel, que votre projet exe d�pend du projet Dll. ET C'EST TOUT.

Si VC++6.0 n'impl�mente pas les d�pendances de projets (ce qui m'�tonnerais, de m�moire) ou que son m�canisme de d�pendance ne sert qu'a inf�rer l'ordre de compilations des projets, il reste une solution de compensation pour arriver au m�me niveau de fonctionnalit�.

Les projets VC++6.0 disposent de la fonctionnalit� de BuildEvent.
C'est simplement la possibilit� d'indiquer des commandes CMD(~ shell d'*nix)
juste avant et juste apr�s la g�n�ration/compilation du projet.

Vous pouvez donc facilement ajouter une commande de copie de la Dll g�n�r�e en Post-Build Event de votre projet de Dll ou en Pr�|Post-Build Event de votre projet de l'application.
Dans ces "scripts", vous disposez de toutes les "variables" n�cessaire pour qu'ils soient simples et r�sistants aux changements/fluctuations de configuration. (Debug vs. Release, chemin vers le r�pertoire du projet, de la solution, nom des fichiers g�n�r�s etc.)
La copie syst�matique d'une Dll en fin de compilation dans un r�pertoire d'un autres projets de la solution se fait en UNE ligne.(et cela quelque soit la configuration Debug/Release ou le r�pertoire de la solution)

Donc mon approche est bien une solution de feignant atteint au dernier stade d'Alzheimer.
C'est aussi l'approche impl�ment�e par les versions r�centes de VS (quand il est utilis� correctement).

Apr�s je veux juste pouvoir ex�cuter le hello dans VC et que ca marche sans d�placer cette fichu dll.

Moi, c'est mieux, c'est VS qui d�place la derni�re version de la Dll, et la bonne (Debug/Release), � l'endroit qui va bien.

Je note pour les MSI je suppose que cela correspond a un package avec les instruction d'install comme les rpm/deb dans le monde *nix.

Tout � fait.

En plus, les outils de cr�ations de MSI qu'y s'int�grent � VS savent r�cup�rer ces informations de d�pendances et s'en servir pour g�n�rer un MSI avec toutes les Dll n�cessaires.

Et si c'est conseill� de mettre la dll avec l exe ok.

Pour les Dll non syst�me, oui, c'est la r�gle.

Pour le d�ploiement je verrais plus tard.

Vous vous diriger vers le syndrome "�a marche sur ma machine mais nulle part ailleurs". Le co�t de la mise en place d'un projet de g�n�ration d'un MSI est quasi nul (sauf pour la prise en main de l'outil, mais il sera de toute fa�on n�cessaire).

Moi cela me va mais ca c'est pour la phase d'install je verrais ca dans plusieurs mois � mon avis

Ce n�est pas tr�s "Agile" comme approche.
Il faut toujours tester tr�s t�t dans le processus de d�veloppement et le packaging est n�cessaire (et co�te quasi rien).

Pensez � utiliser VS2010 � la place de VC++6.0. Si vous n'utilisez pas les MFC, la version gratuite de VS2010, VS2010 Express est largement suffisante.
si votre code VC++6.0 est de bonne qualit�, il migrera facilement en VC++2010.
Essayez, cela ne coute qu'un Dll de la version Express ou d'une version d'�valuation de VS2010.

Utilisez les m�thodes �prouv�es que je vous indique, cela permettra une bien meilleure int�gration avec le reste des outils de l'�cosyst�me VS.

[corwin]

Oulala pas taper

je suis d'accord avec ton approche mais cela fait seulement 2 jours que je suis sous windows a jouer avec VC++. Oui je "joue" avant de faire le design de mon appli histoire de comprendre la philosophie des outils que j'utilise.
merci pour tes commentaires d'ailleurs.

Imaginez que vous deviez changer votre variable PATH � chaque nouveau projet, et sur les machines de tous les d�veloppeurs.

tout � fait d'accord entre temps je viens de trouver les options qui vont bien pour faire ce que je veux :
compilation des diff�rente dll dans les sous projet et d�ploiement dans un r�pertoire unique de tout le bazare.

Je n'ai plus de VC++6.0 depuis bien des ann�es. Il est obsol�te depuis au moins 12 ans et plus support� par M$ depuis belles lurettes.

C'est ce que l'on m'a dit mais mon client oblige a utiliser VC6 pour des probl�mes de compatibilit�. Ni connaissant rien en outil microsoft je le crois et je fais avec. J'ai aussi reagrd� du cot� d'�clipse pour utiliser seulement le compilo de VC6 mais eclipse ne g�re pas le debugguer du coup je reste sous VC6.

Sur les versions r�centes de Visual Studio, on peut d�finir des d�pendances entre des projets

Je cherche maintenant comment faire cela pour qu'il lance la compilation automatique des sous projet. Sachant que toute les sorties sont maintenant regroup�es au m�me endroit.

[EDIT]je viens de trouver menu project > dependencies [/EDIT]

Les projets VC++6.0 disposent de la fonctionnalit� de BuildEvent.
C'est simplement la possibilit� d'indiquer des commandes CMD(~ shell d'*nix)
juste avant et juste apr�s la g�n�ration/compilation du projet.

Ouaip j'ia vu l'option mais qaund on cr�er un nouveau projet on peux les faire d�pendre d'un autre. Du coup je suppose que l on peux ajouter une d�pendance apr�s la cr�ation mais je n'ai pas trouv� pour le moment.

Vous vous diriger vers le syndrome "�a marche sur ma machine mais nulle part ailleurs". Le co�t de la mise en place d'un projet de g�n�ration d'un MSI est quasi nul (sauf pour la prise en main de l'outil, mais il sera de toute fa�on n�cessaire).

Le truc c'est que ce n'est pas moi et ma boite qui g�re cela, et ce n'est pas mon job. Je n'intervient que pour livrer un exe qui utilise une ou deux dll. Le reste n'est pas de mon ressort. Je livre un d�monstrateur. La partie int�gration est largement secondaire dans ce projet. Le point critique �tant les algorithmes de traitement � impl�menter.

Ce n�est pas tr�s "Agile" comme approche.

Il faut toujours tester tr�s t�t dans le processus de d�veloppement et le packaging est n�cessaire (et co�te quasi rien).

Encore d'accord avec toi tu pr�che un convaincu. Perso je fait des tests sur mon code suivant la m�thode TDD, du packaging de l'int�gration continue et toute la sauce XP quand je suis linux mais l� c'est un cas particulier donc je fais avec. Donc pour ce projet il y aura seulement les tests. Je ne suis pas chef de projet je n'ai pas de pouvoir sur ce projet

Bon c'est pas tout ca mais je retourne a mon vieux visual.

a+

[camboui]

Un peu d'histoire, juste pour le plaisir

Win95 est sorti en 1995. Ce fut le premier OS "acceptable" de MS.
Il fut suivi par WinNT 4.0 en 1996.
VC++6.0 est sorti en 1997.
C'�tait la fin des ann�es '90 avec 2 �l�ments majeurs dans le d�veloppement de l'informatique: la peur du bug de l'an 2000 et l'adoption de masse de l'internet.

L'environnement de d�veloppement de VC++6.0 �tait tellement facile, fiable et innovant qu'il a tu� tous ses concurrents.
Pas �tonnant qu'il est eu un si grand impact dont l'effet se fait encore sentir aujourd'hui. Et ce n'est pas fini.
A mon avis il vivra tant que WinXP vivra.
MS a cess� de le supporter depuis octobre 2001.