D�pendances de DLL C++/CLI

Je suis d�butant en C++/CLI et je bloque sur un probl�me... Je vais tenter de l'expliquer le plus clairement possible :

J'ai cr�� deux DLL C++/CLI :
La premi�re (A) est utilis�e par la seconde (B).
"A" d�finit quelques classes abstraites, et quelques classes concr�tes (toutes manag�es).
"B" d�finit uniquement des classes concr�tes (manag�es �galement) qui h�ritent des classes abstraites d�finies dans "A". Notez que toutes les classes d�finies dans "A" sont import�es quelque part dans "B".
Toutes les classes concr�tes d�finies dans A et B servent � wrapper des objets natifs C++ (pour y acc�der depuis du C#) qui sont d�finis dans d'autres DLL (natives, mais compil�es avec /clr, comme A et B).

Je compile bien mes DLL, je les r�f�rence dans le C#, et c'est l� que le probl�me apparait :
Dans l'explorateur d'objets, ma DLL "A" est vide, et ma DLL "B" contient tous les objets de "A" et "B" r�unis.
Apr�s r�flexion, j'ai trouv� ca (� peu pr�s) normal �tant donn� que "A" ne contient aucun ".cpp" ; uniquement des ".h" ; et que "B" inclut tout "A"...

Je me suis alors dit qu'en mettant des .cpp dans "A" ca changerait le probl�me.
En effet, j'ai simplement rajout� dans "A" un fichier ".cpp" qui contenait uniquement l'include du fichier ".h" correspondant (pas de code).
R�sultat dans l'explorateur d'objets : "B" contient toujours TOUT, mais "A" contient maintenant ses propres classes. Du coup, le projet C# ne compile m�me plus, vu qu'il a des classes d�finies dans les deux DLLs !

Enfin, j'ai essay� de mettre le code d'une m�thode dans le fichier ".cpp" ajout� dans "A".. Et l�, probl�me de link ("B" ne trouve pas le symbole de la m�thode en question). Or "A" ne me g�n�re pas de fichier .lib (je ne connais pas bien le conditions sous lesquelles un .lib est g�n�r� avec une DLL). Donc je ne sais pas comment linker correctement dans ce cas l�...

Si vous avez la moindre id�e qui pourrait m'�tre utile, ca m'interesse :)
Merci d'avance ;)

Logiquement les dlls du C++/CLI sont des assemblies mang�es, comme pour le C# donc a priori tu n'as pas besoin des fichiers lib puisqu'il s'agit de rajouter une r�f�rence vers une dll manag�e. De plus, tous les fichiers de A devraient �tre dans A et B ne contiendrait alors aucun fichier de A ( ni *.h, ni *.cpp ) mais devrait juste importer l'espace de nom ( using namespace A ). Tout cel� devrai marchier normallement, pour peut que toutes les classes utilis�es soient manag�es ... :?

Merci pour ta r�ponse rapide smyley :)
Je ne comprends pas bien quand tu dis "B ne contiendrait alors aucun fichier de A mais devrait juste importer l'espace de nom" :
J'ai quand m�me besoin dans les fichiers de B de faire r�f�rence aux .h de A, je suis donc oblig� de mettre dans B des ' #include "FichierDeA.h" '...
Et c'est l� que ca pose probl�me, car le fichier ainsi inclus se retrouve d�clar� dans A et dans B !
(Toutes mes classes sont manag�es...)

J'ai cr�� un exemple simple dont les fichiers sont dans Pi�ce jointe 16894 (j'utilise visual) :


Dans un projet DLL_A, j'ai le fichier TestA.h :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#pragma once   namespace Test { public ref class TestA { public: TestA(void) {} }; }

---

et le fichier TestA.cpp qui va avec :

Code:

---

1 2 3

#include "StdAfx.h" #include "TestA.h"

---

Si je ne met pas ce fichier CPP, la dll g�n�r�e est vide.

