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.