Architecture .NET

Microsoft .NET
Développeur	Microsoft
Dernière version	3.5.21022.8 (le 19 novembre 2007) [+/−]
Environnement	Windows NT 4.0, Windows 98 et supérieurs
Type	Plate-forme
Licence	MS-EULA, BCL sous Microsoft Reference License
Site Web	www.microsoft.com/net

Microsoft .NET^[1] est le nom d'un ensemble de produits et de technologies informatiques de l'entreprise Microsoft pour rendre ses applications portables ou facilement accessibles par Internet. Les futures versions du système d'exploitation seront en fait un serveur web local permettant de gérer de nombreux services évitant d'externaliser des données privées sur un service web (Yahoo!, Google, Amazon.com), de stockage ou spécialisé dans l'hébergement web.

Microsoft se base sur plusieurs technologies :

• des protocoles de communication basées sur Le Framework .NET et non plus COM, OLE
• un langage plus simple que C/C++, Visual Basic, Java, J# comme le langage C#
• une bibliothèque compatible framework .NET et non plus MFC, GDI…
• une machine d'exécution architecture basé sur la CLI libre, portable et multi-langage
• un outil de gestion de projet ouvert MSBuild avec plusieurs compilateurs ([1])
• un IDE de développement plus performant (Métaprogrammation) et compatible Visual C++ sous le nom de Visual Studio
• un ensemble de bibliothèques haut niveau et robuste Windows Live ID, Framework .NET
• une portabilité pour les systèmes d'exploitation Windows et Windows Mobile
• des composants facilitant le développement de services (MapPoint) et d'applications aussi bien locales que web (ASP.NET)

Le Framework .Net a été conçu par Anders Hejlsberg, le père de Delphi. Celui-ci a développé entre autres le langage C#^[2].

Sommaire 1 Principales caractéristiques de .NET 2 Architecture 2.1 CLI 2.2 CIL 2.3 CLR 2.3.1 CLR et Sécurité 2.3.2 CLR et Gestion de la mémoire 3 Avantages et inconvénients 4 Notes et références 5 Voir aussi 5.1 Articles connexes 5.2 Liens externes

Principales caractéristiques de .NET

Interopérabilité 

Du fait de la nécessité d'interagir entre les nouvelles et les anciennes applications, le framework fournit des moyens pour accéder aux fonctionnalités qui sont mises en œuvre dans les programmes qui s'exécutent en dehors de l'environnement .NET . La possibilité d'accéder aux composants COM est fournie par les espaces de noms System.Runtime.InteropServices et System.EnterpriseServices. L'accès aux autres fonctionnalités est fourni grâce à P/Invoke.

Common Runtime Engine 

Les langages de programmation du framework sont compilés dans un langage intermédiaire connu sous le nom de Common Intermediate Language, ou CIL (anciennement connu sous le nom de Microsoft Intermediate Language, ou MSIL). Ce langage n'est pas interprété, mais subit une compilation à la volée et une compilation au niveau de la Common Language Runtime (CLR). La CLR est l'implémentation de la CLI.

Indépendance du langage 

La spécification du Common Type System (ou CTS) définit l'ensemble des types de données et structures de programmation supportés par la CLR ainsi que comment ils peuvent ou non interagir entre eux. Par conséquent, le .NET Framework supporte l'échange des instances des types entre les programmes écrits avec n'importe lequel des langages .NET.

Architecture

Le cœur du .Net Framework repose dans la Common Langage Infrastructure (ou CLI). Le but de la CLI est de fournir un langage indépendant de la plate-forme, aussi bien pour le développement que pour l'exécution. La CLI inclut des fonctions pour gérer les erreurs, le ramasse-miettes, la sécurité et l'interopérabilité avec les objets COM. L'implémentation Microsoft de la CLI est appelée Common Language Runtime (ou CLR).

CLI

voir Common Language Infrastructure

CIL

voir Common Intermediate Language

CLR

voir CLR, DLR et Machine virtuelle applicative

CLR et Sécurité

Le .NET Framework a son propre mécanisme de sécurité. Ses deux 'composants' principaux sont CAS (Code Access Security) et la validation et vérification. CAS est basé sur un système de preuves associées à une assembly particulière. Typiquement, la preuve est l'origine de l’assembly (Installation en local, téléchargement à partir d'Internet ou d'un Intranet, …). CAS utilise cette preuve pour déterminer les permissions données au code. Un code peut demander une autorisation pour le code qu'il appelle. La demande d'autorisation sait que le CLR parcourt la pile d'appel : chaque assembly de chaque méthode dans la pile est vérifiée. Si au moins une de ces assembly n'est pas autorisée à avoir la permission demandée une erreur est levée.

