Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Dll dans un répertoire différent de l'exe
Bonsoir à tous,
Développant en C++, je poste cette question ici mais peut être a-t-elle sa place ailleurs ...
Tout est-il qu'à l'heure actuelle mes dlls sont forcément dans le même répertoire que l'éxécutable, sous peine de voir une erreur "Dll [...] manquante".
Y'a-t-il un moyen pour séparer les répertoires ? l'idéal étant un répertoire "Mes Dlls" et un autre "Librairies externes utilisées" ...
Merci d'avance
JS
Bonsoir,
Si tu travailles sous GNU/Linux ou Mac, il y a le rpath qui permet de spécifier un chemin relatif à l'exe.
Sous Windows par contre, il n'y a guère d'autre moyen que de copier la DLL dans le dossier de l'exe ou bien de modifier le PATH.
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Bonsoir
Si il y a un moyen d'utiliser des DLL sans qu'il soient dans le même répertoireEnvoyé par Florian Goo
mais il faut qu'elle soient des DLL COM
If you type Google into Google, you Can break the internet" - The IT Crowd
Salut,
Oui c'est possible mais c'est un peu pénible à mettre en place, plus d'information dans Isolated Applications and Side-by-side Assemblies.
MAT.
Pas plus qu'une DLL normale. de plus une DLL com possède un identificateur unique ( GUID ) ce qui n'est pas le cas dans une DLL classique
If you type Google into Google, you Can break the internet" - The IT Crowd
Excuse-moi, je répondais directement à la question d'origine en fait.
MAT.
Si on la met dans le dossier windows/system32, il n'y a pas de problèmes non?
Ben si, il y a un problème: Tu as une DLL non-système dans system32.
C'est beaucoup plus sale que de modifier le path, et l'auteur aimerait bien ne pas avoir à la modifier...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Il faut arrêter avec ces bidouilles!
On ne devrait même pas pouvoir modifier ce répertoire, voire même tout le dossier Windows (oui, bon, dans certains cas on a pas le choix).
Qu'a-t-il de plus que n'importe quel autre dossier? Il est dans le PATH par défaut. Est-ce que ça nous donne pour autant le droit de le polluer?
Est-ce que tu vas mettre dans les dossier de Firefox des éléments de VLC par exemple?
Il n'y a que deux solutions qui ont déjà été évoquées ici:Si je ne dis pas de bêtise, un EXE va d'abord chercher dans son répertoire, puis dans les dossiers du PATH.
- Mettre les DLLs dans le dossier de l'exécutable
- Modifier le PATH et y rajouter le répertoire de la DLL
A mon sens il n'y a pas de plus ou moins bonne solution entre ces deux-là, ça dépend du contexte. Par exemple, si la DLL est seulement utilisé par le programme, il faut bien sûr la mettre avec l'EXE. Par contre, si elle est utilisée par plusieurs programmes qui n'ont rien à voir, mieux vaut la mettre dans un dossier "Commun" par exemple, et rajouter celui-ci au PATH.
Désolé, je m'enflamme un peu.
"L'ordinateur obéit à vos ordres, pas à vos intentions." [Anonyme]
C'est un peu plus subtil que ça, cf. Assembly Searching Sequence (Au passage on remarque que le PATH n'est pas listé).
Il y en a d'autres dont notamment : utiliser le système préconisé pour les placer dans le répertoire centralisé WinSxS (shared assemblies), écrire un manifest placé avec l'application pour indiquer où trouver les DLL (private assemblies), etc..
Mais oui, la solution la plus simple reste encore de placer les DLL avec l'application (ou démarrer l'application depuis le répertoire des DLL, plus malin que de bricoler le PATH).
MAT.
Attention, il y a une différence entre la recherche d'assembly et la recherche de DLL. Différence d'autant plus confuse quand les "unmanaged assemblies" s'ajoutent au mélange...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
C'est pas juste pour les LoadLibrary ça ?
MAT.
En fait, il me semble que c'est à la fois pour les LoadLibrary() et pour le chargement au lancement de toutes les bibliothèques n'étant pas des Unmanaged Assemblies (en gros, toute bibliothèque faite ou utilisée avec autre chose que "Visual 2005 ou supérieur").
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je ne comprends pas bien... Vous êtes l'auteur du programme principal? Dans ce cas, il suffit d'utiliser LoadLibrary. Si vous êtes l'auteur de la librairie et que vous voulez que vos utilisateurs puissent l'utiliser de n'importe où tout en l'installant dans votre propre dossier d'installation, il suffit de leur dire d'utiliser LoadLibrary, en leur filant un source d'exemple si vraiment besoin.
Si vous ne voulez absolument pas utiliser LoadLibrary (j'ai du mal à imaginer pourquoi, ça n'a que des avantages, en particulier la bonne coopération inter-langage et inter-compilateur), alors oui il faut sans doute sauter à la corde 3 fois autour du grand chêne une nuit de pleine lune, voire maitriser les assemblies side-by-side et autre patois MS sale.
"Maybe C++0x will inspire people to write tutorials emphasizing simple use, rather than just papers showing off cleverness." - Bjarne Stroustrup
"Modern C++11 is not your daddy’s C++" - Herb Sutter
Quel est l'intérêt de passer par LoadLibrary lorsque ce n'est pas nécessaire (pour faire un système de plugins par ex) ?
Tu lies absolument tout en statique peut-être ?
MAT.
Bonjour à tous,
Tout d'abord merci de m'avoir autant répondu.
Initialement cette question m'est venue car j'utilise des librairies extérieures (SDL, SFML ...) et je trouvais un peu dégueu d'avoir toutes les Dlls dans le même répertoire que mes Dlls maisons et mon Exe principal (question lisibilité).
A terme je ne suis pas sur que mon programme aille sur d'autres postes que le mien donc la modification du PATH pour y inclure les chemins vers les Dlls requisent me parait pas trop mal.
Pour info je lie statiquement les lib externes à mes projets, et mes Dlls "internes" sont utilisées via LoadLibrary.
Merci à tous pour vos réponses
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager