Présentation de la plateforme .Net

Historique de la plateforme .Net

La plateforme .Net est devenue au fil des ans une technologie « phare ». Initiée au début des années 2000 par Microsoft, elle n'a depuis cessé d'évoluer et de s'étendre. Dans cette série de tutoriels, nous allons approfondir notre connaissance de la plateforme .Net, en explorant ses différents composants dont le ramasse-miette, le CIL ou encore le CLR sont de dignes représentants.

Ce premier tutoriel est consacré à une présentation rapide de l'histoire de la plateforme .Net et de ses fonctionnalités.

2 commentaires Donner une note à l'article (5) 

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Présentation

Depuis la création du tout premier Windows, Microsoft a mis à disposition une API (Application Programming Interface) afin de permettre aux développeurs de concevoir des logiciels exploitant les fonctionnalités fournies par le système d'exploitation.

Cette API, ou plutôt ces API, car il y en a eu plusieurs, ont marqué différentes générations et ont énormément évolué au fil des années. De nouvelles API ont fait leur apparition, tandis que d'autres se sont enrichies.

Parmi les API les plus marquantes de l'histoire de Windows, nous pouvons citer :

  • Win16 : la première API disponible sous Windows. Apparue avec Windows 3.1 sous le nom de « Windows API », elle était notamment destinée à un usage avec le langage C. Elle ciblait uniquement les architectures 16 bits ;
  • Win32 : avec l'apparition de l'architecture 32 bits, il était nécessaire de faire évoluer la précédente API afin de tirer profit au maximum des capacités de cette nouvelle architecture ;
  • MFC (Microsoft Foundation Class) : encapsulant l'API Win16 puis Win32 dans un paradigme objet, cette API facilitait l'utilisation du langage C++ pour le développement de logiciels ;
  • sans oublier des technologies comme COM, ATL, OLE ou encore ActiveX (liste non exhaustive), chacune pour répondre à des besoins spécifiques.

Ainsi, au fil des années, les API disponibles pour les développeurs se sont multipliées et enrichies, formant une jungle de plus en plus complexe. Afin de résoudre les problèmes inhérents à cette complexification croissante, Microsoft a développé une nouvelle technologie, une « technologie pour les gouverner toutes », dans le but d'harmoniser et de moderniser toutes ces API : la plateforme .Net.

Apparue au début des années 2000, cette technologie n'a depuis cessé à son tour d'évoluer afin de fournir aux développeurs toujours plus de fonctionnalités.

Le framework .Net est constitué de plusieurs composants, chacun ayant un rôle bien défini :

  • le « Common Language Runtime » ;
  • le « Common Intermediate Language (CILCommon Intermediate Language) ;
  • le « Common Type System (CTS) ;
  • la « Base Class Library » (BCL).

I-A. Common Intermediate Language

La plateforme .Net a cette particularité qu'elle n'est pas associée à un langage en particulier, contrairement aux autres API mises à disposition jusqu'alors (C pour Win16/13, C++ pour MFC, etc.).

En effet, la compilation d'un programme écrit dans un langage supportant la plateforme .Net génère non pas un code machine spécifique à une architecture donnée, mais un code « intermédiaire », utilisant un jeu d'instructions indépendant du processeur et qui sera exécuté par une machine virtuelle.

C'est ensuite cette machine virtuelle qui retranscrira le code intermédiaire dans un code machine correspondant à l'architecture sur laquelle est exécuté le programme.

Ce code intermédiaire porte le nom de « Common Intermediate Language » ou CIL.

Dans la littérature, il n'est pas rare de trouver ce langage intermédiaire sous le nom de « Microsoft Intermediate Language » ou MSIL. Il s'agit du premier nom qui a été donné à ce langage. La désignation « Common Intermediate Language » est apparue lors de la standardisation de la plateforme .Net et est de fait la désignation officielle.

Dans le langage courant, un code sous forme de langage intermédiaire est désigné comme un « code managé » à opposer à un langage classique comme le C ou le C++ dont la compilation génère un code machine spécifique à un processeur donné et qui est désigné comme « code natif ».

Le terme anglais correspondant est « managed code » dont la traduction littérale serait « code géré ». Néanmoins, cette traduction littérale n'étant pas usitée, il convient d'utiliser l'anglicisme « code managé ».

