Paum� dans la cr�ation et l'utilisation de DLLs

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/10/2007, 13h42
pierre.chatelier

Paum� dans la cr�ation et l'utilisation de DLLs

Bonjour,

Je voudrais mettre au point une structure de d�veloppement sur laquelle je me casse les dents depuis deux jours. Je ne sais pas r�soudre entre autres les divers probl�mes de link ijw/clr/pure/pas pure (c'est une horreur)
Voici :
J'ai une base de code en C++ standard, agr�ment� parfois de quelques utilisations de classes C++/CLI (system::string^, etc.). Je voudrais en faire une DLL utilisable dans d'autres projets (disons core.lib/core.dll; un jour il faudra que je comprenne pourquoi la g�n�ration d'une dll produit aussi un .lib)
J'ai un projet ("solution" en visual) consitu�e de deux sous-projets
-la red�finition d'un contr�le utilisateur (UIControl)
-le programme principal
Ces deux projets ont besoin du code de core.dll

Initialement, �a marchait bien :
La dll �tait compil�e en CLR (ni pure ni safe), d�cor�e des divers declspec(dllexport)
Le contr�le utilisateur �tait aussi en CLR (ni pure ni safe) et importait les headers en rempla�ant les dllexport par dllimport, linkant avec core.lib, et utilisant #using core.dll (merci au tuto de nico-pyright)
Le programme principal faisait de m�me

Et puis un jour, le designer du programme principal s'est mis � ne plus reconna�tre le contr�le utilisateur. Ce n'est pas faute d'avoir reg�n�r� le projet, refait l'importation du contr�le dans la bo�te � outil... rien � faire. Et puis finalement, en supprimant le contr�le de la bo�te � outil pour le r�importer ensuite, je suis retomb� sur l'erreur de chargement HRESULT machin qui apparemment vient du fait que mon usercontrol.dll n'est pas clr:pure

J'ai donc d�cid� de refaire un peu �a.
-Pour une raison que je ne m'explique pas, core.dll compile tr�s bien en clr:pure (je croyais que le C++ et les pointeurs l'en emp�cheraient). Au passage, j'ai d� supprimer les declspec(dllexport).
-De m�me, mon usercontrol compile en clr:pure (en virant les dllimport des headers)
-par contre, �a ne linke plus. Un obscur lnk2001 sur 5 ou 6 fonctions de ma dll l'en emp�che. Il n'y a aucune raison pour �a, ces fonctions sont banales, et je n'ai pas dupliqu� les d�clarations dans diff�rents headers, donc pas d'incoh�rence possible.
-En fouillant le net, il para�t qu'il faut rajouter msvcmrt.lib, mais dans ce cas, �a n'essaye m�me pas de linker (mscvcmrt.lib est en ijw, incompatible clr:pure).

J'ai essay� des tas de configurations pure/pas pure, rien n'y fait, je n'y arrive pas.

Quelqu'un aurait-il des lumi�res ?

Merci

+
Chacha
19/10/2007, 13h53
nico-pyright(c)

quelles sont les erreurs ?
19/10/2007, 14h01
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

quelles sont les erreurs ?

error LNK2001: symbole externe non r�solu
"public: void __clrcall EXSingletonManager::destroySingletons(void)" (?destroySingletons@EXSingletonManager@@$$FQAMXXZ)

et idem pour quelques autres fonctions d'autres classes (c'est tr�s vari� : une virtuelle, une statique, un constructeur...)

Prenons l'exemple de cette fonction: elle n'est pas inline, elle est dans une classe. Le code est dans un .cpp, et le .h est ainsi :
class EXSingletonManager {
...
public: void destroySingletons(void);
}...

J'avais pens� qu'il pouvait s'agir de fonctions d�cor�es/inlin�es diff�remment dans le .obj en fonction des optimisations, mais j'ai bien mis les m�me, j'ai essay� de les d�sactiver, etc. Rien � faire

+
Chacha

[edit]
Tiens, ben en fait, core.dll ne g�n�re plus de core.lib, puisque j'ai vir� les dllexport qui sont incompatibles avec le clr:pure...
J'ai aussi essay� de forcer le __clrcall devant les fonctions probl�matiques, mais rien ne change.
[edit2]
Et si je compile core.dll en clr (pas pure), c'est pareil
19/10/2007, 14h45
nico-pyright(c)

quand tu changes de mode de compilation, la convention d'appel par d�faut change.
Si tu fais des classes natives comme semble l'etre EXSingletonManager, tu peux essayer en d�finissant explicitement la convention d'appel, � stdcall par exemple

mais peut-etre serait-il plus judicieux d'en faire des classes manag�es qui seront plus facilement int�ropables ensuite
19/10/2007, 14h51
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

