InteroperabilityEdit
Parce que les systèmes informatiques nécessitent couramment une interaction entre les applications récentes et anciennes, .NET Framework fournit des moyens d’accéder aux fonctions implémentées dans les programmes récents et anciens qui s’exécutent en dehors de l’environnement .NET. L’accès aux composants du Component Object Model (COM) est fourni dans les espaces de noms System.Runtime.InteropServices et System.EnterpriseServices du framework. L’accès aux autres fonctions se fait via les services d’invocation de la plate-forme (P/Invoke). L’accès aux fonctions .NET à partir d’applications natives se fait via la fonction P/Invoke inverse.
Indépendance du langageEdit
Le Framework .NET introduit un système de type commun (CTS) qui définit tous les types de données et les constructions de programmation possibles pris en charge par le CLR et la façon dont ils peuvent ou non interagir conformément à la spécification CLI. Grâce à cette fonctionnalité, .NET Framework prend en charge l’échange de types et d’instances d’objets entre les bibliothèques et les applications écrites à l’aide de tout langage .NET conforme.
Sécurité des typesModifier
Le CTS et le CLR utilisé dans .NET Framework appliquent également la sécurité des types. Cela permet d’éviter les casts mal définis, les invocations de méthodes erronées et les problèmes de taille mémoire lors de l’accès à un objet. Cela permet également à la plupart des langages CLI d’être typés de manière statique (avec ou sans inférence de type). Cependant, à partir de .NET Framework 4.0, le Dynamic Language Runtime a étendu le CLR, permettant aux langages typés dynamiquement d’être implémentés au sommet du CLI.
PortabilitéEdit
Bien que Microsoft n’ait jamais implémenté le framework complet sur un système autre que Microsoft Windows, il a conçu le framework pour être multiplateforme, et des implémentations sont disponibles pour d’autres systèmes d’exploitation (voir Silverlight et § Implémentations alternatives). Microsoft a soumis les spécifications de CLI (qui comprend les bibliothèques de classes de base, CTS et CIL), C# et C++/CLI à Ecma International (ECMA) et à l’Organisation internationale de normalisation (ISO), les rendant ainsi disponibles en tant que normes officielles. Cela permet à des tiers de créer des implémentations compatibles du framework et de ses langages sur d’autres plateformes.
SecurityEdit
Le framework .NET possède son propre mécanisme de sécurité avec deux fonctionnalités générales : La sécurité d’accès au code (CAS), et la validation et la vérification. La CAS est basée sur des preuves qui sont associées à un assemblage spécifique. Généralement, la preuve est la source de l’assembly (qu’il soit installé sur la machine locale ou qu’il ait été téléchargé depuis Internet). CAS utilise les preuves pour déterminer les permissions accordées au code. Un autre code peut demander au code appelant de se voir accorder une permission spécifique. La demande amène le CLR à effectuer une marche de la pile d’appels : chaque assemblage de chaque méthode dans la pile d’appels est vérifié pour la permission requise ; si un assemblage ne se voit pas accorder la permission, une exception de sécurité est lancée.
Le bytecode CIL géré est plus facile à rétro-ingénier que le code natif, à moins qu’il ne soit obfusqué. Les programmes de décompilation .NET permettent aux développeurs n’ayant aucune compétence en rétro-ingénierie de visualiser le code source derrière les assemblages .NET non obfusqués. En revanche, les applications compilées en code machine natif sont beaucoup plus difficiles à désingénier, et le code source n’est presque jamais produit avec succès, principalement en raison des optimisations du compilateur et de l’absence de réflexion. Cela suscite des inquiétudes dans le monde des affaires quant à la perte éventuelle de secrets commerciaux et au contournement des mécanismes de contrôle des licences. Pour atténuer ce problème, Microsoft a inclus Dotfuscator Community Edition dans Visual Studio .NET depuis 2002. Des outils d’obfuscation tiers sont également disponibles auprès de fournisseurs tels que VMware, V.i. Labs, Turbo et Red Gate Software. Des outils de cryptage au niveau des méthodes pour le code .NET sont disponibles auprès de fournisseurs tels que SafeNet.
Gestion de la mémoireEdit
CLR libère le développeur du fardeau de la gestion de la mémoire (allocation et libération lorsque c’est fait) ; il gère lui-même la gestion de la mémoire en détectant quand la mémoire peut être libérée en toute sécurité. Les instanciations de types .NET (objets) sont allouées à partir du tas géré ; un pool de mémoire géré par CLR. Tant qu’il existe une référence à un objet, soit directement, soit via un graphe d’objets, l’objet est considéré comme utilisé. Lorsqu’aucune référence à un objet n’existe, et qu’il ne peut être atteint ou utilisé, il devient un garbage, éligible à la collecte.
.NET Framework inclut un garbage collector (GC) qui s’exécute périodiquement, sur un thread distinct de celui de l’application, qui énumère tous les objets inutilisables et récupère la mémoire qui leur est allouée. Il s’agit d’un ramasseur d’ordures non déterministe, compactant, avec marquage et balayage. GC ne s’exécute que lorsqu’une quantité déterminée de mémoire a été utilisée ou qu’il y a une pression suffisante pour la mémoire sur le système. Comme il n’est pas garanti que les conditions de récupération de la mémoire soient atteintes, les exécutions de GC sont non déterministes. Chaque application .NET possède un ensemble de racines, qui sont des pointeurs vers des objets du tas géré (objets gérés). Il s’agit notamment de références à des objets statiques, d’objets définis comme des variables locales ou des paramètres de méthode en cours d’exécution, et d’objets auxquels font référence les registres du CPU. Lorsque GC s’exécute, il met l’application en pause puis, pour chaque objet auquel la racine fait référence, il énumère récursivement tous les objets atteignables à partir des objets de la racine et les marque comme atteignables. Il utilise les métadonnées CLI et la réflexion pour découvrir les objets encapsulés par un objet, puis les parcourt récursivement. Il énumère ensuite tous les objets du tas (qui ont été initialement alloués de manière contiguë) en utilisant la réflexion. Tous les objets non marqués comme atteignables sont des déchets. C’est la phase de marquage. Comme la mémoire détenue par les déchets n’a pas d’importance, elle est considérée comme de l’espace libre. Cependant, cela laisse des morceaux d’espace libre entre les objets qui étaient initialement contigus. Les objets sont alors compactés ensemble pour rendre l’espace libre du tas géré à nouveau contigu. Toute référence à un objet invalidée par le déplacement de l’objet est mise à jour par GC pour refléter le nouvel emplacement. L’application est reprise après la fin du garbage collection. La dernière version de .NET Framework utilise un garbage collector concurrent en même temps que le code utilisateur, ce qui rend les pauses imperceptibles, car elles sont effectuées en arrière-plan.
Le garbage collector utilisé par .NET Framework est également générationnel. Les objets se voient attribuer une génération. Les objets nouvellement créés sont étiquetés génération 0. Les objets qui survivent à une collecte de déchets sont étiquetés génération 1. Les objets de génération 1 qui survivent à une autre collecte sont de génération 2. Le framework utilise des objets jusqu’à la génération 2. Les objets de génération supérieure sont collectés moins souvent que les objets de génération inférieure. Cela augmente l’efficacité du ramassage des ordures, car les objets plus anciens ont généralement une durée de vie plus longue que les objets plus récents. En ignorant les objets plus anciens dans la plupart des passages de collecte, moins de vérifications et d’opérations de compactage sont nécessaires au total.
PerformanceEdit
Lors du premier lancement d’une application, le .NET Framework compile le code CIL en code exécutable à l’aide de son compilateur juste-à-temps et met en cache le programme exécutable dans le .NET Native Image Cache. Grâce à la mise en cache, l’application se lance plus rapidement lors des lancements suivants, bien que le premier lancement soit généralement plus lent. Pour accélérer le premier lancement, les développeurs peuvent utiliser l’utilitaire Native Image Generator pour compiler et mettre en cache manuellement, en avance sur le temps, toute application .NET.
Le ramasseur de déchets, qui est intégré à l’environnement, peut introduire des retards d’exécution imprévus sur lesquels le développeur a peu de contrôle direct. « Dans les grandes applications, le nombre d’objets avec lesquels le ramasseur de déchets doit travailler peut devenir très important, ce qui signifie qu’il peut prendre un temps très long pour les visiter et les réorganiser tous. »
Le Framework .NET fournit une prise en charge de l’appel des extensions SIMD en continu (SSE) via le code géré depuis avril 2014 dans Visual Studio 2013 Update 2. Cependant, Mono a fourni un support pour les extensions SIMD dès la version 2.2 au sein de l’espace de noms Mono.Simd en 2009. Le développeur principal de Mono, Miguel de Icaza, a exprimé l’espoir que ce support SIMD soit adopté par la norme ECMA de CLR. Les extensions SIMD en continu sont disponibles dans les processeurs x86 depuis l’introduction du Pentium III. D’autres architectures telles que ARM et MIPS disposent également d’extensions SIMD. Dans le cas où le CPU n’a pas le support de ces extensions, les instructions sont simulées en logiciel.