I-B. Common Language Runtime

Il s'agit de l'environnement dans lequel s'exécute tout code managé. Il fournit de nombreux services, que ce soit la gestion de la mémoire (ramasse-miette), la gestion des exceptions, la gestion des tâches, le chargement de code managé, les types de base (entier, chaîne de caractères…).

Le CLR est souvent vu comme une machine virtuelle, dans la mesure où il permet l'exécution d'un code écrit pour une architecture différente.

Il est à noter que le CLR n'est pas une spécification de l'environnement dans lequel s'exécute un code managé, mais une implémentation, réalisée par Microsoft, de la spécification « Common Language Infrastructure » (CLI). C'est cette spécification qui est LA référence décrivant l'environnement d'exécution.

Le CLR est considéré comme l'implémentation de référence du CLI, au point qu'il est parfois fait mention de CLR au lieu de CLI. Par exemple, le projet Mono, dont l'objectif est de fournir un environnement .Net sur des plateformes comme Linux ou MacOS, se décrit comme une implémentation open source du Framework .Net de Microsoft basé sur le standard ECMA pour C# et le « Common Language Runtime ». (1)

I-C. Dynamic Language Runtime

Le CLR que nous venons de voir ne supporte que les langages statiquement typés, c'est-à-dire que le type d'un objet doit être connu au moment de la compilation.

Or, il existe des langages dynamiquement typés, comme Python, où le type d'un objet peut être déterminé lors de l'exécution. Aussi, Microsoft a introduit un nouvel environnement d'exécution qui ajoute un ensemble de service au CLR pour le support des langages dynamiquement typés : le « Dynamic Language Runtime » ou DLR.

I-D. Common Type System

Comme précisé précédemment, la plateforme .Net ne dépend pas d'un langage particulier. Cela signifie d'une part que tout développeur peut écrire son code dans tout langage qui peut être compilé en CIL, mais également qu'il est nécessaire que des codes écrits dans des langages différents puissent interagir.

Et c'est justement là qu'intervient le « Common Type System » en décrivant tous les types supportés (entier, chaîne de caractères, etc.) d'une manière indépendante des langages afin qu'ils puissent interagir entre eux de manière transparente. Ainsi, un code C# pourra utiliser une classe définie dans une autre bibliothèque, qu'importe qu'elle ait été écrite en C#, en VB.Net, en C++/CLI, etc.

Pour parvenir à cela, le « Common Type System » :

  • définit le cadre général afin de permettre de passer d'un langage à un autre ;
  • fournit un modèle orienté-objet afin de supporter l'implémentation de nombreux langages sur la plateforme .Net ;
  • définit un ensemble de règles que les langages doivent suivre ;
  • fournit une liste de types primitifs (entier, booléen, chaîne de caractères, etc.).

I-E. Base Class Library

Il s'agit de la « bibliothèque standard » de la plateforme .Net. Très fournie, elle met à disposition de très nombreux services :

  • gestion des collections comme des listes, des tables de hashage, des piles, des queues… ;
  • des outils de diagnostic, en fournissant des services de traçage des événements, des compteurs de performances ou encore l'interaction avec d'autres processus ;
  • des outils de globalisation et d'internationalisation ;
  • la gestion des entrées/sorties ;
  • la gestion de la sécurité ;
  • la manipulation de texte ;
  • la gestion de tâches ;
  • la réflexivité ;
  • des services réseau ;
  • la manipulation de XML ;

I-F. Résumé

Image non disponible
Figure 1 : Plateforme .Net

La plateforme .Net regroupe :

  • une implémentation du Common Language Interface (CLI) ;
  • la bilbiothèque standard (Base Class Library).

L'implémentation du CLI est constituée du CLR et du DLR, qui exécute du code managé, c'est-à-dire un code dans le langage intermédiaire (CIL).

Tout ceci est très semblable à ce qui existe dans le monde Java. Un programme java (.Net) utilise la Java Class Library (Base Class Library) et est compilé en Bytecode (CIL) avant d'être exécuté dans une machine virtuelle (CLR).

II. Plateforme .Net et les langages

II-A. Common Language Specification

Précédemment, il a été dit que la plateforme .Net n'était pas associée à un langage en particulier (cf. Common Intermediate Language). Cela permet notamment d'écrire un composant dans un langage et de l'utiliser dans une application écrite dans un autre langage.

