AccueilđŸ‡«đŸ‡·Chercher

Microsoft .NET

Microsoft .NET (prononcé « dot net »[1])[2] est le nom donné à un ensemble de produits et de technologies informatiques de l'entreprise Microsoft pour rendre des applications facilement portables sur Internet. Le but est de fournir un serveur web local permettant de gérer des services et évitant d'externaliser des données privées sur un service web de stockage ou un hébergement web tiers.

La plate-forme .NET s'appuie sur plusieurs technologies :

Principales caractéristiques de .NET

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.
VersionNuméro de versionC# VersionDate de sortieVisual StudioPar défaut dans Windows
1.01.0.3705.0C# 1.0Visual Studio .NET 2002Windows XP versions Tablette et Media Center
1.11.1.4322.573C# 1.1Visual Studio .NET 2003Windows Server 2003
2.02.0.50727.42C# 2.0Visual Studio 2005Windows Server 2003 R2
3.03.0.4506.30C# 3.0Windows Vista, Windows Server 2008
3.53.5.21022.8C# 3.0Visual Studio 2008Windows 7, Windows Server 2008 R2
4.04.0.30319.1C# 4.0Visual Studio 2010Windows Server 2008 R2 SP1
4.54.5C# 5.0Visual Studio 2012Windows 8, Windows Server 2012
4.5.14.5.50938.18408C# 5.0Visual Studio 2013Windows 8.1, Windows Server 2012R2
4.64.6.00081C# 6.0Visual Studio 2015Windows 10, Windows Server 2016
4.6.2C# 7.0Visual Studio 2017Windows 10
4.7C# 7.1Visual Studio 2017 v15.3Windows 10
4.7.1C# 7.2Visual Studio 2017 v15.5Windows 10
4.7.2C# 7.3Visual Studio 2017 v15.7Windows 10
4.8 Windows 10

Architecture

Visualisation du fonctionnement de la Common Language Infrastructure (CLI)

CLI, CIL et CLR

Le framework .Net repose sur la Common Language 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é

La sĂ©curitĂ© est gĂ©rĂ©e par le CAS (Code Access Security). CAS est fondĂ© 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

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 processeurs[4]. 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 marques. 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 fondé 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 objets[5].

Ancien logo.

Avantages

  • Le framework, maintenant en 4.8, est une bibliothĂšque homogĂšne, efficace et performante.
  • Avec l’avĂšnement des applications web, l'environnement .Net devient accessible sur n'importe quel client, MVC5 fournit tous les outils pour dĂ©velopper des WebAPI serveur et des interfaces HTML5 Clients. Quant au WPF browser il est lui supportĂ© sur desktop via des plugins chrome et firefox.
  • Mono et Xamarin ont rendu disponible l'environnement .Net en natif sur Android, iOS et Linux.

Inconvénients

  • 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 rendues possibles 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 CLR[6].
  • Les langages compilĂ©s Ă  la volĂ©e produisent du code qui peut ĂȘtre plus facilement rĂ©tro-analysĂ© que s'il Ă©tait Ă©crit en code natif, avec par exemple avec des outils comme dotPeek de JetBrains, oĂč la qualitĂ© de la dĂ©compilation permettent quasiment une recompilation directe du code rĂ©tro-dĂ©compilĂ©. 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). Ce type d'outil tente de limiter les analyses ou altĂ©rations du code binaire rendus possible par des logiciels comme Reflector[7] ou Reflexil[8].
  • 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 Profile[9], et qui ne pĂšse que 26,5 Mio.

Notes et références

  1. Développement sécurisé avec Microsoft.Net et HP Fortify, Microsoft Développeurs France La scÚne se produit à 33 s.
  2. prononcĂ© /dɒt nɛt/ en anglais car dot est l'Ă©quivalent anglophone du mot point.
  3. Prononcé « C charpe ».
  4. (en) « Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework » (consulté le )
  5. (en) « Garbage Collection—Part 2: Automatic Memory Management in the Microsoft .NET Framework » (consultĂ© le )
  6. « Head-to-head benchmark: C++ vs .NET », sur www.codeproject.com
  7. « .NET Decompiler: Decompile Any .NET Code - .NET Reflector », sur www.red-gate.com
  8. « www.reflexil.net », sur www.reflexil.net
  9. « List of archived blogs », sur docs.microsoft.com

Voir aussi

Articles connexes

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.