Path.GetDirectoryName([Assembly].GetExecutingAssembly.GetName.CodeBase)
Les espaces de noms nécessaires sont:
• System.Reflection
• System.IO

VS .NET offre un environnement robuste pour créer des applications basées sur le NETCF. Ces applications peuvent tourner sur Pocket PC, Pocket PC 2002(et plus) et Windows CE .NET 4.1 (et plus). L’environnement permet d’inclure facilement des Windows Forms et composants ADO.NET dans les programmes en plus de tout ce qui a attrait au web ( consommer des services web).

 

a)      Design : VS .NET :1 / eVC++ :0

 

A la différence d’eVC++ VS .NET offre un environnement très simple d’utilisation pour tout ce qui concerne le « design » de forms. VS .NET a reprit toutes les bonnes idées de VB concernant le design notamment la notion de form (fichiers *.ebf en VB).

 

b)      Sécurité : VS .NET :2 / eVC++ :0

 

Un autre avantage d’utiliser des assemblies plutôt que des DLLs est que les premiers sont plus sécurisés (chargés dans le runtime avec un niveau de confiance), permettent d’éviter le chainage (système de versionning), gèrent les dépendances, … En un mot, les assemblies permettent de se passer de ce que certains appellent « l’enfer des DLLs ».

 

c)      Performances d’exécution : VS .NET :2 / eVC++ :1

 

L’inconvénient qui résulte de cela (b) est que les assemblies ne peuvent s’exécuter que dans le Runtime .NET (ce qui fait qu’il faut avoir le NETCF installé à la fois sur le PC et le PPC) qui est lui-même est chargé par l’OS ; les DLLs C++ sont directement « consommable » par l’OS (win32) d’une façon native. C’est en partie à cause de se « problème » (et d’autres aussi) que les applications C++/C sont beaucoup plus performant que celles développées avec C# .NET/VB .NET/C++ .NET/Java, …

 

d)      Intégration de composants natifs type ocx : VS .NET :2 / eVC++ :2

 

Annoncé pour la version 2 du NETCF, il n’est toujours pas possible d’ « héberger » des composants ActiveX sous NETCF. Sous eVC++ il suffit d’un clic deux mouvements pour intégrer son contrôle ActiveX dans son programme. Cependant, il est possible de développer une couche supplémentaire au NETCF permettant de résoudre cet handicap. Sinon, la seule alternative est de redévelopper son composant pour le NETCF (paradoxalement, il permet de le faire). Le développement et la mise en place de cette couche est assez complexe mais ils existent des bases (librairies de classes) offertes « gratuitement » par la firme OpenNETCT.

 

Pour que cela fonctionne on doit disposer du proxy sous forme d’Assemby et d’un Wrapper dans un fichier C# (c’est le seul langage dans lequel le Wrapper peut être généré). L’Assembly et le Wrapper sont générés par l’utilitaire de ligne de commande offert avec le FrameWork .NET (Aximp, pour ActiveX IMPort). Cet utilitaire n’étant pas adapté pour le NETCF, il pourrait être nécessaire de modifier la Wrapper à la main dans certain cas (c’est le cas du composant MapX50.dll).

Cependant, sous NETCF il existe toutes les classes nécessaires pour faire du Marshling de type et du Wrapping.

 

e)      Automation OLE : VS .NET :3 / eVC++ :2

 

C# permet beaucoup plus aisément de faire de l’automation (accès aux routines d’un processus) que le C++. On peut très facilement contrôler un processus Word en exécutant ces routines (créer un document, faire des mises en page ou tout simplement générer des rapports Word ou Excel) à partir d’un code managé. Faire ce type de programme en C++ est possible mais pas facile d’accès. o:p>

 

 

 

f)       C# (sous VS .NET) vs C++ (sous eVC++) : VS .NET :3 / eVC++ :2

 

Il n’est tout simplement pas possible de comparer ces deux langages du fait que leurs objectifs ne sont pas les mêmes. Si j’avais à le faire je dirais qu’un programme C# offre très certainement plus de lisibilité (il suffit juste de voir le nombre de ligne de code généré automatique par eVC++ avant même d’avoir écrit une ligne), de productivité (le système de séparation du « code design (interface) » et du « code code (implementation) » - utilisation de Classes partielles- améliore grandement la productivité avec C#) et de facilités de management (gestion du code au sens large) du fait tout simplement que ces concepteurs ont retenu les leçons tirer du C++, Java, Delphi et autres langages.