Jusqu'à présent, nous avons vu le Common Type System comme étant une base commune à tous les langages afin de permettre cette interopérabilité. Il s'agit malheureusement d'une base nécessaire, mais pas suffisante.

En effet, des langages peuvent avoir des spécifications différentes qui les rendent potentiellement incompatibles. Prenons un exemple simple : le C# et VB.Net. Le langage VB.Net n'est pas sensible à la casse, tandis que le C# l'est.

Ainsi, si on tente de définir deux classes « Personne » et « personne », nous n'aurons pas le même comportement en fonction du langage :

  • VB.Net : on aura une erreur de compilation, précisant que la classe est déjà définie ;
  • C# : on n'aura pas d'erreur de compilation, et les deux classes seront bien définies.

Si maintenant, depuis un code VB.Net, on essaie d'utiliser la classe « Personne » définie dans un composant écrit en C#, comment savoir s'il s'agit de la classe « Personne » ou de la classe « personne », dans la mesure où VB.Net n'est pas sensible à la casse ? Réponse : c'est impossible.

Aussi, une nouvelle couche a été définie, le « Common Language Specification » ou CLS, qui définit des règles permettant d'assurer une compatibilité entre les différents langages.

Dans l'exemple ci-dessus, la règle qui protège de cette problématique précise que les identifiants doivent être différents autrement que par la casse. Ainsi, le code C# définissant les deux classes « Personne » et « personne », bien que compilant, n'est pas CLS-compatible. Et de ce fait, ne sera pas utilisable dans tous les langages supportant la plateforme .Net.

Tout bon compilateur générera un avertissement dès lors qu'un code n'est pas CLS-compatible.

II-B. Liste des langages

La plateforme .Net supporte bon nombre de langages. Comme il est presque impossible de les citer tous (il y en a plus de 70 !), je me contenterai de citer les plus connus :

  • C# ;
  • VB.Net ;
  • C++ (connu sous le nom C++/CLI) ;
  • F# ;
  • Python (IronPython).

C# et VB.Net peuvent être vu comme des langages « principaux » de la plateforme .Net, dans le sens où ces langages, développés par Microsoft, sont souvent mis à jour en même temps que la publication d'une nouvelle version de la plateforme .Net. Par ailleurs, le C# a été spécifiquement conçu pour cette plateforme.

II-C. Fonctionnement

C:\Users\fdori\OneDrive\Professionnel\Developpez.com\Articles\Livre\Présentation\Compilation.png
Figure 2 : Compilation & Exécutions

Un code source est compilé en CLI via un compilateur dédié. Ensuite, le CLI est exécuté via le CLR/DLR.

Le DLR est un module bâti au-dessus du CLR afin d'en étendre ses fonctionnalités. Aussi, par abus de langage, CLR désigne souvent DLR + CLR.

III. Historique

Le framework .Net présenté jusqu'à présent n'a pas toujours été ainsi. La première version, parue en 2000 était loin d'avoir toutes les fonctionnalités présentes aujourd'hui. Le DLR n'existait pas, la bibliothèque standard n'était pas aussi fournie, le CLR a connu plusieurs versions et de nombreux aspects, non encore abordés jusqu'ici ont été améliorés et/ou ajoutés (le ramasse-miette, la gestion des tâches, etc.).

Le tableau ci-dessous synthétise les différentes versions du framework .Net, la version du CLR associée, la version des langages C# et VB.Net ainsi que les ajouts majeurs au niveau de la bibliothèque standard, des langages et du CLI.

Image non disponible
Figure 3 : Historique des différentes versions

Il faut noter que :

  • le Framework 4.5.x regroupe les frameworks 4.5, 4.5.1 et 4.5.2 ;
  • le framework 4.6.x regroupe les frameworks 4.6, 4.6.1 et 4.6.2 ;
  • VB 14 et C#6 viennent avec le framework 4.6 ;
  • VB 15 et C#7 viennent avec le framework 4.6.2.

IV. .NET Standard

Victime de son succès, la plateforme .Net s'est exportée sur d'autres environnements « non Windows » ces dernières années.

