comment appeler les méthodes c # (mono, .net), delegates du c natif

Votre code C peut définir des fonctions pour enregistrer des rappels. Le code C # peut P / invoquer ces fonctions et transmettre des delegates gérés en tant qu’arguments. Le code de marshalling les transformera de manière transparente en pointeurs de fonction C.

Vous pouvez également utiliser l’API d’incorporation Mono pour l’approcher depuis le côté C, pour charger des assemblys, rechercher des méthodes Mono et les appeler.

L’utilisation de l’API d’intégration est beaucoup plus compliquée. Si votre point d’entrée est en C, vous devrez utiliser l’API d’intégration, mais il est probablement plus facile d’écrire simplement une méthode gérée pour effectuer l’enregistrement de rappel et toute autre configuration gérée. Il vous suffit alors de charger et d’appeler cette méthode unique. à partir du code C.

Il existe une vue d’ensemble de l’interopérabilité des codes gérés / non gérés sur le site MSDN qui pourrait vous éclairer un peu. Un extrait ci-dessous:

Accéder directement à une API gérée

Si un client non géré est écrit en C ++, il peut être compilé avec le compilateur Visual Studio .NET C ++ en tant qu ‘”image en mode mixte”. Une fois cette opération effectuée, le client non géré peut accéder directement à n’importe quelle API gérée. Toutefois, certaines règles de codage s’appliquent à l’access aux objects gérés à partir de code non géré. Consultez la documentation C ++ pour plus de détails.

L’access direct est l’option privilégiée car il ne nécessite aucune attention particulière des développeurs d’API gérés. Ils peuvent concevoir leurs API gérées conformément aux directives de conception des API gérées et être sûr que l’API sera toujours accessible aux appelants non gérés.

Exposer une API gérée en tant qu’API COM

Chaque classe gérée publique peut être exposée à des clients non gérés via COM interop. Ce processus est très facile à mettre en œuvre car la couche COM Interop prend en charge toute la plomberie COM. Ainsi, par exemple, chaque classe gérée semble implémenter IUnknown, IDispatch, ISupportErrorInfo et quelques autres interfaces COM standard.

Bien qu’il soit facile d’exposer des API gérées en tant qu’API COM, les modèles d’object géré et COM sont très différents. Par conséquent, exposer l’API géré à COM doit toujours être une décision de conception explicite. Certaines fonctionnalités disponibles dans le monde géré n’ont pas d’équivalent dans le monde COM et ne seront pas utilisables à partir des clients COM. De ce fait, il existe souvent une tension entre les directives de conception d’API gérées et la compatibilité avec COM.

Si les clients COM sont importants, écrivez votre API gérée conformément aux instructions de conception de cette dernière, puis créez un wrapper managé fin compatible avec COM, autour de votre API gérée, qui sera exposé à COM.

Exposer une API gérée en tant qu’API plate

Parfois, les clients non gérés ne peuvent pas utiliser COM. Par exemple, ils peuvent déjà être écrits pour utiliser des API plates et ne peuvent pas être modifiés ou recompilés. C ++ est le seul langage de haut niveau qui vous permet d’exposer des API gérées en tant qu’API plates. Cela n’est pas aussi simple que d’exposer une API gérée en tant qu’API COM. C’est une technique très avancée qui nécessite une connaissance avancée de l’interopérabilité C ++ et des différences entre les mondes géré et non géré.

Exposez votre API gérée en tant qu’API plate uniquement si cela est absolument nécessaire. Si vous n’avez pas le choix, vérifiez la documentation C ++ et soyez pleinement conscient de toutes les limitations.

Voici une solution. Pour appeler la fonction C # à partir de C, on utilise l’atsortingbut [DllExport] (à l’opposé de P / Invoke DllImport). https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports