Discussion :

[popoms]

Bonjour à tous,

j'ai besoin d'encapsuler un code C# dans un code C, pour permettre l'interopérabilité avec d'autres langages qui ne supportent pas .NET, et je galère un peu.

J'ai pensé qu'encapsuler ma dll C# avec du C++/CLI, puis passer du C++/CLI au C serait la bonne méthode. J'ai essayé de faire tout ça dans la même dll, ce qui n'est peut-être pas une bonne idée.
J'ai mis ma dll C++/CLI en mode /clr, qui permet l'interopérabilité. Pourtant, quand je compile mon code en dll, aucun fichier .lib n'est généré, alors qu'habituellement il y en a un. Quand je compile en statique, j'ai un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Warning LNK4221 : no public symbols found; archive member will be inaccessible

Et effectivement, quand j'essaie d'appeler ma dll depuis un code C++ natif, j'ai une erreur au lien avec le fichier .lib.
Sous VISUAL 2008 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Error	1	error LNK2019: unresolved external symbol __imp__getSupportedLanguages referenced in function _wmain	win32_testdll.obj	win32_testdll

J'ai la même erreur avec MinGW :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

undefined reference to "__imp__getSupportedLanguages"

Au moins mes compilos sont d'accord, ce doit être ma librairie en C++/CLI qui n'exporte pas les bons symboles. Je suppose que c'est une histoire de managé/pas managé, mais je ne sait pas trop comment m'y prendre.

La question finalement c'est de savoir comment faire pour obtenir une dll avec une interface externe non managée et une interface interne managée! Dans la FAQ c'est surtout le contraire qui est bien montré. Quelqu'un aurait une idée pour faire ça?

Je rajoute mon fichier .h si ça peut aider :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// dll_c.h
#ifndef DLL_C_H
#define DLL_C_H
#pragma once
 
#ifdef DLL_EXPORT
#define DllImportExport  __declspec( dllexport )
#else
#define DllImportExport  __declspec( dllimport )
#endif
//#include <stdlib.h>
 
//using namespace System;
 
namespace dll_c {
 
	#ifdef __cplusplus
    extern "C" {
    #endif
 
	DllImportExport int getSupportedLanguages(char **langages, int *arraySize, char *errormsg);
 
    #ifdef __cplusplus
    }
    #endif
}
 
#endif //DLL_C_H

[Philippe Vialatte]

Salut,

en fait, il faut que tu definisse ta classe comme etant comvisible, et que tu exposes les methodes/enumerations dont tu as besoin...

Jamais fait, par contre


------------------

Edit : par contre, j'ai trouve ca :

http://www.codeproject.com/KB/vb/COM_Interop.aspx

Ca m'a l'air de bien correspondre a ce que tu veux...

[popoms]

Apparemment oui, je checke un coup pour voir

[nico-pyright(c)]

l'assembly c++/cli n'a pas à exporter des méthodes comme une dll classique

tu peux regarder cet exemple dans mon tutoriel
http://nico-pyright.developpez.com/t...LwrapperCppCli
ou dans ce post http://blog.developpez.com/nico-pyri...i_exe#more6460

[popoms]

Merci à tous les deux pour vos réponses!

@ nico-pyright(c)

l'assembly c++/cli n'a pas à exporter des méthodes comme une dll classique

Ben en fait si, parce que dans mon cas, le code appelant est un code non managé en C, C++ ou autre. C'est la dll de base qui est en .NET et que je veux encapsuler. En fait je veux faire le contraire de ce que tu fais dans ton tuto.

Le code de l'encapsulation est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// This is the main DLL file.
 
//#include "stdafx.h"
 
#include "dll_c.h"
 
using namespace TousLesNamespacesQuiVontBien;
 
 
int getSupportedLanguages(char **languages, int *arraySize, char *errormsg)
{
	MyController controler;
	String ^errormessage = gcnew String("");
	List<String^> ^langues = gcnew List<String^>();
 
	bool ret = controler.GetSupportedLanguages(langues, errormessage);
 
	langues->Add("ENGLISH");
	langues->Add("SPANISH");
 
	*arraySize = langues->Count;
 
	for (int i=0; i<*arraySize; ++i){
		languages[i] = static_cast<char *>(System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(langues[i]).ToPointer());
	}
 
	errormsg = static_cast<char *>(System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(errormessage).ToPointer());
	return (ret? 0 : 1);
}

Mon problème, c'est que je n'arrive pas à appeler cette dll depuis un code C++ natif. J'ai une erreur au link, comme dit dans mon premier post.

Ce qui me paraît bizarre c'est que quand je compile ma dll C++/CLI, aucun fichier .lib n'est généré, alors que quand on compile un dll en C++ natif, il y a un .lib, dont on se sert ensuite pour linker la dll.
Y'a-t-il un moyen de générer une dll C++/CLI qui puisse être appelée par un code natif?

@pvialatte

J'ai lu le lien que tu m'a envoyé, ça à l'air compliqué mais pour l'instant je n'ai pas de meilleure solution que de passer par ces objets COM.

[nico-pyright(c)]

ok,
donc tu veux utiliser une dll c# dans un projet C++ natif

pas besoin de dll intermédiaire, tu peux faire du com interop comme déjà suggéré ou du hosting de clr, voir dans ce tuto http://nico-pyright.developpez.com/t...2005/interop2/

[popoms]

Merci pour ta réponse et ton tuto, que (j'avoue) j'avais diagonalisé sans m'arrêter sur la partie qui parlait de mon problème. En fait le wrapper inversé résoud mon problème. J'ai repris ton code et intégré le mien à la place, ça marche!

Par contre avec mon ancien projet, le fichier lib n'est toujours pas généré. As-tu activé une option spéciale pour ça?

[nico-pyright(c)]

tu veux dire que tu as un projet qui construit une dll native mais aucun .lib n'est généré ?

dans ce cas, c'est que tu n'as pas déclaré des méthodes qui doivent être exportées
soit explicitement dans le code, soit avec un .def éventuellement

[popoms]

Ca y est, j'ai trouvé ce qui merde dans mon code: en fait ça ne crée pas de .lib quand j'ai déclaré ma fonction dans un namespace (ça je comprends pas vraiment pourquoi). J'ai viré le namespace et ça marche. Youpi!!