Les plus notables sont :

  • Mono : qui vise une compatibilité maximum avec l'implémentation de la plateforme réalisée par Microsoft ;
  • .Net Core : développée par Microsoft, elle vise la portabilité sur différents systèmes (Linux, MacOS, Windows) ;
  • Xamarin : pour le développement d'applications mobiles et tablettes en utilisant un langage unique (le C#).

Chacune de ces plateformes implémente les standards définis, notamment le CLI.

Mono et Xamarin ont été initialement développés par la société Xamarin. En 2016, Microsoft a racheté cette société, avec pour objectif de proposer et d'intégrer la solution Xamarin au cœur même de Visual Studio.

Néanmoins, il persiste une source d'incompatibilité entre ces plateformes. Cette source est la bibliothèque standard proposée avec chaque plateforme.

Mono a beau être une implémentation open source visant la compatibilité avec l'implémentation de la plateforme originelle de Microsoft, cette compatibilité n'est pas parfaite, notamment à cause de l'absence de certaines API.

.Net Core a été conçu pour la portabilité sur différents systèmes, avec pour objectif de pouvoir compiler une application et ensuite de la déployer sur n'importe quel système. Mais .Net Core dispose d'une bibliothèque standard (connue sous le nom de Core Library) parfois très différente de celle de la plateforme originelle, et très incomplète sur certains points (impossible, à l'heure actuelle, de réaliser une interface utilisateur graphique avec la Core Library, il faut se tourner vers des composants tiers).

Xamarin, a pour but d'unifier l'environnement de développement mobile :

  • en proposant un langage unique (le C#) pour le développement d'application mobile, que ce soit à destination des plateformes Android, iOS ou Windows Phone ;
  • en permettant aussi de partager du code entre ces différents environnements. Mais les bibliothèques standards pour Android, iOS et Windows Phone restent différentes.

Ainsi donc, fort de son succès, l'environnement .Net se retrouve à reproduire les mêmes problèmes qu'il était censé résoudre : la multiplication des plateformes, et donc des API. À une nuance près malgré tout : les langages restent les mêmes !

C'est donc de ce constat qu'est née l'initiative .NET Standard. Il s'agit d'une spécification de la bibliothèque standard fournie avec une plateforme. Il ne s'agit pas d'une spécification stricte, mais d'une spécification minimale, c'est-à-dire que .NET Standard spécifie un certain nombre d'API « de base », mais que chaque plateforme reste libre de venir l'enrichir.

L'objectif voulu est qu'un composant écrit en respectant .NET Standard puisse être utilisé sur toute plateforme respectant ce même standard.

À l'heure où sont écrites ces lignes, .NET Standard en est à sa version 1.6, mais la version 2.0 est déjà en préparation, puisque prévue pour le printemps 2017. Cette prochaine version est très attendue dans la mesure où elle spécifiera un certain nombre d'API utiles, notamment :

  • support étendu du XML (XLinq, XPath, XSD, XSL) ;
  • sérialisation ;
  • réseau ;
  • entrées / sorties ;
  • tâches.

À l'heure actuelle, la version 1.6 de .Net Standard spécifie principalement des API relatives :

  • à la compression ;
  • à la réflexion ;
  • aux requêtes Linq ;
  • à la cryptographie ;
  • à la manipulation de document XML.

Fort de cette nouvelle spécification, on peut espérer que les différentes plateformes tendent à converger et réduire ainsi la fragmentation induite par l'existence de plusieurs plateformes et ainsi éviter de retomber dans les écueils du passé.

Avant l'apparition de .Net Standard, il y a eu une première initiative d'interopérabilité entre les différentes plateformes avec les Portable Class Library (ou PCL). Il s'agissait de pouvoir écrire du code qui puisse ensuite être utilisé quelle que soit la plateforme cible. L'idée était de se restreindre aux API qui étaient communes à toutes les plateformes en prenant l'intersection (au sens mathématique du terme) des bibliothèques standards des différentes plateformes. Aujourd'hui, il est recommandé d'utiliser .Net Standard pour les nouveaux projets et les PCL ne sont gardées que pour des raisons de compatibilité.

V. Remerciements

Pour leur relecture technique, je tiens à remercier :

Je remercie également Claude LELOUP pour sa relecture orthographique

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   


« Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime ». Phrase présente sur la page d'accueil au 07 mai 2017.

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2017 François DORIN. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.