quand tu changes de mode de compilation, la convention d'appel par d�faut change.
Si tu fais des classes natives comme semble l'etre EXSingletonManager, tu peux essayer en d�finissant explicitement la convention d'appel, � stdcall par exemple

�a ne change absolument rien ! Toujours les m�mes erreurs de link sur les m�mes fonctions !

Citation:

mais peut-etre serait-il plus judicieux d'en faire des classes manag�es qui seront plus facilement int�ropables ensuite

Ce n'est pas mon but. Je ne veux pas r��crire en code manag� toutes les classes C++ standard que j'utilise, au contraire; je veux le plus de code standard possible. En r�alit�, le peu de code manag� dans ces classes est encapsul� par un #ifdef VISUAL ... #endif : j'utilise les types natifs quand c'est possible, en fonction du syst�me.

+
Chacha
19/10/2007, 15h17
pierre.chatelier

Je pense � quelque chose...
Est-ce mafa�on d'importer les headers qui ne va pas ?

Je m'explique : dans le projet principal, m�me si je suis li� � ma dll, il me faut bien les headers pour utiliser les classes. Or,le compilateur va peut-�tre compiler certaines m�thodes lors du parsing du header, et d�corer diff�remment, ce qui donne un link "symbole non trouv�". Mais comment faire, alors, pour lui faire "lire" le header d'une classe en lui disant "�a mon coco, ce sont les d�clarations d'une dll compil�e, peut-�tre, en clr pas pure" (ce qui n'est pas le cas, mais bon) ? Il y a une astuce ?

+
Chacha
19/10/2007, 15h50
nico-pyright(c)

ce qui est sur c'est que tu ne dois pas avoir clrcall devant tes fonctions natives

tu as un projet minimal qui reproduit l'erreur ? car je t'avouerai que je ne comprends pas trop ton histoire ...
19/10/2007, 16h13
pierre.chatelier

1 pi�ce(s) jointe(s)

Citation:

Envoy� par nico-pyright(c)

ce qui est sur c'est que tu ne dois pas avoir clrcall devant tes fonctions natives
tu as un projet minimal qui reproduit l'erreur ? car je t'avouerai que je ne comprends pas trop ton histoire ...

Oui, je viens d'en faire un en vitesse. Je l'ai con�u � l'image des descriptions que j'ai fournies plus haut :
-Un projet autonome "Core" avec un EXSingletonManager (en C++ standard) tr�s simplifi� qui cr�e une dll en clr
-Un projet C++/CLI "Client" contenant un sous-projet "MyControl" et un sous-projet C++/CLI "Client", correspondant respectivement � un UIControl sous-class� et un programme principal.

Le "MyControl" tente d'exploiter EXSingletonManager, et �choue avec la fameuse erreur de link.

Au cas o�, j'ai int�gr� dans le stdafx.h de quoi tester rapidement les jeux de declspec(dllexport/dllimport) (mais a priori cela est inutile)

Pour que �a fonctionne "out of the box", je n'ai quasiment rien mis dans les options de compilation du projet, j'ai �crit en dur dans le code les chemins relatifs entre les �l�ments.

Merci de ton int�r�t.

+
Chacha

[edit]
Pour �viter d'ins�rer de potentielles erreurs de ma part, je n'ai pas sp�cifi� les #using Core.dll et les d�pendances avec Core.dll, puisque je n'ai trouv� aucune configuration correcte. C'est donc � la bonne �me qui va regarder de m'enseigner comment faire !
22/10/2007, 08h55
pierre.chatelier

Salut,

As-tu regard� le code ? Je ne te cache pas que je n'ai pas beaucoup d'autres recours, alors je compte beaucoup l� dessus... Comme ce n'est pas le genre de d�tail que l'on trouve dans un livre ou un tutorial, c'est dans ces cas l� que l'on a besoin d'un expert.

Merci d'avance,

+
Chacha
22/10/2007, 09h41
nico-pyright(c)

alors, c'est pas du tout comme ca qu'il faut faire ...

soit ton projet "core" est une assembly qui expose les m�thodes d'un objet manag�, dans ce cas il faut :
- �crire un wrapper manag� dans "core" qui encapsule ton objet EXSingletonManager natif
- r�f�rencer ce wrapper dans ton projet "client"

soit ton projet "core" est une dll native, dans ce cas, il faut utiliser les m�canismes de C++ interop pour pouvoir acceder � ces fonctions, comme d�crit dans mon tutoriel http://nico-pyright.developpez.com/t...vc2005/interop

Une autre solution est de mixer le code natif et manag� dans le meme projet, comme expliqu� dans ce meme tutoriel ou dans celui la http://nico-pyright.developpez.com/t...grationcppnet/
22/10/2007, 11h50
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

alors, c'est pas du tout comme ca qu'il faut faire ...

�a doit �tre pour �a que je n'y arrive pas

Citation:

soit ton projet "core" est une assembly qui expose les m�thodes d'un objet manag�, dans ce cas il faut :
- �crire un wrapper manag� dans "core" qui encapsule ton objet EXSingletonManager natif

C'est justement ce que je veux �viter: je ne vais pas refaire un wrapper par classe C++ existante.

Citation:

soit ton projet "core" est une dll native, dans ce cas, il faut utiliser les m�canismes de C++ interop pour pouvoir acceder � ces fonctions, comme d�crit dans mon tutoriel http://nico-pyright.developpez.com/t...vc2005/interop

J'ai d�j� lu ce tutoriel, mais il ne r�pond pas vraiment � la question de l'export/import d'une classe C++ existante � partir d'une dll mixte native/manag� vers un code C++ manag� (et non C#!)
En th�orie, cela devrait marcher comme sur des roulettes, en pratique, j'ai mes erreur de link.

[edit]
j'ai l'intuition que �a marcherait si je n'�tais pas oblig� de faire un include des headers de la dll daans mon autre composant. Mais je n'arrive pas � utiliser des biblioth�ques de type qui permettraient (?) de se passer des headers pour informer le compilo de l'existence des classes/m�thodes

+
Chacha
22/10/2007, 13h42
nico-pyright(c)

dans ton projet C++/CLI, essaie simplement d'ajouter toutes tes classes native (.h et .cpp), tu buildes tout ensemble et ca marche
22/10/2007, 13h59
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

dans ton projet C++/CLI, essaie simplement d'ajouter toutes tes classes native (.h et .cpp), tu buildes tout ensemble et ca marche

Oui oui, je confirme, �a marche ! C'est ce que je faisais avant.
En r�alit�, je voulais simplement faire mieux. En effet, comme je vais �tre amen� � cr�er plusieurs projets C++/CLI partageant la m�me base de code C++ natif/manag�, je comptais en faire une DLL... C'est l� que les ennuis ont commenc�.
Depuis quelques heures, je suis revenu � l'ancien syst�me o� mon code sera "dupliqu�" entre les diff�rents projets; tant pis, c'est moins pratique mais au moins �a fonctionne.

Merci

+
Chacha
22/10/2007, 16h26
nico-pyright(c)

ok, j'avais pas compris.

dans ce cas, la m�thode de la dll est faisable.

Tu cr�es une dll,
tu exportes les m�thodes
tu links le .lib � ton projet c++/cli
tu inclus les header

et le tour est jou�
22/10/2007, 16h49
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

ok, j'avais pas compris.

dans ce cas, la m�thode de la dll est faisable.

Tu cr�es une dll,
tu exportes les m�thodes
tu links le .lib � ton projet c++/cli
tu inclus les header

et le tour est jou�

Ah mais l� on revient au point de d�part :-)
C'est la manipulation que j'explique dans le premier message de ce fil : je fais tout cela, mais il y a des erreurs de link, que je ne sais pas expliquer. Je suppose que cela vient du fait que je veux exporter non pas de simples fonctions, mais des classes C++. Et c'est aussi ce qu'illustre le projet minimal que j'ai post�.
22/10/2007, 17h32
nico-pyright(c)

non, il y a une diff�rence, il faut lier le .lib
23/10/2007, 10h04
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

non, il y a une diff�rence, il faut lier le .lib

Nous sommes d'accord, mais tu peux constater que cela ne fonctionne pas, m�me dans le projet minimal !
23/10/2007, 10h19
nico-pyright(c)

je ne vois pas de link au .lib dans ton projet minimal
d'autant plus que dans celui-ci, tu ne cr�es pas de .lib
23/10/2007, 10h24
pierre.chatelier

Citation:

Envoy� par nico-pyright(c)

je ne vois pas de link au .lib dans ton projet minimal
d'autant plus que dans celui-ci, tu ne cr�es pas de .lib

Exact, mais j'ai essay� ! J'avais indiqu�:

Citation:

Pour �viter d'ins�rer de potentielles erreurs de ma part, je n'ai pas sp�cifi� les #using Core.dll et les d�pendances avec Core.dll, puisque je n'ai trouv� aucune configuration correcte

...et cela concerne aussi le .lib, g�n�r� ou pas selon la configuration du projet Core (en clr:pure ou clr).
Ne sachant comment faire, je n'ai pas surcharg� la configuration du projet, mais j'ai bien s�r fait de multiples essais.
23/10/2007, 11h50
nico-pyright(c)

a mon avis, le probl�me vient de la

il faut que tu arrives � bien exporter les m�thodes et les classes et � bien lier le .lib au projet

Voir 40 message(s) de cette discussion en une page