1 / 25

Appels de fonctions natives sous C#

Appels de fonctions natives sous C#. Proposition d’une architecture pour « wrapper » une classe native. Managed code vs Unmanaged code C++ (compilation, décoration, exportation) Fonctionnalités « interops » de .NET Architecture proposée Création des 4 projets Déploiement.

blaze-aguilar
Download Presentation

Appels de fonctions natives sous C#

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Appels de fonctions natives sous C# Proposition d’une architecture pour « wrapper » une classe native

  2. Managed code vs Unmanaged code • C++ (compilation, décoration, exportation) • Fonctionnalités « interops » de .NET • Architecture proposée • Création des 4 projets • Déploiement

  3. Managed Code vs Unmanaged code • Managed code : code exécuter (interpréter) sous le « framework » .NET.

  4. Managed Code vs Unmanaged code • Sous .NET CF 2.0, il n’y a pas de C++/CLI

  5. C++: Compilation • Lors de la compilation, le compilateur génère un fichier .obj par fichier .cpp qu’il compile. • Toutes les fonctions et variables globales compilées dans un fichier .obj sont « marquées ». • Lors de l’application des liens, le « Linker » génère un fichier « PE » en liant tous les fichiers .obj.

  6. C++: Décoration • La déclaration d’une fonction dans un fichier .obj est encodée (décorée). • L’algorithme de décoration dépend du compilateur (et parfois aussi de sa version). • En C, il n’y a habituellement pas de décoration.

  7. C++: Décoration • Exemple: soit la variable globale« int dllVersion ». Son nom décoré sera« ?dllVersion@@3MA » sous Visual C++ 2005 • Pour déclarer, sous C++, une entité non décorée; il faut forcer le compilateur à l’interpréter comme du code C:extern ”C” int dllVersion;

  8. C++: Exportation • Pour exporter une variable globale ou fonction, sa déclaration doit être ajoutée dans la table d’exportation du fichier « PE ». • « __declspec(dllexport) » le fait automatiquement.

  9. C++: Exportation

  10. C++: Exportation • Pour exporter une fonction non décorée:extern “C” __declspec(dllexport) void fnt(int);

  11. Fonctionnalités « Interops » de .NET • P/invoke permet, sous .NET, d’exécuter du code natif (unmanaged). • Sous CF 2.0, la convention d’appel est __cdecl [DllImport("CommandCInterface.dll", CallingConvention = CallingConvention.Winapi, CharSet = CharSet.Unicode, EntryPoint = "SetNameAgeCommand_SetNameAgeCommand_name_age")] internal static extern IntPtr SetNameAgeCommand_SetNameAgeCommand_name_age(byte[] name, Int32 age);

  12. Architecture proposée : buts • Pouvoir simplement importer une classe sous C# qui fut implémentée sous C++ (unmanaged). • Apporter très peu de modifications au projet à importer. • Compréhensible et possiblement automatisable. • Simple à déployer.

  13. Architecture proposée : Modèle

  14. Architecture proposée: projet « Command.dll » • Est un projet C++ unmanaged code. • Est le projet original à importer sous .NET • Nécessite très peu (ou pas du tout de modification).

  15. Architecture proposée: CommandCInterface.dll • Est un projet C++ unmanaged code. • Est une interface C de la classe Command. • Pour chaque fonction membre de la classe « Command », il faut exporter une fonction « wrapper » • Il faut ajouter une référence au projet Command.dll • Exemple:extern "C" __declspec(dllexport) void SetNameAgeCommand_EncodeCommand(SetNameAgeCommand *this_);

  16. Architecture proposée: CommandCSInterface.dll • Est un projet C#. • Est une interface C# de la classe Command. • Pour chacune des fonctions exportées de CommandCInterface.dll, il faut ajouter une fonction statique de type p/invoke. • Il faut ajouter une dépendance au projet CommandCInterface.dll.

  17. Architecture proposée: CommandCSInterface.dll • La classe interface doit encapsuler un pointeur « protected IntPtr this_; » sur l’objet « Command ». Il doit être passé en paramètre lors de l’appel d’une fonction. • « this_ » est initialisé lors de la création d’une instance. • « this_ » est détruit lors de la destruction de l’instance.

  18. Architecture proposée: CommandCSInterface.dll [DllImport("CommandCInterface.dll", CallingConvention = CallingConvention.Winapi, CharSet = CharSet.Unicode, EntryPoint = "SetNameAgeCommand_EncodeCommand")] private static extern void SetNameAgeCommand_EncodeCommand(IntPtr p);

  19. Architecture proposée: DeviceApp.exe • Est un projet C# • Utilise l’interface C# pour accéder à un objet de type « Command ». • Il faut ajouter une référence au projet CommandCSInterface.dll.

  20. Création du projet Command.dll • C++, librairie pour Windows Mobile Device 5.0. • Réutiliser les mêmes fichiers utilisés pour compiler le projet sous Win32. • S’assurer d’être en « Unicode ».

  21. Création du projet: CommandCInterface.dll • C++, librairie pour Windows Mobile Device 5.0. • S’assurer d’être en « Unicode ». • Ne pas oublier la référence sur Command.dll

  22. Création du projet: CommandCSInterface.dll • C#, librairie 2.0 pour Windows Mobile Device 5.0. • Ne pas oublier la dépendance sur CommandCInterface.dll.

  23. Création du projet: DeviceApp.exe • C# application graphique 2.0 pour Windows Mobile Device 5.0. • Ne pas oublier la référence sur CommandCSInterface.dll.

  24. Déploiement • Il est important d’ajuster les propriétés des 4 projets concernant leur déploiement. • Tous les projets doivent être déployés dans le même répertoire!

  25. Questions…

More Related