Utilisation de DLL mixées à partir de / clr: projets purs

Question

Je construis un projet avec une Dll.

La Dll doit supporter le code natif, je l'ai donc déclaré en tant que / clr. Mon projet était aussi un projet / clr et tout allait bien. Cependant, j'aimerais inclure des tests NUnit et je devais donc passer mon projet principal de / clr à / clr: pure.

Tout est toujours compilé mais tout appel à la DLL génère une erreur d'exécution. Quand je reviens à / clr tout va bien

Dans ma DLL, les fonctions exportées sont déclarées comme suit:

#define DllExport   __declspec( dllexport )
DllExport bool DisplayScan(bool bShow, bool bAllPasses) { }

J'ai également créé un fichier .def contenant les noms réels de toutes les fonctions exportées

LIBRARY "Controller"
EXPORTS
DisplayScan

Depuis mon projet principal, mes importations sont déclarées comme suit:

#define _DllImport [DllImport("Controller.dll", CallingConvention = CallingConvention::Cdecl)] static
_DllImport bool DisplayScan(bool bShow, bool bAllPasses)

Quelqu'un a-t-il déjà rencontré un tel problème?

Answer 1

Ok tout fonctionne maintenant

En fait, cela fonctionne depuis le début.

Moral: n'essayez pas de convertir un caractère * dans std :: string

Chose étrange: ça va dans / clr jusqu'à ce que vous reveniez de la fonction. Il se bloque immédiatement dans / clr: pure

Answer 2

En gros, vous faites quelque chose qui n'est pas pris en charge. / clr: exportations de DLL pures et natives. Comme indiqué dans cet article MSDN " les assemblages purs ne peuvent pas exporter des fonctions sont appelables à partir de fonctions natives, car les points d'entrée d'un assemblage pur utilisent la convention d'appel __clrcall. "

Je ne suis pas sûr de la meilleure solution de contournement. Cependant, avec quelques expériences, vous pourriez probablement tirer parti de la convention d'appel __clrcall avec l'option / clr. Cliquez ici pour un lien

Answer 3

Avantages de / clr: pure

Meilleures performances: étant donné que les assemblys purs ne contiennent que MSIL, il n’existe pas de fonctions natives et, par conséquent, aucune transition non gérée / non gérée n’est nécessaire. (Les appels de fonction effectués via P / Invoke sont une exception à cette règle.)

AppDomain Awareness: des fonctions gérées et des types de données CLR existent dans les domaines d'applications, ce qui affecte leur visibilité et leur accessibilité. Les assemblys purs sont sensibles au domaine (__declspec (appdomain) est impliqué pour chaque type), de sorte que l'accès à leurs types et fonctionnalités à partir d'autres composants .NET est plus facile et plus sûr. De ce fait, les assemblages purs interagissent plus facilement avec d’autres composants .NET que les assemblages mixtes.

Pas de chargement sur disque: les assemblys purs peuvent être chargés en mémoire et même diffusés. Cela est essentiel pour utiliser les assemblys .NET en tant que procédures stockées. Cela diffère des assemblages mixtes qui, en raison d'une dépendance aux mécanismes de chargement de Windows, doivent exister sur le disque pour s'exécuter.

Réflexion: il n’est pas possible de réfléchir sur des exécutables mixtes, alors que les assemblages purs fournissent un support de réflexion complet. Pour plus d'informations, voir Reflection (C ++ / CLI).

Contrôlabilité de l'hôte: étant donné que les assemblages purs ne contiennent que MSIL, ils se comportent de manière plus prévisible et flexible que les assemblages mixtes lorsqu'ils sont utilisés dans des applications hébergeant le CLR et modifiant son comportement par défaut.

Limitations de / clr: pure

Cette section couvre les fonctionnalités non prises en charge par / clr: pure.

Les assemblages purs ne peuvent pas être appelés par des fonctions non gérées. Par conséquent, les assemblages purs ne peuvent pas implémenter des interfaces COM ou exposer des rappels natifs. Les assemblys purs ne peuvent pas exporter de fonctions via les fichiers __declspec (dllexport) ou .DEF. De plus, les fonctions déclarées avec la convention __clrcall ne peuvent pas être importées via __declspec (dllimport). Les fonctions d'un module natif peuvent être appelées à partir d'un assemblage pur, mais les assemblys purs ne peuvent pas exposer les fonctions appelables en natif. Par conséquent, l'exposition des fonctionnalités dans un assemblage pur doit s'effectuer via des fonctions gérées dans un assemblage mixte. Voir Comment: migrer vers / clr: pure (C ++ / CLI) pour plus d'informations.

Les bibliothèques ATL et MFC ne sont pas prises en charge par la compilation en mode pur dans Visual C ++.

Les modules .net purs ne sont pas acceptés en tant qu'entrée dans l'éditeur de liens Visual C ++. Toutefois, les fichiers .obj purs sont acceptés par l'éditeur de liens et les fichiers .obj contiennent un sur-ensemble d'informations contenues dans netmodules. Voir Fichiers .netmodule en tant qu'entrée de l'éditeur de liens pour plus d'informations.

La prise en charge du compilateur COM (# import) n'est pas prise en charge car cela introduirait des instructions non gérées dans l'assemblage pur.

Les options de virgule flottante pour l'alignement et la gestion des exceptions ne sont pas réglables pour les assemblages purs. __Declspec (align) ne peut donc pas être utilisé. Cela rend certains fichiers d’en-tête, tels que fpieee.h, incompatibles avec / clr: pure.

La fonction GetLastError du fichier PSDK peut donner un comportement non défini lors de la compilation avec / clr: pure.

Answer 4

votre problème appelle conventionCallingConvention = CallingConvention :: Cdecl ... définit votre fonction de cette façon ou utilise stdcall ou clrcall, clecl est pour du C pur.

ou le problème est ici: définir cette fonction extern non statique