utilisation d'une dll

bonjour à tous j'ai besoin de vos lumières concernant l'utilisation de dll sous c++,

afin d'utiliser les fonctions d'une dll, je l'ai tout d'abord ajouté dans un projet C# en tant que référence, mais problème:

"madll.dll could not be added. Please make sure tat the file is accessible and that it is a valid assembly or com component"

J'en ai conclu qu'il etait impossible de l'utiliser en C#.

J'ai ensuite essayé de charger la dll dans un projet C++, à l'aide de l'instruction "loadlibrabry"...

Mais voila le probleme c'est que je n'arrive pas a executer la fonction "execute()" qui se trouve dans la dll.

Pouvez vous m'aider ?

merci

Citation:

---

afin d'utiliser les fonctions d'une dll

---

Il y a plein de type différents de dll :
- ressource de localisation de programme
- composant COM
- assembly .NET
- bibliothèque de fonctions C chargeable dynamiquement
- bibliothèque de fonctions/classes C++ chargeable dynamiquement (mais c'est pourri).
- etc...

Il faudrait déjà savoir à quel type de Dll on a affaire.

Citation:

---

J'en ai conclu qu'il etait impossible de l'utiliser en C#.

---

Bin si, mais on n'utilise pas un composant COM ou un assembly .NET comme une bibliothèque de fonctions C.
On revient toujours à la même question : c'est quoi comme type de Dll.

Le plus simple, c'est de charger la dll dans dependency walker (http://www.dependencywalker.com/)pour voir ce qu'elle export et comment.

Citation:

---

J'ai ensuite essayé de charger la dll dans un projet C++, à l'aide de l'instruction "loadlibrabry"...

---

Ça, ça marche qu'avec des " bibliothèques de fonctions C chargeable dynamiquement", et encore, c'était bon il y 25 ans.
On fait plus comme ça depuis longtemps.
Votre dll est bien fournit avec un .h et un .lib, non ?
Si c'est fait par des sagouins peut-être pas, mais c'est toujours plus rapide et plus fiable de les recréer que de faire des "loadlibrabry" du précambrien de l'informatique.

Citation:

---

Mais voila le probleme c'est que je n'arrive pas a exécuter la fonction "execute()" qui se trouve dans la dll.

---

Alors, pas de _ devant et des parenthèses derrières, aucune fonction ne peut être exportée avec un nom aussi WTF.
Utilisez dependency walker pour voir le vrai nom de la fonction, si vous voulez toujours vous emmerder avec des "loadlibrabry".

merci pour tes explication, voici ce que j'ai pu trouver :

-il s'agit d'une dll COM
-j'ai utilisé le logiciel dependency walker et j'ai pu retrouver ma fonction "Execute" dans la liste (dans la colonne nommé E il y'a un carré gris avec un "C" à l'interieur.

Ça semble un peu particulier, votre machin. :weird:
Normalement, un composant COM "pur" ne dispose que de 4 à 5 fonctions C exportés et aucune ne se nomme "Execute".

Si vous n'avez qu'"Execute" comme fonction C, et pas les fonctions de COM comme 'DllGetClassObject" ou "DllCanUnloadNow" ou encore "DllRegisterServer", c'est que c'est une Dll avec une API C classique et non un composant COM.

Si vous avec "Execute" et les autres fonctions C de COM, vous êtes en face d'une Dll hybride COM/C.

Avec le "loadlibrabry" du précambrien de l'informatique, il utilise GetProcAddress qui est case-sensitive, donc si vous cherchez "execute" et que c'est "Execute" qui est exporté, ça le fera pas.

Mais franchement si vous pouvez esquiver ces cochonneries de "LoadLibrary" et "GetProcAddress" d'une autre ère, faites-le rapidement.
Trouvez les .h et lib associés à cette dll, où créez les de toutes pièces (si vous êtes un débutant, demandez à une personne expérimenté de vous les créer, car c'est rapide à faire quand on connait mais faut un peu maitriser le machin)

@bacelar: Franchement, je suis une personne expérimentée et pourtant je ne sais pas créer une lib statique d'importation (surtout une quoi soit correcte) juste à partir de la DLL...

@movlw: Si c'était une DLL COM, tu n'aurais pas dû avoir l'erreur "madll.dll could not be added. Please make sure tat the file is accessible and that it is a valid assembly or COM component". Si ta DLL n'exporte qu'une seule fonction, alors ce n'est pas une DLL COM.
Ce qui veut dire que tu dois pouvoir l'utiliser depuis C# en déclarant sa fonction avec l'attribut DllImport.

@bacelar: Tu craches sur LoadLibrary, mais comment tu charges dynamiquement une DLL de type plugin? C'est le genre de choses qui se fait plutôt couramment, les plugins, et si en plus on a la contrainte du multiplateforme (donc pas de COM ou d'assembly .Net)... J'aimerais donc savoir ce que tu préconises, dans ce cas là?

Si ta DLL est bien une DLL COM, il faut que tu l'enregistres avec "regsvr32.exe <Chemin Complet>\MaDll.dll" puis tu devrais pouvoir la trouver parmi les composants COM, lorsque tu veux l'ajouter en tant que référence (pour cela il te faut aussi connaitre l'espace de noms défini par ta DLL), si tant est que c'est bien une DLL COM traditionnelle, ce qui ne me semble pas être le cas...

Citation:

---

@bacelar: Tu craches sur LoadLibrary, mais comment tu charges dynamiquement une DLL de type plugin?

---

On n'a l’embarra du choix, les framework de plug-ins sont pléthores, même sans utiliser ceux offerts de base par Windows : COM, .NET, ou encore le delayloading :ptdr:

Citation:

---

et si en plus on a la contrainte du multiplateforme (donc pas de COM ou d'assembly .Net)

---

Parce que "LoadLibrary", c'est portable peut-être. :weird:
COM a été partiellement porté sur Mac et le XCOM de FireFox/Mazilla était assez proche de COM.
.Net a été porté sous Linux/MacOsX via le projet Mono.

Citation:

---

J'aimerais donc savoir ce que tu préconises, dans ce cas là?

---

Si c'est deu plug-Ins : utiliser un framework fait pour, moi fainéant. ;)
Si c'est juste pour utiliser un dll packagé avec les pieds : casser les pieds des fournisseurs pour qu'ils donnent les .lib et .h qui vont avec, ou si c'est des cons, les faire moi-même ( et c'est pas si dure, vue que c'est des noms non-décorés ;) )

Citation:

---

il faut que tu l'enregistres avec "regsvr32.exe <Chemin Complet>\MaDll.dll"

---

L'enregistrement n'est nécessaire qu'au déploiement.
L'ajout d'une dll COM dans les références d'un projet doit s’accompagner d'un "#import" dans le code source et des commandes d'enregistrement dans les post-action de la compilation.(cela permet de toujours utiliser la bonne version du composant)

Citation:

---

pour cela il te faut aussi connaitre l'espace de noms défini par ta DLL

---

???
C'est le genre de truc qui est récupérer par le dépiautage de la TLB par MIDL.EXE et consort, non ?
C'est même souvent "overwrité" lors de l'import.

Citation:

---

Envoyé par bacelar

Parce que "LoadLibrary", c'est portable peut-être. :weird:
COM a été partiellement porté sur Mac et le XCOM de FireFox/Mazilla était assez proche de COM.
.Net a été porté sous Linux/MacOsX via le projet Mono.

---

Donc COM n'est pas portable (Je n'ai pas vu Linux, et "partiellement" ... ben c'est pas complet du coup), je ne connais pas XPCOM mais ça a l'air intéressant.
Pour le portage de .Net, je ne m'attarderai pas, parce que le framework .Net en natif :aie: (CLR, c'est ça?).
LoadLibrary n'est pas portable, mais facilement remplaçable par dlopen sur les autres plateformes.

Citation:

---

Envoyé par bacelar

C'est le genre de truc qui est récupérer par le dépiautage de la TLB par MIDL.EXE et consort, non ?
C'est même souvent "overwrité" lors de l'import.

---

Oui, dépiautage de TLB, ou juste récupérer l'IDL.

L'implémentation de la CLR de Microsoft est maintenant OpenSource, les spécifications de la CLR est une norme ECMA depuis quasi le début de .NET.
Il est donc possible d'avoir une compatibilité de 100% sur n'importe quelle plateforme, si une implémentation de la CLR y existe.
Le projet OpenSource Mono est donc une implémentation des spécifications de la CLR sur les plateformes Linux, MacOS, Windows et bien d'autres.
Que la CLR soit native ne pose aucun problème, car elle suit la norme ECMA.
L'implémentation de Mono est de 100% pour les technologies "Core" de .NET.
Les parties comme WPF qui est très lié à directX au niveau de l'implémentation M$ et qui demande beaucoup de travail pour faire du "from scratch" ne sont pas ou pas encore implémentés dans Mono.
Mais pour les plug-ins, c'est du LoadAssembly "de base", le genre de truc que Mono sait faire depuis le début (depuis ~2002).

Citation:

---

LoadLibrary n'est pas portable, mais facilement remplaçable par dlopen sur les autres plateformes.

---

Ce que fait sans problèmes et de manières transparentes le moindre framework de plug-ins, même très rudimentaire.

Donc, oui je crash sur "LoadLibrary", car il n'y aucune justification à son utilisation, sauf pour réinventer une roue, qui sauf avec beaucoup de travail, sera bien plus carré que n'importe quel framework de plug-ins, portable ou pas.

Si le fournisseur du composant (la dll) ne veut pas imposer de framework d'interconnexion, il n' a qu'a fournir le .h et le .lib correspondant à l'inferface C qu'il fournit. Et l'utilisateur peut très facilement générer (très souvent automatiquement) des wrapper pour le framework d’interconnexion ou utiliser finement le delayloading.

AUX CHIOTTES LOADLIBRARY+GETPROCADDRESS !!!