S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Dossier Vista : première partie

Dossier Vista : première partie

Vincent HERMANN, Jerôme BOSCH le 30 janvier 2006
L'environnement .Net, l'une des fondations de Vista



.Net est le nom donné à la plateforme de développement logiciel principale de Microsoft. C’est un regroupement de l’architecture interne des langages, de composants et d’outils.

La technologie .Net comporte trois grandes parties :


  • Un ensemble extensible de langages dont le C#, le VB.Net, et le Delphi. Ces langages doivent respecter la spécification CLS (Common Language Specification).
  • Un ensemble de classes de bases utilisées par les applications. C’est ce que l’on appelle le framework .Net.
  • Une couche logicielle nommé CLI (Common Language Infrastructure) est responsable de l’exécution des applications .Net

Les applications .Net, quel que soit le langage haut niveau utilisé, sont compilées dans un langage intermédiaire (IL, Intermediate Language). On parlera alors de code managé (IL) et non managé (code machine). Le but est de transformer le code IL en code machine lors de l’exécution lorsque le système d’exploitation et le processeur sont connus. Une application .Net peut ainsi être déployée sur n’importe quelle plateforme compatible .Net sans être recompilée. On dit alors que les applications sont portables au niveau binaire.

Pour le moment, le framework .Net a uniquement été implémenté sur les plateformes Windows mais cela est voué à changer dans le futur, et l’on peut trouver actuellement le projet MONO sur Linux (implémentation open source du framework). On trouve aussi le projet rotor de Microsoft (en shared source) qui fournit une implémentation du CLI pour MacOS X, FreeBSD et Windows.

La machine virtuelle .Net, appelée CLR (pour Common Language Runtime), peut être comparée à la machine virtuelle Java, bien que cette dernière n’ait été conçue que pour le seul langage Java. Pour passer le code IL en code machine, le CLR va utiliser la technique de compilation JIT (Just In Time). Le CLR compile des portions de code (méthodes) juste avant de les exécuter. Cette technique donne de meilleurs résultats en termes de performances que l’interprétation séquentielle d'instructions.



Le CLR est capable d’appliquer bon nombre d’optimisations et peut générer du code optimisé pour un certain type de processeur ou encore placer les variables les plus fréquemment utilisées directement dans les registres du processeur, ce qui accélère leurs accès. La version 2.0 de .Net améliore nettement les performances de l’outil NGen qui, lancé à la fin de l’installation, permet de compiler entièrement une application avec le compilateur JIT. Dans certains cas la compilation JIT peut affecter les performances. Cet outil peut donc devenir intéressant bien que son utilisation désactive certaines optimisations appliquées en temps réel.

Le CLR gère également le chargement des applications et leur exécution. Les applications sont placées dans une sandbox qui les isole totalement des autres applications et du système. Nous reparlerons de ce point plus en détails dans le chapitre dédié à la sécurité. La mémoire sous .Net est entièrement gérée par le CLR qui utilise un ramasse-miette (garbage collector) pour libérer automatiquement la mémoire inutilisée.

Dans .Net, on appelle un « assembly » une librairie de codes compilés en code IL. Sous Windows on le trouve sous deux types : les .EXE et les .DLL. On sait que des librairies de code standard peuvent être partagées par plusieurs applications, ce qui peut induire un problème récurrent connu en général sous le nom poétique « d’enfer des DLL » : certaines mises à jour de librairies partagées peuvent empêcher d’autres applications de fonctionner suite à des changements de code. Cela a été plus ou moins réduit par les modules d’installation récents mais on en trouve encore la présence.

L’environnement Net propose une solution intéressante : il est capable de charger des assemblies de différentes versions. L’application utilisera la version pour laquelle elle a été prévue. Pour différencier les assemblies, .Net utilise la méthode des noms forts. Un nom fort est constitué de quatre entités : le nom de l’assembly, sa version, sa culture, et un jeton dérivé de la clé publique qui sert à la signer numériquement. Le répertoire GAC (Global Assembly Cache) permet de stocker les assemblies partagées grâce au nom fort qui les identifie de façon unique.


Le développement d’une application obéit souvent a des contraintes financières. La réécriture de gros projets et la formation des développeurs avec de nouveaux langages peuvent devenir lourds en termes de coûts pour les entreprises. Le .Net 2.0 introduit le langage C++/CLI vers lequel tous les anciens programmes codés en C++ peuvent être compilés, bien que Microsoft ait ajouté des fonctionnalités internes au .Net par exemple pour la gestion mémoire. Il n'est en revanche pas possible de compiler un code C++/CLI en utilisant un ancien compilateur. A noter qu'il existait une version managée du C++ (Managed C++) dans la première version de l'environnement .Net. Les assemblies produits sont dits mixtes car ils contiennent à la fois des sections de code en IL et en code machine (x86). Les développeurs C++ pourront ainsi plus facilement migrer le vieux code et accéder plus facilement aux nouvelles fonctionnalités apportées par le .Net.

Le Framework .Net propose une API (Application Programming Interface) objet de très haut niveau qui permet de créer des applications complexes plus rapidement. Le .Net respecte un bon nombre de standards d’organisations comme le W3C (World Wide Web Consortium), l’IEEE (Institute of Electrical and Electronics Engineers), l’OASIS (Organization for the Advancement of Structured Information Standards), l’IETF (Internet Engineering Task Force) et la WSI (Web Services Inspection).

L’utilisation du XML est omniprésente et permet une meilleure interopérabilité des applications. Par exemple, la méthode de sauvegarde de la configuration passe par l’utilisation d’un fichier XML et rend obsolète la base de registres. Alors que sur Windows XP, le framework .Net repose sur l’API Win32, il en est totalement indépendant sous Vista, ce qui devrait améliorer les performances. Il est intégré dans le sous-système WinFX qui représente l’API managée de Windows Vista : elle regroupe le framework .Net 2.0, la Windows Presentation Foundation (WPF, ex-Avalon) et la Windows Communication Foundation (WCF, ex-Indigo). Cette API est destinée à s’élargir avec le temps.