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.