De la m�me fa�on, je cr�e un projet DLL_B qui contient TestB.h :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#pragma once   namespace Test { public ref class TestB { public: TestB(void); }; }

---

Cette fois, l'impl�mentation est dans TestB.cpp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include "StdAfx.h" #include "TestB.h"   #include "TestA.h"     Test::TestB::TestB(void) { Test::TestA ta; }

---

Maintenant, je r�f�rence les deux DLL dans un projet C#, et j'obtiens l'erreur :

Code:

---

1 2 3 4

{CheminVersProjetC#}\Form1.cs(15,14): erreur CS0433: Le type 'Test.TestA' existe dans '{CheminVersRepDeSortie}\DLL_A.dll' et dans '{CheminVersRepDeSortie}\DLL_B.dll' {CheminVersRepDeSortie}\DLL_A.dll : (Fichier concerné) {CheminVersRepDeSortie}\DLL_B.dll : (Fichier concerné)

---

Voil� le test basique.

Un autre test consiste � ne pas cr�er de fichier TestA.cpp : Ca fonctionne mais tout (TestA et TestB) se trouve dans la DLL_B. C'est pas bon (dans le cas r�el d'utilisation, je veux avoir deux DLL qui utilisent A, et avec ce comportement, j'aurais une d�finition des classes de A dans ces deux DLL...)

Enfin, un dernier test consiste � mettre du code de la classe TestA dans TestA.cpp (comme c'est fait pour B, avec la d�finition du constructeur dans le cpp). Mais dans ce cas, DLL_B ne passe pas le link :

Code:

---

1 2	TestB.obj : error LNK2020: jeton non résolu (06000002) Test.TestA::.ctor

---

(C'est le constructeur de TestA qui est d�fini dans le cpp, qui correspond bien au jeton non r�solu ...)

Voil�, je pense que le probl�me est assez clair (n'h�sitez pas � me demander des pr�cisions si besoin !).
Ce qui m'emnnuie c'est que ce comportement semble logique (sauf pour le probl�me de link, mais je gal�re toujours avec les probl�mes de link...).

Encore une fois, je vous remercie d'avance pour votre aide !

je vais �ssayer pour voir

voil�, la solution VS 2005 est dans DLL_A

C'�tait bien �a... Le "using namespace" dont tu avais parl�... En fait je n'arrive pas � le faire dans mon projet... Il me dit qu'il ne connait pas le namespace !
J'ai peur que ce soit un cas non couvert dans l'exemple : soit � cause des classes templates, soit � cause de fonctions type C (qui ne sont pas dans des classes).
Je vais essayer de reproduire le probl�me dans le programme d'exemple...

Ca y est, j'y suis enfin arriv� !
Bon j'ai vraiment fait une erreur de d�butant : je n'avais pas r�f�renc� l'assembly dans les "propri�t�s communes" de mes sous-projets (�quivalents de DLL_B). :aie:
En tout cas, merci beaucoup :yaisse2:

Bon, maintenant que ca marche, je tombe dans sur autre probl�me ... :bug:
Les sous-projets (�quivalents de DLL_B) ne peuvent pas acc�der aux objets natifs wrapp�s par les classes manag�es du projet parent... Et ce, m�me si les objets natifs sont accessibles depuis les sous projets...
J'ai ouvert un autre topic pour ca, m�me si j'ai une (plut�t deux) solution(s) de contournement...

Merci encore !

J'aimerais revenir sur une question pos� au d�but:dans quel cas un .lib est g�n�r� � la compilation d'un DLL?

Voici mon probl�me:
3 elements:
* un dll c++
* un wrapper cli wrappant la dll c++
* une dll C# utilisant le wrapper

Mon wrapper cli a besoin du .lib g�n�r� par la dll c++ pour le link.
Ce .lib n'est g�n�r� que si ma dll c++ contient une fct export� or je n'en ai pas!
quand je met une fct export� (juste pour tester) dans ma dll, le .lib est cr�� mais cette lib ne convient pas au wrapper (pb de convention __cdecl et __clrcall).

Quand je g�n�re un .lib a partir de mon projet dll c++ (compil� en lib), le .lib est il le meme que celui g�n�r� lors de la compilation en tant que dll?(il me semble que non).Puis je utiliser ce .lib pour mon wrapper (en tout cas la compilation fonctionne!ou est pass� le pb de __cdecl et __clrcall ???)

Merci pour votre aide

pour avoir une lib, il faut exporter des fonctions (que ce soit avec dllexport ou par .def)
Pour que ton wrapper puisse l'exploiter, il faut que les conventions d'appels soient les memes.
Le mieux est de les d�finir explicitement dans le prototype de la fonction. Soit les garder _cdecl et dans ton wrapper, les expliciter.
Soit tout passer en stdcall

Pour que ton wrapper puisse l'exploiter, il faut que les conventions d'appels soient les memes.
Le mieux est de les d�finir explicitement dans le prototype de la fonction. Soit les garder _cdecl et dans ton wrapper, les expliciter.
-->c'est � dire (expliciter)?

Soit tout passer en stdcall
-->mais dans ce cas mon wrapper n'est plus utilisable depuis le C#!

J'ai remarqu� qu'en mettant 'virtual' devant les m�thodes wrapp� le link fonctionne, mais j'ai des methodes statique dc pas de 'virtual' !

relis bien le lien dans la faq que je t'ai donn� : http://dotnet.developpez.com/faq/cpp...r#errorLNK2031

ca veut dire qu'il faut dans le prototype mettre en clair _cdcel

et si tu as les sources de la lib, rien ne t'empeche de tout recompiler en stdcall

mais bon, le plus simple reste de mettre _cdcel explicitement dans ton wrapper c++/cli pour les fonctions export�es � utiliser

Je rappel que mon wrapper est concu pour etre utilis� par du C#!
Il est donc ecrit en c++/cli.
Dans les propri�t�, calling convention est bien __cdecl (/Gd) donc comme la DLL a wrapper.
si je met __declspec(dllimport) devant la m�thode du wrapper j'obtiens naturellement l'erreur
error C3387: ... : __declspec(dllexport)/__declspec(dllimport) cannot be applied to a member of a managed type

Je pense qu'il faudrait trouver une compatibilit� entre les 2 conventions d'appel (une sorte de wrapper de convention d'appel, un truc normalis� si c existe!).

Quelles sont les autres pistes?
Le 'virtual' fonctionne mais pour les m�thodes static? :(

mais non, il ne faut pas exporter les m�thodes du wrapper, mais les m�thodes de la lib C
Le wrapper �crit en C++/CLI, ca sera une assembly qui pourra etre utilis�e telle quelle par du C#, comme une autre assembly.

Le C# utilise l'assembly �crite en C++/CLI qui encapsule et utilise la dll �crite en C.

C'est cod� en C++ et non en C...bref.

Si j'utilise le .lib de ma DLL C++ natif c'est justement pr ne pas faire d'export (librairie statique)!
J'ai essay� avec l'export - DllImport avec mes m�thodes statique et ca compile mais c'est pas propre tous ca (a cause des export)!

si tu veux pas t'emmerder avec des libs et des exports, le plus simple c'est de recompiler ta lib avec le switch /clr et d'inclure dans le projet une nouvelle classe ref qui fait le wrapper, tout ca sera dans le meme assembly manag� et c'est le C++ interop qui fait tout le boulot pour toi

Tout dans le meme assembly c'est ce que j'avais fait au d�but et effectivement c plus simple!

J'ai mis des export dans ma lib et tout fonctionne (sans meme faire d'import dans mon wrapper!).
Ce que je n'avais pas compris c'est que le .lib g�n�r� lors de la compilation de la DLL n'est pas vraiment une lib statique!Oui c'est un .lib, mais pas du tout le meme que le .lib g�n�r� en compilant le projet en librairie statique (la taille du fichier est 10 fois plus petite!).

Voila donc c'est r�solu.
MERCI!
:D