Cette question peut sembler une répétition de précédents. J'ai lu une série de postes, mais pas complètement clair pour ma situation.
J'ai une bibliothèque C ++ créée à l'aide de Momals IDE. Je dois être capable d'utiliser cette bibliothèque dans un projet C #.
Quelqu'un travaillait sur ce projet avant d'être remis à moi. Actuellement, il y a 2 couches pour rendre cela possible. Premièrement, un projet C ++ inclut la bibliothèque complète avec une emballeuse C ++. Ce projet crée une DLL comme sortie. Cette DLL C ++ est ensuite introduite dans un projet C #, qui a des appels Dllimport à la DLL C ++. Ce projet C # crée à nouveau une DLL. Enfin, afin d'utiliser la bibliothèque dans la demande C #, je dois inclure une référence à ces deux DLL.
Est-ce le moyen correct de le faire fonctionner? Je pensais probablement qu'il devrait y avoir un moyen de simplifier le processus.
Quelqu'un peut-il m'aider avec cette question?
3 Réponses :
Étant donné que vous utilisez une bibliothèque C ++, je suppose que cela tire parti de la sémantique C ++ comme des classes, plutôt que de simplement exposer les procédures. Si tel est le cas, la manière dont cela est généralement effectué est via une bibliothèque de gestion C ++ créée manuellement.
Fondamentalement, vous créez une bibliothèque C ++ gérée dans Visual Studio, vous référez votre bibliothèque C ++ existante et créez une enveloppe gérée autour de vos classes C ++ existantes. Vous faites ensuite référence à cet ensemble (géré) C ++ dans votre projet C # et incluez la bibliothèque originale (non gérée) C ++ dans votre assembly C # comme fichier qui est placé dans le répertoire de construction.
Ceci est requis car il n'ya aucun moyen de faire référence à des choses telles que C ++ CLASSE via p / invoke ( Si votre bibliothèque de base est juste une série de fonctions, vous pouvez ensuite faire référence directement dans le projet C # via p / invoquer des fonctions.
De toute façon, toutes les bibliothèques mentionnées ci-dessus (pour la première, la bibliothèque C ++ non gérée, l'assemblage géré C ++ et le projet C #, ou, pour la seconde, la bibliothèque C ++ non traitée et le projet C #) doivent être incluses. dans n'importe quel projet qui les réfère. Vous ne pouvez pas lier statiquement la bibliothèque non gérée dans l'assemblée gérée. dllimport ).
+1, mais je voudrais souligner que si vous utilisez .NET 1.1, "géré C ++" est désormais appelé "C ++ / CLI", et il y a énormes différences entre les deux.
De plus, je pense que vous voulez dire "Vous ne pouvez pas lier de manière dynamique la bibliothèque non gérée". la liaison statiquement est le seul moyen d'utiliser la bibliothèque.
Merci beaucoup .... Comme vous l'avez dit, la LIB non gérée a des cours et des interfaces. Cela étant le cas, je crois que je dois avoir une emballeuse C ++ et une enveloppe C # pour pouvoir utiliser le C ++ Lib non géré dans mon application C #, non? Maintenant, le wrapper C ++ fait la tâche de créer une instance des classes et de la mise en œuvre de l'interface, est-ce correct? J'ai encore une question. Est-ce le travail de la liberme non gérée de fournir une fonctionnalité externe "C" et _DLLEXPORT? Actuellement, ce n'est pas le cas, mais je peux mettre cela comme une exigence pour le prochain projet, alors je veux juste m'assurer.
@Batul: à votre première question, oui; Vous auriez besoin de créer une classe wrapper en C ++ / CLI (grâce à @Randolpho pour la clarification de la terminologie) qui consomme vos types classiques C ++. À votre deuxième question, oui, si vous voulez aller à la route dllimport , votre bibliothèque non gérée doit exposer extern "c" fonctionne pour qu'ils soient consommables dans Un assemblage entièrement géré (C #, VB.NET, etc.). Notez ici que nous parlons de deux choses différentes; Généralement, vous Utilisez l'assemblage C ++ / CLI en tant que wrapper ou vous exportez des fonctions de procédure et dllimport dans votre code géré.
Oh, l'implémentation existante utilise ces deux méthodes. Le gars travaillant à ce sujet avant de moi a créé un wrapper C ++ et exporté les fonctions. Ensuite, il utilise également Dllimport dans C # pour accéder aux fonctions. Merci pour la clarification. Maintenant, envisagez que le C ++ Lib non géré a des cours et des interfaces, peut-il dllimporter une option? De plus, si je crée un wrapper C ++ / CLI, cela signifie-t-il que je peux simplement ajouter cela comme une référence dans l'application C # N Utilisez-la telle qu'elle est? sans avoir à utiliser dllimport? Je suis vraiment désolé de demander tant de questions, mais merci beaucoup pour votre patience.
@Batul: Il n'y a aucune raison que vous ne pouvez pas utiliser les deux, ce n'est qu'une solution typique. Et oui, si vous créez un wrapper C ++ / CLI, vous pouvez simplement l'ajouter comme une référence dans votre assembly C # sans aucun autre travail. Les types C ++ / CLI seront disponibles de la même manière que tout autre type .NET.
@Batul: Considérant que j'ai préconisé la solution que vous avez choisie (un wrapper C ++ / CLI) et donnait une explication (IMO) plus complète, je suis curieux pourquoi vous avez "inaccepté" ma réponse et que j'ai sélectionné une autre plus tard et A moins de votes?
Ce n'est pas que, j'ai supposé que, une fois que je sélectionne un post comme réponse, elle porterait la FWD que l'une pour tous les commentaires consécutifs sur ce poste, d'où la confusion. Comme vous l'avez dit, j'ai réalisé que votre solution était la meilleure. Merci beaucoup......
On dirait que vous avez un wrapper trop, mais peut-être que quelqu'un met en œuvre une sorte de façade ou d'ajouter des propriétés ou quelque chose. La connexion de base entre géré et non gérée sera soit DLLIMPORT d'appels de fonction "plats" - NO Fonctions membres - ou CO ++ / CLI Code des fonctions d'appel des membres. Si le wrapper est C ++ / CLI, il est plus facile d'écrire (il suffit d'inclure l'en-tête de la bibliothèque C ++) et le plus facile à appeler (C # code ajoute simplement une référence .NET à la normale) afin que ce soit mon premier choix si Il y a une expertise C ++ sur le projet.
On dirait que quiconque vous preniez est de le faire de la dure. S'il y a moins de 20 méthodes, je suggérerais de partir.
À partir de ce que j'ai ressemblé à la meilleure solution pour moi aussi, mais une fois que j'ai commencé, tout ce que j'ai examiné, il ne fait que souligné la solution actuelle de la bonne façon de le faire. Ce que je comprends de votre suggestion est également d'avoir une emballeuse C ++ pour gérer les classes de la lib libération non géographique C ++, puis utilisez des appels Dllimport dans C #. Ai-je raison?
Si vous ajoutez un wrapper C ++ / CLI, il peut vous éviter de p / invoke (dllimport.) Le code C ++ / CLI peut simplement simplement "inclure l'en-tête, le lien vers la lib" pour utiliser votre code natif. Tout ce qui est Classe de référence publique FOO dans le code C ++ / CLI peut être appelé à partir de C # sans mécanisme interoper du tout - ajouter simplement une référence et l'utiliser.
Merci kate. D'après ce que j'ai lu jusqu'à présent, Dllimport nécessite une structure plane dans la lib, c'est-à-dire sans classes ni interfaces. Mais ma lib non gérée a des cours et des interfaces, alors cela signifie-t-il que je ne peux pas utiliser dllimport? Si tel est le cas, la création de wrapper C ++ / CLI est la seule façon d'aller?
En C ++ - Terre, il n'y a pas à peu près une "seule façon de partir". Juste de meilleures façons. Écrire une enveloppe plate autour de vos classes afin que vous puissiez utiliser Dllimport ne semble pas être un bon plan. Je préférerais l'approche C ++ / CLI.
Dupliqué possible de Comment puis-je appeler Native C ++ de C #?