J'aurais besoin de précision sur interop C++/C# [Résolu]
dodo7263642
Messages postés mercredi 10 septembre 2008Date d'inscription
9 février 2017
Dernière intervention
-
24 janv. 2014 à 10:41 - Dernière réponse : yann_lo_san1137
Messages postés lundi 17 novembre 2003Date d'inscription
23 janvier 2016
Dernière intervention
- 24 janv. 2014 à 13:00
Mon post parle de C# mais c'est dans le cas d'interop avec C++.
Je vais donc développer une bibliothèque en C++ non managé que je vais par la suite consommer sur une plateforme en C++ et sur une autre plateforme en C#.
Cette bibliothèque sera une base commune aux 2 plateformes.
Pour l'intégration de cette bibliothèque sur la plateforme en C++ pas de soucis de ce côté là. Pour l'intégration sur la plateforme en C#, pas de soucis particulier non plus (j'ai déjà mon idée) mais en lisant plusieurs tuto sur différents site (codeproject, développez.com etc...) je commence à me perdre car j'ai l'impression de lire tout et son contraire.
Pour intégrer ma bibliothèque sur la plateforme C#, il y a plusieurs possibilités :
1) Utilisation de P/Invoke pour exposer mes méthodes et les utiliser dans mon code C#.
2) Utilisation d'un wrapper C++ / CLI pour ma bibliothèque non managé
3) Tout écrire en C++/CLI
J'ai retenu la solution 2).
Mais pour cette solution suis-je obliger de mettre mon code non managé dans une dll ?
Voici comment j'ai procédé de mon côté pour éviter de mettre mon code non managé dans une dll. J'ai donc écrit un bout de code en C++ non managé. Ensuite j'ai écrit un wrapper managé dans lequel je déclare juste un pointeur vers ma classe non managée (en incluant bien sur les bons header !). Je mets tout ça dans une .dll que je peux ensuite consommer "nativement" dans mon appli en C#. Et cela fonctionne !
Est ce une bonne approche selon vous ?
Ce qui m'inquiète aussi est le fait que si je dois modifier, pour une quelconque raison ma bibliothèque commune, je devrais donc modifier mon wrapper et mon code C# et en terme de maintenabilité et d'évolution, je ne suis plus sur du choix de ma solution.
Qu'en pensez vous ?
Voilà, je crois que j'ai à peu près tout dit. Le post est un peu long mais j'ai essayé d'être le plus complet possible.
Merci d'avoir tout lu ;-) et de vos éventuelles réponses !
@++
SD
"La censure épargne les corbeaux et s'acharne sur les colombes" Juvenal
"La tolérance est une vertu qui rend la paix possible" K.Annan
"Pourquoi Windows ? Parce que Linux ou l'inverse peut-être"
cptpingu3784
Messages postés dimanche 12 décembre 2004Date d'inscriptionModérateurStatut
18 avril 2018
Dernière intervention -24 janv. 2014 à 10:48
0
Utile
Bonjour.
Je n'ai malheureusement pas la réponse à ta question, en revanche, je t'invite exceptionnellement à "cross-poster" ce sujet dans la section C#, afin d'optimiser tes chances de réponse. Tu crées un sujet de même nom, tu mets dedans un lien vers cette page, en expliquant que c'est un post inter-section, et moi derrière je ferme le sujet pour que les réponses soient bien centralisées ici.
le seul problème dans ta solution est qu'AUCUNE partie de ton code ne pourra être exécuté sur une plateforme non managé.
Par exemple un programme en pur C/win32 APIs, ne pourra pas utiliser ta DLL puisqu'elle contient des référence au .net.
Isoler des DLL non managées est ce que fait Microsoft.
Puis avec 1 wrapper en p/invoke en dehors de la dll, celle-ci peut s'exécuter avec tous les langages managés.
Une autre solution permet de faire une DLL en C# UNIQUEMENT puis de l'utiliser depuis du code natif c/c++ via le chargement du runtime .net depuis l'applicatif avec des appels COM
Voir ceci pour charger le runtime et utiliser une dll C# managée :
