Discussion :

[pasqual]

Bonjour,

Je cherche � utiliser une fonction d'une dll (build�e en C#) en c++. Voici la fonction en C#

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
namespace WMIString
{
    public class WMI
    {
        public string GetString()
        {
            string maString= "";
            //...
            return maString;
        }
    }
}

Dans les propri�t�s du projet, j'ai mis sous l'onglet applications : target framework : ".NET Framework 2". Sous assembly information, j'ai coch� "Make assembly COM-visible"
Dans les build options, j'ai coch�, "register for COM interop". Je devrais donc pouvoir utiliser cette dll dans un autre language, non?
J'ai ensuite builder la dll (appelons la madll.dll) sans erreur

Je veux ensuite charger cette dll depuis un projet c++ (j'utilise Qt �galement). Pour cela j'ai d�fini dans mon .h

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

typedef std::string (WINAPIV *WMI_GETSTRING)(VOID);

et dans mon .cpp je fais

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
HINSTANCE hdll;
hdll = LoadLibraryW( L"madll.dll" );
if(hdll) 
	ui.textEdit->append("madll.dll loaded");
else
	ui.textEdit->append("madll.dll not loaded");
 
WMI_GETSTRING WMIGetString;
WMIGetString= (WMI_GETSTRING)GetProcAddress( hdll, "GetString");
if( !WMIGetString)
       ui.textEdit->append("cannot find function");

Cela compile, et je peux voir que la dll est bien charg�e correctement (le message "madll.dll loaded" s'affiche), cependant la fonction n'est pas trouv�e.

Pourquoi?
Merci d'avance pour votre aide

[Arzar]

Est-ce que tu as aussi essay� avec la directive #import ? C'est souvent plus simple.

Edit : Et puis m�me, si je me souviens bien, on ne peut pas faire des GetProcAddress comme �a avec COM. Il faut plut�t faire qqchose comme :

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
 
#import "madll.dll"
void foo()
{
   CoComPtr<IWMI> wmi;
   wmi.CoCreateInstance(/* on passe ici le guid de l'objet com */);
 
   BSTR s = wmi->GetString();
} // release automatique de wmi quand on sort de la portée de foo
 
int main()
{
   CoInitialize();
   foo();
   CoUnitialize();
}

[pasqual]

Merci pour ta r�ponse Arzar,

Elle m'a permis de trouver un tr�s bon article nomm� "how-to-call-a-managed-dll-from-unmanaged-code"

Voici les principales �tapes
1. Impl�menter et builder la dll C# (class library)
2. g�n�rer un fichier clef � l'aide de la commande
sn.exe -k MyKeyFile.SNK
3. Ajoute/modifier les lignes suivantes du fichier AssemblyInfo.cs

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
[assembly: ComVisible(true)]
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("MyKeyFile.SNK")]

4. g�n�rer un fichier .tlb � l'aide de la commande
RegAsm.exe [including full path] madll.dll /tlb:madll.tlb /codebase
5. on peut ensuite utiliser cette dll depuis du code C++ avec

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
// Import the type library in DLL
#import "madll.tlb" raw_interfaces_only

Salutations

[JolyLoic]

A noter qu'en faisant ainsi, tu cr�es un wrapper COM autour de ta DLL. Ce n'est pas le seul moyen de faire. En effet, tu peux inclure mscoree.h et importer mscorelib.tlb, tu auras ainsi acc�s � un wrapper com autour du noyau de la CLR, et � partir de ce wrappper tu pourras appeler CorBindToRuntimeEx pour acc�der � la clr, et � partir de l�, des fonction comme ExecuteInDefaultAppDomain peuvent demander � la CLR de charger une DLL manag�e sp�cifique.

[Saris]

Bonjour,

Voici mon probl�me,

J'ai une DLL en c# compil�e avec VS 2010. Je souhaiterais pouvoir l'utiliser depuis du code natif c++ (comme d�crit pr�c�demment), mais depuis VS 2005.

J'ai essayer de plusieurs mani�re notamment celle ci qui va cr�er un wrapper C++ sur ma DLL.

Code de la DLL dllTest.dll (c# VS2010)

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
 
using System;
 
namespace NamespaceDLL
{
  public class MaDll
  {
    ...
    public static int SimpleTest(int value)
    {
      return ++value;
    }
    ...
  }
}

Code du Wrapper wrapper.cpp (C++ VS2010)

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
 
#include "stdafx.h"
#include "wrapperDll.h"
 
 
#using "..\bin\Debug\dllTest.dll"
 
using namespace System;
using namespace NamespaceDLL;
 
extern "C"
{
	__declspec(dllexport) int __cdecl SimpleTest (int value)
	{
		MaDll __gc *test;
		test = new MaDll;
 
		return test->SimpleTest (value);
	}
}

Application Test natif test.cpp (WIN32 App consol VS2005)

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
 
#include "stdafx.h"
 
using namespace std;
 
extern "C"
{
	int __cdecl SimpleTest(int value);
}
 
int _tmain(int argc, _TCHAR* argv[])
{	
  SimpleTest(100);
 
  return 0;
}

Voil� le gros du code. Tous les fichiers sont pr�sents DLL LIB car pas de probl�me de compilation. Mais � l'ex�cution il y a une erreur lors de l'appel de la m�thode du wrapper qui fait appel � celle de la DLL.

Quand j'ex�cute ce que test depuis VS2010 je n'ai aucun probl�me et j'obtiens le r�sultat attendu. Mais via VS2005 erreur ...

Si vous pouvez m'aider ... Merci.

Saris

[bacelar]

C'est quoi comme erreur ?

Ciblez-vous bien le Framework 2.0 de .Net dans les projets C# et C++/CLI ?

VS2005-> Framework 2.0

[Saris]

Bonjour,

Je viens de faire le test avec la DLL c# en Framework 2.0 mais cela ne change rien.

Erreur � l'ex�cution lors de l'appel de la m�thode du wrapper qui appel celle de la DLL :
Exception non g�r�e � 0x75419617 dans test.exe*: 0xE0434352: 0xe0434352.

Si je compile tout en VS2010 ou tout en VS2005 �a fonctionne mais d�s que je mix �a plante.

C'est bien au niveau de la DLL c# qu'il y a un probl�me puisque si je fais une fonction simple (qui n'appelle pas la DLL) dans le wrapper, je n'ai pas d'erreur.

+ Dans mon code de test en VS2005 je fais bien :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

#pragma comment(lib, "wrapper.lib")

pour avoir acc�s aux m�thodes du wrapper.

[bacelar]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Je viens de faire le test avec la DLL c# en Framework 2.0 mais cela ne change rien.

Et la dll en C++/CLI ???

[JolyLoic]

Et si tu faisais pas �a, mais que tu te liais dynamiquement � ta DLL (GetProcAddress et compagnie) ?

[bacelar]

Les assemblies .NET n'exportent pas les m�thodes des classes.
C'est exactement comme une dll COM qui n'exporte que 4 ou 5 m�thodes qui sont toujours les m�mes.

Les attributs ComVisible et consort ne servent qu'� montrer les objets .NET comme des objets COM.

Le code .NET a besoin d'avoir un certain nombre de dll charg�es, constituant le runtime d'ex�cution et de JIT compilation. Et ce runtime doit intercepter les appels au code .NET pour g�n�rer � la vol�e le code natif. Toutes cette cuisine est planqu�e dans les 4 ou 5 m�thodes COM export�es par l'assembly .NET.

Moralit� : pas de link dynamique nue et heureusement, car mettre en place le runtime .NET avant l'appel des m�thodes ne serait pas un sin�cure.

D'o� l'int�r�t de C++/CLI qui fait tourner du code natif et manag� indiff�remment. C'est le compilateur C++/CLI qui met en place le runtime .NET et qui g�n�re le code de passage entre le code natif et manag� et vice versa.

[Saris]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Je viens de faire le test avec la DLL c# en Framework 2.0 mais cela ne change rien.

Et la dll en C++/CLI ???

Si je veux compiler la DLL C++ en .NET 2.0, je dois installer VS2008 ...

Error 11 error MSB8009: .NET Framework 2.0/3.0/3.5 target the v90 platform toolset. Please make sure that Visual Studio 2008 is installed on the machine. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets 292 6 wrapper

Ca fait beaucoup de Visual Studio tout �a pour un probl�me d'incompatibilit� VS ... hum

D'autant plus que si je fais appel, depuis VS2005, � un m�thode de mon wrapper dont celle-ci n'appel pas une de la DLL c#, tout ce passe correctement m�me en 4.0.

[bacelar]

J'ai confondu le probl�me de pasqual (initiateur du fil) et celui de Saris (le squatteur )

Saris, si tu n'utilises pas le Framework 2.0 pourquoi ne pas utiliser VS2010 pour tout le code manag� en utilisant le Framework .NET 4.0 ?

Pour ceux qui ont vraiment des probl�matiques de version de Framework, il semble que la configuration par d�faut des projets VC++ de VS2010 est un peu bogu�, regardez la r�ponse indiquant le changement de "Platform Toolset" du projet dans le fil suivant :
http://social.msdn.microsoft.com/For...f-3d69d5f61cda

[Saris]

Saris, si tu n'utilises pas le Framework 2.0 pourquoi ne pas utiliser VS2010 pour tout le code manag� en utilisant le Framework .NET 4.0 ?

En gros voil� comment �a se passe :

Nous faisons une application, en code natif, qui doit absolument �tre compil�e en VS2005 pour pouvoir tourner sur Bentley MicroStation. (test.cpp)

Par souci de facilit� nous avons cr�� une DLL en c# sur VS2010 (dllTest.dll)
Pour le moment ils utilisent une macro qui bidouille la DLL de mani�re � la rendre accessible depuis du code natif.

Je dois rendre cette DLL accessible depuis le code natif. J'ai donc cr�� un wrapper (wrapper.cpp).

A la base, la DLL et le wrapper sont compil� en .NET 4.0 sur VS2010. L'application test doit absolument appel� le wrapper depuis VS2005.
Erreur � l'ex�cution.

DLL et wrapper en .NET 2.0 sur VS2010
Test VS2005.
Erreur � l'ex�cution.

Pour info, si j'ajoute cette m�thode dans le wrapper (en .NET 2.0 ou 4.0):

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
__declspec(dllexport) int __cdecl TestWrapper (int value)
	{
		return ++value;
	}

,
Je n'ai pas d'erreur. C'est vraiment lorsque mon wrapper fait appel � la DLL principale compil�e sous VS2010 (.NET 2.0 ou 4.0) que j'ai l'erreur.

En tout cas le scoitteur que je suis vous remercie pour votre aide

[bacelar]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

doit absolument être compilée en VS2005 pour pouvoir tourner sur Bentley MicroStation. (test.cpp)

D�j�, �a sent pas bon.

Moi, je ferais plus qu'un petit effort pour rendre compilable le code avec VS2010.

Au moment du plantage, analysez la zone de plantage.

Moi, je pencherais pour l'utilisation de 2 Framework .NET.

Pour v�rifiez, appelez du code manag� dans la dll en C++/CLI. S'il y a 2 Framework, cela plantera aussi.

[JolyLoic]

Les assemblies .NET n'exportent pas les m�thodes des classes.
C'est exactement comme une dll COM qui n'exporte que 4 ou 5 m�thodes qui sont toujours les m�mes.

Les attributs ComVisible et consort ne servent qu'� montrer les objets .NET comme des objets COM.

Le code .NET a besoin d'avoir un certain nombre de dll charg�es, constituant le runtime d'ex�cution et de JIT compilation. Et ce runtime doit intercepter les appels au code .NET pour g�n�rer � la vol�e le code natif. Toutes cette cuisine est planqu�e dans les 4 ou 5 m�thodes COM export�es par l'assembly .NET.

Moralit� : pas de link dynamique nue et heureusement, car mettre en place le runtime .NET avant l'appel des m�thodes ne serait pas un sin�cure.

Je ne parlais pas de linker dynamiquement la biblioth�que C#, bien �videmment (m�me si c'est possible, avec CorBindToRuntimeEx et autre, si ce n'est pas une sin�cure, ce 'nest pas non plus la mer � boire), mais de lier dynamiquement la DLL en C++/CLI VS2010, qui expose des points d'entr�e en pur C, depuis un programme en VC2005. �a, �a devrait marcher.

[Saris]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

doit absolument être compilée en VS2005 pour pouvoir tourner sur Bentley MicroStation. (test.cpp)

D�j�, �a sent pas bon.

Moi, je ferais plus qu'un petit effort pour rendre compilable le code avec VS2010.

J'aimerais bien mais c'est Bentley qui recommande cela :
http://www.la-solutions.co.uk/content/MDL/MdlDll.htm

Donc voil� c'est comme �a. Du coup nous sommes limit� pour le d�veloppement sauf si nous trouvons une solution pour rendre cette DLL construite en VS2010 compatible depuis de code natif en VS2005.

Est ce que quelqu'un a pu essayer cette petite manip avec deux VS diff�rents ?
L'exemple montr� pr�c�demment devrait th�oriquement fonctionner.

[Saris]

Je ne parlais pas de linker dynamiquement la biblioth�que C#, bien �videmment (m�me si c'est possible, avec CorBindToRuntimeEx et autre, si ce n'est pas une sin�cure, ce 'nest pas non plus la mer � boire), mais de lier dynamiquement la DLL en C++/CLI VS2010, qui expose des points d'entr�e en pur C, depuis un programme en VC2005. �a, �a devrait marcher.

Bonjour,

Vous pourriez, me donner un exemple ou expliquer cette solution ?
D'avance Merci

[M�dinoc]

C'est possible, �a, qu'une DLL C++/CLI expose des points d'entr�e pur C et soit chargeable par LoadLibrary()?

[bacelar]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

C'est possible, ça, qu'une DLL C++/CLI expose des points d'entrée pur C et soit chargeable par LoadLibrary()?

Oui car C++/CLI permet de faire du code manag� et du code non manag� dans la m�me dll. Il faut juste que les fonctions export�es utilisent les conventions C. Vous connaissent mon avertion pour les exports C++ (de classe ou pas).

En survolant la page fourni par Saris sur Bentley MicroStation, je vois du .NET. Avec un peu de malchance, les libs Bentley MicroStation nous ont coll� un Framework en louzd�. V�rifiez la pr�sence ou n'en d'un Framework .NET dans l'ex�cutable natif 2005.

Si c'est le cas retournez vous sur mes remarques pr�c�dentes sur "Platform Toolset".

J'insiste sur le fait que le d�buggeur est � m�me de vous indiquer ce type de probl�me si vous analyse correctement l'�tat du processus dans le d�buggeur.

[Saris]

Je vais essayer de faire cela...

Pour le moment je n'utilise rien qui n'ait avoir avec Bentley MicroStation... vu que �a n'a pas march� avec, j'ai fait plusieurs solutions tests dans chaque VS. Je vous ai parl� de MicroStation pour expliquer les raison du pourquoi je dois utiliser cette DLL depuis VS 2005.

M�me ces simples exemples ne fonctionnent pas, sauf quand le tout est test� dans un m�me VS.