Version imprimable
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.
Bonsoir
Si il y a un moyen d'utiliser des DLL sans qu'il soient dans le même répertoireCitation:
Envoyé par Florian Goo
mais il faut qu'elle soient des DLL COM
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 classiqueCitation:
Envoyé par Mat007
Excuse-moi, je répondais directement à la question d'origine en fait.Citation:
Envoyé par buggen25
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...
Il faut arrêter avec ces bidouilles! :furieux:Citation:
Envoyé par coyotte507
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 :mrgreen:.
C'est un peu plus subtil que ça, cf. Assembly Searching Sequence (Au passage on remarque que le PATH n'est pas listé).Citation:
Envoyé par Spout
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..Citation:
Envoyé par Spout
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...
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").
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.
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