Existe-t-il un moyen d'écrire un objet en C/C++ pouvant être utilisé à partir de .NET? Je voudrais le faire d'une manière très simple, celle utilisée pour étendre fondamentalement tous les autres langages, c'est-à-dire écrire un objet en C, conforme à l'interface requise par le langage d'exécution, utiliser l'objet de la langue.Écrire un objet .NET dans C?
Vous pouvez créer une bibliothèque en C/C++ et exporter les méthodes et l'utiliser dans .NET en utilisant P/Invoke.
Si vous utilisez C++ géré, cela compile en code IL, ce qui permet de l'utiliser directement dans n'importe quel langage .NET. Pour le code C/C++ non géré, vous devez utiliser P/Invoke dans le code .NET pour l'appeler.
Pour le code C/C++ non géré, vous devez utiliser P/Invoke dans le code .NET pour l'appeler.
Vous devez utiliser C++/CLI (anciennement appelé Managed C++, mais ce terme est déconseillé par les responsables marketing de Microsoft). C++/CLI est un surensemble C++ qui se compile en .NET IL et fournit des fonctionnalités permettant l'interopération avec d'autres langages .NET. C++/CLI permet un code mixte géré et natif. C'est le seul langage .NET qui supporte cela.
Deux façons:
C++/CLI: C++/CLI est une méthode qui rend les choses franchissable. Les classes que vous créez pour CLI en C++/CLI ne sont pas exactement régulière anciennes classes C++, mais vous pouvez relier des classes C++ avec les modèles d'adaptation
P/Invoke (montre pour les SEHExceptions!): Si vous souhaitez développer en utilisant bibliothèques C/C++ natives de base, vous pouvez accéder à n'importe quelle exportation C standard à partir du CLR en utilisant P/Invoke et vous pouvez Marshall manuellement vos objets si vous les déclarez bien des deux côtés. Voir le guide "Interop with Native Libraries" pour plus d'informations que vous pourriez vouloir savoir.
Je ne peux pas insister assez. Regardez vos exceptions! Ne les laissez pas échapper de votre code CLI dans votre code natif ou de votre code natif dans leur code CLI.
Si vous travaillez avec unmanaged types (ECMA-334 §27.2), un exemple étant des tableaux de types primitifs, vous pouvez procéder comme suit. Comme cela sacrifie un peu de sécurité du code, je recommande fortement d'essayer d'abord les alternatives et de ne recourir à cela que si le P/Invoke s'avère lent dans les versions de sortie en dehors du débogueur (le débogueur utilise un much slower P/Invoke (100x slower) pour intercepter plusieurs types de défaillances).
[DllImport("NativeLibrary.dll")]
private extern unsafe void NativeMethod(byte* data, int length);
byte[] data = new byte[10000000];
unsafe
{
fixed (byte* ptr = data)
{
NativeMethod(ptr, data.Length);
}
}
Mono cannot currently compile C++/CLI, malheureusement, donc en C++/CLI est probablement la façon la plus simple et efficace de faire ce que vous demandez, il ne va probablement pas travailler pour vous. Vous pouvez compiler l'assembly C++/CLI avec le.Outils NET, peut-être, but even that may not work bien (faites défiler jusqu'à la réponse à propos de "Puis-je exécuter mon programme Visual Studio .NET ..."). P/Invoke ou COM interop devrait le faire, bien que P/Invoke entraîne des problèmes de performances potentiels et COM interop signifie que vous devez transformer votre interface C vanilla simple en une interface COM ... qui, en C , n'est-ce pas agréable.
P/Invoke est extrêmement inefficace car je passe de gros BLOB binaires comme arguments et P/Invoke nécessiterait de le copier. Ce dont j'ai besoin, c'est d'un accès à l'infrastructure .NET depuis mon composant, pour pouvoir accéder aux données sans avoir à les copier. Caged géré fournit ce genre de chose, cependant, je voudrais que la chose fonctionne avec .NET et Mono et géré C++ n'est pas pris en charge avec Mono :( –
En d'autres termes: Y at-il une interface JNI-like pour CLR? –
Si vous voulez que cela fonctionne dans Mono, j'essaierais l'approche PInvoke et vérifierais si la performance est acceptable avant de passer plus de temps à chercher une approche plus élégante –