La plateforme .NET

Introduction

Au travers de la plateforme .NET, Microsoft fournit un ensemble d’outils et de technologies destinées au développement d’applications ciblant des configurations logicielles et matérielles variées.

Le tableau ci-dessous donne un état des lieux global des possibilités actuelles de la plateforme sur différents systèmes d’exploitation.

Type d’applications	Windows	Linux	MacOS	Android	iOS
Applications Console
Applications fenêtrées (WinForms & WPF)
Applications Web
Applications mobiles

À l’origine, les différents types d’applications développées pouvaient l’être grâce à une brique commune : le Framework .NET. Ce framework est une solution logicielle qui comprend plusieurs composants dédiés au développement ou à l’exécution des applications. Il est fourni par Microsoft pour les systèmes d’exploitation Windows depuis la genèse de la plateforme. Très rapidement, la communauté open source a fourni son équivalent pour les systèmes Linux et MacOS au travers du projet Mono. Enfin, Microsoft a rejoint l’effort open source avec l’avènement de .NET Core, qui vise notamment à fournir un support officiel de la plateforme .NET sur les systèmes...

Historique de la plateforme

Depuis ses débuts, Windows expose ses fonctionnalités aux développeurs au travers d’interfaces de programmation (en anglais API pour Application Programming Interface) afin de permettre la création d’applications. Avec la complexification de Windows, différentes API ont vu le jour et évolué :

La plateforme .NET est apparue au début des années 2000 en réponse au problème de la complexification de ces API. Elle les unifie et les modernise, tout en permettant leur utilisation par n’importe quel langage possédant une implémentation compatible. C# a d’ailleurs été créé pour la plateforme .NET afin qu’un langage puisse exploiter toutes les capacités qu’elle offre.

L’unification des API et des modèles de développement a aussi touché le monde du Web. Microsoft fournissait en effet le moteur de script (côté serveur) ASP (Active Server Page) depuis le milieu des années 1990, mais il a été déprécié en faveur d’une brique intégrée au framework .NET : ASP.NET. Celle-ci a permis l’amélioration des performances des applications web en introduisant du code compilé, et non plus interprété. Elle a aussi amélioré leur maintenabilité en remplaçant la programmation procédurale typique des langages de script avec un modèle de programmation...

Évolution de la plateforme

Comme nous venons de la voir, au fil du temps, l’environnement .NET s’est enrichi de nombreuses fonctionnalités, dont certaines étaient/sont résolument novatrices. Les applications basées sur la plateforme peuvent être exécutées par des ordinateurs de bureau, des tablettes, des navigateurs web, des smartphones ou même dans de l’électronique embarquée. Le nombre de développeurs utilisant les langages basés sur le CLR a également considérablement augmenté, jusqu’à atteindre plusieurs millions à travers le monde.

À ce stade de maturation, de nouvelles problématiques se posent, autant au niveau des équipes de développement de Microsoft qu’au niveau de la communauté de développeurs qui utilisent cette technologie. On trouve notamment parmi les préoccupations le besoin de compatibilité/portabilité du code ou le besoin de modernisation des compilateurs C# et VB.NET.

En réaction à ces problématiques, les équipes de développement du framework .NET ont mis en place une spécification formelle des API de la plateforme : .NET Standard. Ils ont également retroussé leurs manches et écrit un tout nouveau compilateur pour C# et VB.NET : Roslyn.

Le Common Language Runtime (CLR)

L’exécution des applications Windows traditionnelles est prise en charge par le système d’exploitation. Ces programmes sont générés par un compilateur qui transforme des instructions écrites dans un langage comme C ou C++ en un fichier binaire contenant des instructions spécifiques à un système d’exploitation particulier et à une architecture de processeur spécifique. Par conséquent, dans ce cas de figure, plusieurs exécutables doivent être générés pour supporter les différentes configurations matérielles et logicielles des utilisateurs.

Une solution à cette problématique est de générer un exécutable dont le code est générique, indépendant de l’environnement d’exécution. Toutefois, son exécution ne peut pas être confiée directement au système d’exploitation puisqu’il n’est pas en mesure de traiter le code générique. Il est alors nécessaire d’insérer une brique logicielle dans la chaîne d’exécution, entre l’application et le système, afin de traduire le code générique en instructions adaptées à la machine. Un composant logiciel de ce type est appelé machine virtuelle.

C’est exactement ce principe qui est utilisé par la plateforme .NET. L’étape de compilation d’une application écrite avec Visual C# ou Visual Basic .NET produit un fichier exécutable dont le contenu est essentiellement écrit dans un langage générique nommé Microsoft Intermediate Language (ou MSIL). Lors de son exécution, c’est le Common Language Runtime (CLR) qui prend en charge ce code et assure le rôle de machine virtuelle....

La Base Class Library (BCL)

Chaque implémentation de la plateforme .NET inclut un ensemble de types de données permettant d’obtenir rapidement une solution à un grand nombre de problématiques qui peuvent être rencontrées au cours du développement d’une application.

Ces types de données sont organisés sous la forme d’une hiérarchie. Chaque niveau de cette hiérarchie est défini par un espace de noms (namespace) identifiant un groupement de types. Les espaces de noms sont nommés en concaténant le nom de leur parent, le symbole "." et leur propre nom, le tout désignant généralement le point commun des fonctionnalités fournies. L’espace de noms System.Xml regroupe par exemple un ensemble de classes permettant de traiter des données au format XML.

La BCL contient plusieurs milliers de types, et il est fort probable qu’une grande partie d’entre eux ne soit jamais utilisée dans vos développements. Certains d’entre eux sont en effet très spécifiques et utilisables dans un nombre limité de contextes. C’est par exemple le cas des types définis dans les espaces de noms Microsoft.Build ou System.CodeDom qui permettent respectivement d’interagir avec le moteur MSBuild et de générer du code C# ou Visual Basic .NET.

Parmi...

Le Dynamic Language Runtime (DLR)

Le Dynamic Language Runtime est une surcouche du Common Language Runtime, apparue avec la version 4.0 du Framework .NET, qui fournit des services facilitant l’implémentation et l’utilisation des langages dynamiques dans l’environnement .NET.

Depuis l’arrivée du DLR, il est possible de définir des variables .NET dont le type est dynamique, c’est-à-dire qu’il n’est pas fixé au moment de l’écriture du code. L’utilisation de cette fonctionnalité peut se révéler extrêmement pratique lorsqu’il est question d’interagir avec des applications écrites avec des langages dynamiques ou lorsque l’on souhaite utiliser certains composants COM. Les types de données renvoyés par ces éléments logiciels ne sont en effet pas forcément connus au moment de l’écriture du code et sont donc difficilement utilisables par un langage dont le typage est purement statique.

L’existence du Dynamic Language Runtime permet par conséquent de fournir une implémentation de langages dynamiques comme Python ou Ruby pour la plateforme .NET. Ces deux langages ont d’ailleurs déjà été portés pour .NET sous les noms IronPython et IronRuby.

Il est également possible grâce au DLR de créer des applications .NET...

Une première application avec C#

Pour découvrir C#, nous étudierons ici l’écriture d’une application très simple ainsi que le processus de compilation du code. Cette première phase sera suivie d’une étape d’analyse de l’exécutable généré.

using System; 
 
namespace MaPremiereApplicationCSharp 
{ 
    class Program  
    {  
        static void Main()  
        {  
            Console.WriteLine("Hello world !");  
 ...