Cela fait que dans notre cas (programmation PPC) C# est sans aucun doute le langage le plus approprié.

 

g)      Ouverture : VS .NET :4 / eVC++ :2

 

Pour faire des applications mobiles cloisonnées eVC++ pourrait rivaliser avec VS .NET mais du moment que ces applications ont vocation à s’ouvrir sur le web ou interopérer avec d’autres applications (processus, SGBD, supports hybrides, …) on peut dire que VS.NET prend largement le dessus (à savoir qu’à l’origine .NET était définie par Microsoft comme étant une technologie qui permet de « communiquer », le mot –communiquer- souligne l’importance donner au web et à l’interopérabilité).

 

Il convient ainsi de bien étudier les possibles évolutions de notre application avant de choisir à le développer sous eVC++.

h)      Design patterns (ou réutilisation de code) : VS .NET :4 / eVC++ :2

 

Il est bien dommage de remarquer qu’au cours des développements les développeurs sont amenés à créer plusieurs fois les mêmes classes (types), d’exécuter les même procédures, de manipuler les mêmes objets pour accéder aux DB, etc. … tout ça pour dire : réinventer la roue. Une parade à cela est certainement la définition de motifs de conception (design patterns) réutilisable. Le C# et le C++ étant tous les deux très orientés Objet (l’objet étant la base des design patterns) on ne pourrait choisir l’un plutôt que l’autre.

 

1          Résultat 

 

VS .NET remporte 4 points contre 2 pour eVC++. L’avantage donné à VS .NET peut être dut au fait que je maitrise plus celui-ci.

 

 

L’élément le plus important à prendre en compte est l’évolution de l’application.

 

Merci de me signaler les âneries.

1. SuperWaba : SuperWaba est une JVM qu’on peut faire tourner aussi bien sous Palm OS, Windows CE et AppletViewer. C’est un projet open source. Plus d’info : Superwaba.

 

2. Waba : C’est un langage de type JAVA qui s'appuie sur une JVM réduite donnant de bonnes performances. Sa diffusion est libre de royalties. Waba permet de développer rapidement des applications à partir d'un langage orienté objet simple mais puissant. Il est aussi Multi-OS (PPC et Palm). Fonctionne sou licence Libre / GPL. Plus d’info : WabaSoft.

 

3. Microsoft eMbedded Visual C++ : C’est un IDE complet (SDK PPC, WCE .NET, SDK Emulator, …) permettant de créer des applications et composants systèmes pour Windows CE .NET. Le langage de développement est le C++. Pour la programmation de programmes native Win32 et des DLLs.

 

4. Visual Studio .NET : C’est un IDE qui permet de développer aussi bien des applications Windows basées sur PC que sur PPC. Pour les applications PPC il suffit de se procurer le NETCF (version la plus récente v2).

Pour la programmation en code manage pour le Framework et des Assemblies (cela a la couleur et l’odeur d’une DLL mais ça n’a rien à voir).

Il faut juste savoir que le Newton, lancé par Apple en 1993, est le pionnier des assistants personnels. Puis deux modèles se sont imposés grâce aux fonctions de synchronisation avec un ordinateur de bureau: le Palm Pilot, commercialisé dès 1996 par US Robotics, et le Psion. Aujourd'hui de nombreuses marques proposent des assistants personnels très sophistiqués, pouvant allier multimédia et accès Internet sans fil : Compaq, Hewlett-Packard, Toshiba, Sagem, etc.

 

La différence majeure entre ces différents modèles est l’OS : les uns utilisent Microsoft Mobile et les autres PalmOS. Pour faire simple nous dirons que ceux fonctionnant sous Microsoft mobile sont des PPC (Pocket PC) et les autres des Palms.

 

Comme dans le monde des Postes de travail (pour ne pas dire PC) il existe deux camps : Microsoft et les autres.

 

Pour faire simple et claire on dira que PPC ~= PC et Palm ~= Mac car PalmOS et Windows Mobile sont deux systèmes d’exploitation bien différents. PalmOS semble toute fois être supérieur à WM en se qui concerne le choix des logicielles, la rapidité d’exécution, le prix, … (pour aller loin : ZDNET).