CARECTERISTIQUES DU NET

Voir le sujet précédent Voir le sujet suivant Aller en bas

CARECTERISTIQUES DU NET

Message par FONDATEUR le Jeu 22 Sep - 22:45

Principales caractéristiques de .NET[modifier]

Interopérabilité
Du fait de la nécessité de pouvoir interagir avec les anciennes applications, le framework fournit des moyens pour accéder aux fonctionnalités 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 appelé 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 leurs interactions. Par conséquent, le .NET Framework supporte l'échange des instances des types entre les programmes écrits dans un des langages .NET.
Version Numéro de version Date de sortie Visual Studio Par défaut dans Windows
1.0 1.0.3705.0 13 février 2002 Visual Studio .NET 2002 Windows XP versions Tablette et Media Center
1.1 1.1.4322.573 24 avril 2003 Visual Studio .NET 2003 Windows Server 2003
2.0 2.0.50727.42 7 novembre 2005 Visual Studio 2005 Windows Server 2003 R2
3.0 3.0.4506.30 6 novembre 2006 Windows Vista, Windows Server 2008
3.5 3.5.21022.8 19 novembre 2007 Visual Studio 2008 Windows 7, Windows Server 2008 R2
4.0 4.0.30319.1 12 avril 2010 Visual Studio 2010 Windows Server 2008 R2 SP1
4.5 4.5 13 septembre 2011 (Developer Preview) Visual Studio '11' (Nom de code) Windows 8, Windows Server 8
Architecture[modifier]



Visualisation du fonctionnement de la Common Language Infrastructure (CLI)
CLI, CIL et CLR[modifier]
Articles détaillés : Common Language Infrastructure, Common Intermediate Language et Common Language Runtime.
Le framework .Net repose sur la Common Langage Infrastructure (ou CLI). Son but est de fournir un langage indépendant de la plate-forme, aussi bien pour le développement que pour l'exécution. Elle 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 de la CLI par Microsoft est appelée Common Language Runtime (ou CLR).
Voir aussi : Dynamic Language Runtime et Machine virtuelle de haut niveau.
CLR et Sécurité[modifier]
La sécurité est gérée par le CAS (Code Access Security). CAS est basé sur un système de preuves associées à une assembly particulière. 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 quand 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 exception est levée.
Quand une assembly est chargée, le CLR effectue divers tests dont 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, il vérifie que les tables internes sont correctes. La vérification vérifie que le code ne fait rien de dangereux. 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 appdomain. 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 dangereux du reste. Cependant, le développeur doit séparer l'application en plusieurs sous-domaines, ce qui n'est pas à la charge du CLR.
CLR et Gestion de la mémoire[modifier]
Le CLR prend en charge la gestion de la mémoire (allocation et libération). 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 (directe ou indirecte via un graphe), l'objet est considéré comme étant utilisé par le CLR. Dès qu'il n'y a plus de référence sur un objet (ie, il ne peut plus être ni atteint ni utilisé), le ramasse-miettes en anglais : Garbage Collector, qui s'exécute périodiquement sur un processus léger différent de celui de l'application, passe libérer l'objet de la mémoire.
Le ramasse-miettes du .NET est non-déterministe : il s'exécute seulement après qu'une certaine quantité de mémoire a été allouée ou s'il y a un défaut de mémoire. Il n'y a pas moyen de déterminer quand les conditions de déclenchement du ramasse-miettes sont satisfaites. 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és. 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 processeurs3. Quand le ramasse-miettes s'exécute, il suspend l'application et, pour chaque objet référencé dans la racine, il énumère récursivement, grâce aux métadonnées .NET et à la réflexion, tous les objets qu'il peut atteindre et les marque. 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. Cependant, ce procédé laisse des morceaux de mémoire libre entre les objets encore référencés ; ces objets sont ensuite compactés en utilisant memcpy pour rendre l'espace mémoire utilisé à nouveau continu. Les adresses des pointeurs sont mises à jour en conséquence. Après ces opérations, l'application reprend son exécution.
En réalité, le ramasse-miettes est basé sur un système de génération. Chaque objet se voit affecté à une génération ; les objets nouvellement créés appartiennent à la génération 0. Les objets qui restent après la première passe du ramasse-miettes se voient promus à la génération 1 et les objets qui restent après une deuxième passe sont promus à la génération 2 (niveau maximum). 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 espère améliorer l'efficacité du ramasse-miettes, car les vieux objets ont tendance à avoir une durée de vie plus longue que les nouveaux objets4.
Inconvénients[modifier]

Microsoft ne fournit le framework .NET que pour ses systèmes d'exploitations tel que Windows, Windows CE et la Xbox 360. Le portage sur d'autres systèmes d'exploitations est possible car les spécifications de la CLI sont disponibles (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 disponible5. Il est actuellement possible de télécharger une bonne partie de la source du framework6.
.NET ne fonctionnant pleinement que sous Windows, il est très difficile de changer de système d'exploitation ce qui crée une relation de dépendance au seul fournisseur Microsoft. Cependant, le projet Mono essaie 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 framework, à la compilation à la volée du « managed code » ou encore à certains aspects de la CLR7.
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[réf. nécessaire], par conséquent il y a un risque en ce qui concerne la perte de secrets et le risque de passer outre les mécanismes de contrôle de licence. Plusieurs techniques pour rendre le code impénétrable ont déjà été développées pour l'empêcher. Visual Studio 2005 inclut un tel outil (dotfuscator).
Puisque le framework n'est pas porté sur les anciennes versions de Windows, une application utilisant un 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 le manque de fiabilité des installateurs. Ce problème est en partie résolu par l'introduction d'une version allégée .Net Client Profile8, et qui ne pèse que 26,5 Mio.
Notes et références[modifier]

↑ prononcé « dotte nette » en anglais car dot est l'équivalent anglophone du mot point.
↑ (prononcé « C charpe »)
↑ (en)Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework [archive]. Consulté le 21 novembre 2007
↑ (en)Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework [archive]. Consulté le 21 novembre 2007
↑ [1] [archive]
↑ [2] [archive]
[Vous devez être inscrit et connecté pour voir ce lien] [archive]
[Vous devez être inscrit et connecté pour voir ce lien] [archive]
Voir aussi[modifier]

Articles connexes[modifier]
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
avatar
FONDATEUR
Admin

Messages : 2429
Points : 7531
Date d'inscription : 06/08/2011

Voir le profil de l'utilisateur http://algersoirnet.forumalgerie.net

Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum