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.