Quand une assembly est chargée, le CLR effectue divers tests. Deux d'entre eux sont la validation et la vérification. Pendant la validation, le CLR vérifie que l’assembly contient un code et des métadonnées valides. Après cela, il vérifie que les tables internes sont correctes. En fait la vérification n'est pas si exacte que cela, elle vérifie juste que le code ne fait rien de non-sûr (unsafe). Le code non-sûr sera exécuté uniquement si l’assembly a la permission ‘skip verification’.

Le .NET Framework utilise des appdomains (domaine d'application) comme mécanisme pour isoler le code d'un processus. Un appdomain peut être créé et du code chargé ou déchargé d'un appdomain indépendamment des autres appdomains. Les appdomains peuvent aussi être configurés indépendamment avec différents privilèges de sécurité. Ceci peut aider à améliorer la sécurité d'une application en séparant le code potentiellement non-sûre du reste. Cependant, le développeur doit séparer l'application en plusieurs sous-domaines, ceci n'est pas à la charge du CLR.

CLR et Gestion de la mémoire

Le CLR du .NET Framework décharge le développeur du fardeau qu'est la gestion de la mémoire (allocation et libération une fois fini) ; le CLR effectue cette gestion lui-même. L'allocation de la mémoire pour les instances des types .NET (objets) est effectuée de façon continue à partir du tas. Aussi longtemps qu'il existe une référence vers un objet, qu'elle soit directe ou indirecte via un graphe, l'objet est considéré comme étant utilisé par le CLR. À partir du moment où il n'y a plus de référence sur un objet et par conséquent, qu'il ne peut plus être atteint ou utilisé, il devient un déchet. Cependant, il continue d'utiliser la mémoire qui lui a été allouée. Le .NET Framework possède un composant appelé ramasse-miettes (en anglais Garbage Collector) qui s'exécute périodiquement sur un processus léger différent de celui de l'application. Il énumère tous les objets inutilisés et récupère la mémoire qui leur était allouée.

Le ramasse-miettes du .NET est non déterministe. Le ramasse-miettes s'exécute seulement après qu'une certaine quantité de mémoire ait été allouée ou s'il y a un problème de manque de mémoire. Par conséquent, il n'y a pas moyen de déterminer quand les conditions de déclenchement du ramasse-miettes sont satisfaites, celui-ci s'exécute donc de façon non-déterministe. Chaque application .NET possède un ensemble d'éléments racines qui sont des pointeurs maintenus par le CLR et qui pointent sur les objets du tas géré. Ceci inclut des références aux objets statiques, à ceux définis comme variables locales, aux paramètres définis dans la portée courante du code et enfin aux registres processeurs^[3]. Quand le ramasse-miettes s'exécute, il met en pause l'application et pour chaque objet référencé dans la racine, il énumère récursivement tous les objets qu'il peut atteindre et les marque. Il utilise les métadonnées .NET et la réflexion pour découvrir les objets encapsulés par un autre objet et les parcourt récursivement. Il énumère ensuite tous les objets sur le tas (qui étaient initialement alloués de façon continue) en utilisant la réflexion ; tous les objets qui n'ont pas été marqués sont alors considérés comme des déchets. C'est la phase de marquage. Puisque la mémoire détenue par ces déchets n'a plus d'importance, elle est considérée comme de l'espace libre. Cependant, ce procédé laisse des bouts de mémoire libre entre chaque objet encore référencé par l'application. Ces objets sont ensuite compactés en utilisant memcpy pour les déplacer et rendre l'espace mémoire utilisé à nouveau continu. Chaque pointeur rendu invalide par le déplacement de l'objet sur lequel il pointait est mis à jour avec le nouvel emplacement par le ramasse-miettes. Après ces opérations, l'application poursuit son cours.

En réalité, le ramasse-miettes utilisé par le .NET Framework est basé sur un système de génération. Chaque objet se voit affecté à une génération; les objets nouvellement crées appartiennent à la génération 0. Les objets qui survivent à la première passe du ramasse-miettes se voient promus à la génération 1 et les objets qui survivent à une deuxième passe sont promus à la génération 2. Le .NET n'utilise pas d'autre niveau de génération. Les objets ayant un niveau de génération élevé sont moins souvent analysés par le ramasse-miettes que les objets ayant un faible niveau de génération. Cet algorithme améliore l'efficacité du ramasse-miettes, car les vieux objets ont tendance à avoir une durée de vie plus longue que les nouveaux objets. Par conséquent, moins d'objets ont besoin d'être analysés et compactés^[4].

Avantages et inconvénients

• Microsoft ne fournit les implémentations du framework .NET que pour ses systèmes d'exploitations tel que Windows, Windows CE et la Xbox 360. Microsoft laisse le portage sur les autres systèmes d'exploitations en rendant disponibles les spécifications de la CLI mais pas des frameworks. Les classes de bases Base Class Library ( BCL), sont une partie de la bibliothèque de classes du framework (Framework Class Library ou FCL). La BCL fournit des classes qui encapsulent un certain nombre de fonctions courantes, comme la lecture et l'écriture de fichiers, le rendu graphique, l'interaction avec les bases de données, la manipulation de documents XML, etc. Le code source de la BCL a été rendu disponible pour faciliter le débugage des sessions dans Visual Studio 2008.
• La totalité du code source du framework n'est pas encore disponible (cependant cela devrait arriver dans un futur proche) [2]. Il est actuellement possible de télécharger une bonne partie de la source du framework [3].
• .NET ne fonctionnant pleinement que sous Windows, il est très difficile de changer de système d'exploitation comme Mac OS X ou Linux, ce qui crée une relation de dépendance au seul fournisseur Microsoft. Cependant, le projet Mono [4] est en train de pallier ce problème.
• Les applications fonctionnant avec du code managé en utilisant les environnements tels que le CLR du Framework Microsoft ou la JVM Java ont tendance à nécessiter plus de ressources systèmes que des applications fournissant les mêmes fonctionnalités mais qui accèdent plus directement aux ressources. Cependant, certaines applications ont montré de meilleures performances en utilisant le .NET Framework qu'en utilisant leur version en code natif. Ceci peut être attribué aux optimisations du runtime rendu possible par un tel environnement, à l'utilisation de fonctions performantes au sein du .NET Framework, à la compilation à la volée du code managé ou encore à certains aspects de la CLR.
• Les langages compilés à la volée produisent du code qui peut être plus facilement rétro-analysé que s'ils étaient écrits en code natif, par conséquent il y a un risque en ce qui concerne la perte de secrets ainsi qu'un risque de passer outre les mécanismes de contrôle de licence. Cependant, plusieurs techniques pour rendre le code impénétrable ont déjà été développées pour empêcher ça. Visual Studio 2005 inclut un tel outil (dotfuscator) produit par PreEmptive Solutions.
• Dans un environnement managé tel que le CLR du .NET Framework ou la JVM Java, les exécutions récurrentes du ramasse-miettes pour récupérer la mémoire suspendent l'exécution de l'application pour un intervalle de temps imprédictible (typiquement quelques millisecondes). Ceci rend l'environnement non utilisable pour certaines applications qui doivent répondre dans des intervalles de temps très faibles (Système temps réel).
• Puisque le framework n'est pas installé avec les anciennes versions de Windows, une application qui a besoin du framework doit vérifier qu'il est présent, et s'il n'est pas présent, l'application doit guider l'utilisateur pour l'installer. Cette contrainte peut dissuader certains utilisateurs d'utiliser l'application.
• Les versions récentes du framework (3.5 et supérieures) ne sont pas pré-installées quelle que soit la version de Windows. Certains développeurs sont dérangés par la taille importante du framework (environ 54 Mio pour le .NET 3.0 et 197 Mio pour la version 3.5) et par la fiabilité des installateurs du .NET Framework pour les utilisateurs finaux. Ce problème est en partie résolu par l'introduction du .Net Client Profile^[5], qui ne pèse que 26,5 Mio.

Notes et références

Voir aussi

Articles connexes

• Implémentation Microsoft
  • Framework .NET
  • ADO.NET
  • ASP.NET
  • Managed code
  • Common Language Runtime
  • Common Intermediate Language
  • Common Type System
• Langages
  • .NET Languages
  • Common Language Infrastructure
  • C++/CLI
  • C#
  • F#
  • Microsoft Small Basic
  • IronPython
  • J#
  • JScript .NET
  • Visual Basic .NET
• Outils
  • Microsoft Visual C#
  • Borland Delphi .NET
  • Microsoft Visual Studio
  • Windows PowerShell
• Les implémentations Open Source :
  • Mono
  • DotGNU
  • Portable.NET

Liens externes

• (fr) Microsoft .NET - Site MSDN Contenu sur la plate-forme .NET de Microsoft
• (fr) Catégorie .NET de l’annuaire dmoz
• (fr) La rubrique Dotnet de developpez.com Articles, Cours, FAQs, sources et critiques de livres disponibles.

• Portail de l’informatique