.NET Framework

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche

.NET Framework
Logo .NET.svg
DotNet.svg
Pile de composants .NET Framework
Développeur(s)Microsoft
Première version14 février 2002 ; il y a 19 ans ( 2002-02-14 )
Version finale
4.8.0 Build 3928 / 25 juillet 2019 ; il y a 2 ans [1] ( 2019-07-25 )
Système opérateurWindows 98 ou version ultérieure, Windows NT 4.0 ou version ultérieure
Plate-formeIA-32 , x86-64 et ARM
Successeur.RAPPORTER
TaperCadre logiciel
LicenceMixte; voir § Licences
Site Internetdotnet .microsoft .com Modifiez ceci sur Wikidata

Le .NET Framework (prononcé comme « dot net » ) est un framework logiciel développé par Microsoft qui s'exécute principalement sur Microsoft Windows . Il comprend une grande bibliothèque de classes appelée Framework Class Library (FCL) et fournit l' interopérabilité des langages (chaque langage peut utiliser du code écrit dans d'autres langages) à travers plusieurs langages de programmation . Les programmes écrits pour .NET Framework s'exécutent dans un environnement logiciel (contrairement à un environnement matériel ) nommé Common Language Runtime (CLR). Le CLR est unl' application de la machine virtuelle qui fournit des services tels que la sécurité, la gestion de la mémoire et la gestion des exceptions . En tant que tel, le code informatique écrit à l'aide de .NET Framework est appelé « code managé ». FCL et CLR constituent ensemble le .NET Framework.

FCL fournit l' interface utilisateur , l'accès aux données , la connectivité à la base de données , la cryptographie , le développement d' applications Web , les algorithmes numériques et les communications réseau . Les programmeurs produisent des logiciels en combinant leur code source avec .NET Framework et d'autres bibliothèques. Le framework est destiné à être utilisé par la plupart des nouvelles applications créées pour la plate-forme Windows. Microsoft produit également un environnement de développement intégré pour les logiciels .NET appelé Visual Studio .

.NET Framework a commencé en tant que logiciel propriétaire , bien que la société ait travaillé pour standardiser la pile logicielle presque immédiatement, avant même sa première version. Malgré les efforts de normalisation, les développeurs, principalement ceux des communautés du logiciel libre et open source , ont exprimé leur malaise face aux termes choisis et aux perspectives de toute implémentation libre et open source, notamment en ce qui concerne les brevets logiciels . Depuis lors, Microsoft a modifié le développement de .NET pour suivre de plus près un modèle contemporain de projet logiciel développé par la communauté, notamment en publiant une mise à jour de son brevet promettant de répondre aux préoccupations. [2]

En avril 2019, Microsoft a publié .NET Framework 4.8, la dernière version du framework en tant qu'offre propriétaire. Seules des corrections mensuelles de bugs de sécurité et de fiabilité pour cette version ont été publiées depuis lors. Aucune autre modification de cette version n'est prévue. [3]

Histoire

Microsoft a commencé à développer .NET Framework à la fin des années 1990, à l'origine sous le nom de Next Generation Windows Services (NGWS), dans le cadre de la stratégie .NET . Début 2000, les premières versions bêta de .NET 1.0 ont été publiées.

En août 2000, Microsoft et Intel ont travaillé à la standardisation de Common Language Infrastructure (CLI) et de C# . En décembre 2001, les deux ont été ratifiés par les normes Ecma International (ECMA). [4] [5] L'Organisation internationale de normalisation (ISO) a suivi en avril 2003. La version actuelle des normes ISO est ISO/IEC 23271:2012 et ISO/IEC 23270:2006. [6] [7]

Alors que Microsoft et leurs partenaires détiennent des brevets pour CLI et C#, ECMA et ISO exigent que tous les brevets essentiels à la mise en œuvre soient mis à disposition dans des « conditions raisonnables et non discriminatoires ». Les entreprises ont accepté de respecter ces conditions et de rendre les brevets disponibles sans redevance. Cependant, cela ne s'appliquait pas à la partie du .NET Framework non couverte par les normes ECMA-ISO, qui incluaient Windows Forms , ADO.NET et ASP.NET . Les brevets détenus par Microsoft dans ces domaines peuvent avoir dissuadé les implémentations non-Microsoft du framework complet. [8]

Le 3 octobre 2007, Microsoft a annoncé que le code source des bibliothèques .NET Framework 3.5 allait devenir disponible sous la licence Microsoft Reference Source (Ms-RSL [a] ). [9] Le référentiel de code source est devenu disponible en ligne le 16 janvier 2008 et comprenait BCL, ASP.NET, ADO.NET, Windows Forms, WPF et XML. Scott Guthrie de Microsoft a promis que les bibliothèques LINQ, WCF et WF étaient ajoutées. [dix]

Les variantes .NET Compact Framework et .NET Micro Framework du .NET Framework prenaient en charge d'autres plates-formes Microsoft telles que Windows Mobile , Windows CE et d'autres périphériques embarqués à ressources limitées. Silverlight a pris en charge les navigateurs Web via des plug-ins.

Logo Microsoft .NET Framework v4.5

En novembre 2014, Microsoft a également produit une mise à jour de ses octrois de brevets, qui étend encore la portée au-delà de ses engagements antérieurs. Des projets antérieurs comme Mono existaient dans une zone grise légaleparce que les subventions antérieures de Microsoft ne s'appliquaient qu'à la technologie dans les « spécifications couvertes », y compris strictement les 4e éditions chacune d'ECMA-334 et ECMA-335. La nouvelle promesse de brevet, cependant, ne place aucun plafond sur la version de spécification, et s'étend même à toutes les technologies d'exécution .NET documentées sur MSDN qui n'ont pas été formellement spécifiées par le groupe ECMA, si un projet choisit de les implémenter. Cela permet à Mono et à d'autres projets de maintenir la parité des fonctionnalités avec les fonctionnalités .NET modernes qui ont été introduites depuis la publication de la 4e édition sans risquer de litige concernant les brevets concernant la mise en œuvre de ces fonctionnalités. La nouvelle concession maintient la restriction selon laquelle toute implémentation doit maintenir une conformité minimale avec les parties obligatoires de la spécification CLI. [11]

Le 31 mars 2016, Microsoft a annoncé lors de Microsoft Build qu'ils renouvelleraient complètement la licence Mono sous une licence MIT, même dans les scénarios où une licence commerciale était auparavant nécessaire. [12] Microsoft a également complété sa promesse de brevet antérieure pour Mono, déclarant qu'ils ne revendiqueront aucun "brevet applicable" contre les parties qui "utilisent, vendent, proposent à la vente, importent ou distribuent Mono". [13] [14] Il a été annoncé que le Projet Mono a été contribué à la Fondation .NET. Ces développements font suite à l'acquisition de Xamarin , qui a débuté en février 2016 et s'est achevée le 18 mars 2016. [15]

Le communiqué de presse de Microsoft souligne que l'engagement multiplateforme permet désormais une pile .NET côté serveur entièrement open source et moderne. Microsoft a publié le code source de WPF, Windows Forms et WinUI le 4 décembre 2018. [16]

Architecture

Présentation visuelle de l'infrastructure de langage commun (CLI)

Infrastructure de langage commun

Common Language Infrastructure (CLI) fournit une plate-forme indépendante du langage pour le développement et l'exécution d'applications. En implémentant les aspects essentiels de .NET Framework dans le cadre de l'interface de ligne de commande, ces fonctions ne seront pas liées à un seul langage mais seront disponibles dans les nombreuses langues prises en charge par le framework.

Common Language Runtime

.NET Framework inclut le Common Language Runtime (CLR). Il sert de moteur d'exécution de .NET Framework et offre de nombreux services tels que la gestion de la mémoire , la sécurité de type , la gestion des exceptions , la collecte des ordures , la sécurité et la gestion des threads . Tous les programmes écrits pour .NET Framework sont exécutés par le CLR.

Les programmes écrits pour .NET Framework sont compilés en code Common Intermediate Language (CIL), au lieu d'être directement compilés en code machine . Pendant l'exécution, un compilateur juste-à-temps (JIT) spécifique à l' architecture transforme le code CIL en code machine.

Assemblées

Le code CIL compilé est stocké dans des assemblys CLI . Comme l'exige la spécification, les assemblys sont stockés au format de fichier Portable Executable (PE), commun sur la plate-forme Windows pour toutes les bibliothèques de liens dynamiques (DLL) et les fichiers EXE exécutables . Chaque assembly se compose d'un ou plusieurs fichiers, dont l'un doit contenir un manifeste contenant les métadonnées de l'assembly. Le nom complet d'un assembly (à ne pas confondre avec le nom de fichier sur le disque) contient son nom en texte simple, son numéro de version, sa culture et son jeton de clé publique . Les assemblages sont considérés comme équivalents s'ils partagent le même nom complet.

Une clé privée peut également être utilisée par le créateur de l'assembly pour un nommage fort . Le jeton de clé publique identifie la clé privée avec laquelle un assembly est signé. Seul le créateur de la paire de clés (généralement la personne qui signe l'assembly) peut signer des assemblys qui ont le même nom fort qu'un assembly de version précédente, puisque le créateur possède la clé privée. Un nom fort est requis pour ajouter des assemblys au Global Assembly Cache .

À partir de Visual Studio 2015, la technologie de compilation native .NET permet la compilation du code .NET des applications de la plate-forme Windows universelle directement en code machine plutôt qu'en code CIL, mais l'application doit être écrite en C# ou en Visual Basic.NET. [17]

Bibliothèque de classe

.NET Framework inclut une implémentation des bibliothèques standard de base CLI . La bibliothèque de classes .NET Framework (FCL) est organisée en une hiérarchie d' espaces de noms . La plupart des interfaces de programmation d'applications (API) intégrées font partie des espaces de noms System.*ou Microsoft.*. Ces bibliothèques de classes implémentent de nombreuses fonctions courantes, telles que la lecture et l'écriture de fichiers, le rendu graphique, l'interaction avec la base de données et la manipulation de documents XML. Les bibliothèques de classes sont disponibles pour tous les langages compatibles CLI . La FCL implémente la bibliothèque de classes de base CLI (BCL) et d'autres bibliothèques de classes — certaines sont spécifiées par la CLI et d'autres sont spécifiques à Microsoft.

BCL comprend un petit sous-ensemble de l'ensemble de la bibliothèque de classes et constitue l'ensemble de classes de base qui sert d' API de base de CLR. [18] Pour .NET Framework, la plupart des classes considérées comme faisant partie de BCL résident dans mscorlib.dll, System.dllet System.Core.dll. Les classes BCL sont disponibles dans .NET Framework ainsi que ses implémentations alternatives, notamment .NET Compact Framework , Microsoft Silverlight , .NET Core et Mono .

FCL fait référence à l'intégralité de la bibliothèque de classes fournie avec .NET Framework. Il comprend un ensemble étendu de bibliothèques, notamment BCL, Windows Forms , ASP.NET et Windows Presentation Foundation (WPF), mais également des extensions aux bibliothèques de classes de base ADO.NET , Language Integrated Query (LINQ), Windows Communication Foundation (WCF) et Workflow Foundation (WF). FCL a une portée beaucoup plus large que les bibliothèques standard pour des langages comme C++ , et une portée comparable aux bibliothèques standard de Java .

Avec l'introduction d'implémentations alternatives (par exemple, Silverlight), Microsoft a introduit le concept de bibliothèques de classes portables (PCL) permettant à une bibliothèque consommatrice de s'exécuter sur plus d'une plate-forme. Avec la prolifération des plates-formes .NET, l'approche PCL n'a pas pu évoluer (les PCL sont des intersections définies de la surface d'API entre deux plates-formes ou plus). [19] En tant que prochaine étape évolutive de PCL, la bibliothèque standard .NET a été créée rétroactivement sur la base de laSystem.Runtime.dllAPI basées sur UWP et Silverlight. Les nouvelles plates-formes .NET sont encouragées à implémenter une version de la bibliothèque standard leur permettant de réutiliser les bibliothèques tierces existantes pour s'exécuter sans nouvelles versions de celles-ci. La bibliothèque standard .NET permet une évolution indépendante des couches de modèle de bibliothèque et d'application au sein de l'architecture .NET. [20]

NuGet est le gestionnaire de packages pour toutes les plateformes .NET. Il est utilisé pour récupérer des bibliothèques tierces dans un projet .NET avec un flux de bibliothèque global sur NuGet.org. [21] Les flux privés peuvent être maintenus séparément, par exemple, par un serveur de construction ou un répertoire de système de fichiers.

C++/CLI

Microsoft a introduit C++/CLI dans Visual Studio 2005, qui est un langage et un moyen de compiler des programmes Visual C++ à exécuter dans le .NET Framework. Certaines parties du programme C++ s'exécutent toujours dans un environnement d' exécution Visual C++ non managé, tandis que les parties spécialement modifiées sont traduites en code CIL et exécutées avec le CLR du .NET Framework .

Les assemblys compilés à l'aide du compilateur C++/CLI sont appelés assemblys en mode mixte, car ils contiennent du code natif et managé dans la même DLL. [22] De tels assemblys sont plus complexes à rétroconcevoir, car les décompilateurs .NET tels que .NET Reflector ne révèlent que le code managé.

Principe de conception

Interopérabilité

Étant donné que les systèmes informatiques nécessitent généralement une interaction entre des applications plus récentes et plus anciennes, .NET Framework fournit des moyens d'accéder aux fonctions implémentées dans des programmes plus récents et plus anciens qui s'exécutent en dehors de l'environnement .NET. L'accès aux composants COM ( Component Object Model ) est fourni dans System.Runtime.InteropServiceset les System.EnterpriseServicesespaces de noms du framework. L'accès aux autres fonctions se fait via Platform Invocation Services (P/Invoke). L'accès aux fonctions .NET depuis les applications natives se fait via la fonction P/Invoke inversée.

Indépendance linguistique

.NET Framework introduit un Common Type System (CTS) qui définit tous les types de données et constructions de programmation possibles pris en charge par CLR et comment ils peuvent ou non interagir conformément à la spécification CLI. En raison de 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 n'importe quel langage .NET conforme .

Tapez la sécurité

CTS et le CLR utilisés dans .NET Framework appliquent également la sécurité de type . Cela évite les transtypages mal définis, les invocations de méthodes incorrectes et les problèmes de taille de mémoire lors de l'accès à un objet. Cela rend également la plupart des langages CLI typés statiquement (avec ou sans inférence de type ). Cependant, à partir de .NET Framework 4.0, le Dynamic Language Runtime a étendu le CLR, permettant l'implémentation de langages à typage dynamique au-dessus de la CLI.

Portabilité

Bien que Microsoft n'ait jamais implémenté le framework complet sur aucun système à l'exception de Microsoft Windows, il a conçu le framework pour qu'il soit multiplateforme, [23] 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 pour CLI (qui inclut les bibliothèques de classes de base, CTS et CIL), [24] [25] [26] C# , [27] et C++/CLI [28] à Ecma International (ECMA) et International Organisation de normalisation(ISO), les rendant 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 plates-formes.

Sécurité

.NET Framework 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. Le CAS est basé sur des preuves associées à un assemblage spécifique. Généralement, la preuve est la source de l'assemblage (qu'elle soit installée sur la machine locale ou qu'elle ait été téléchargée à partir d'Internet). CAS utilise des preuves pour déterminer les autorisations accordées au code. Un autre code peut exiger que le code appelant reçoive une autorisation spécifiée. La demande amène le CLR à effectuer un parcours de pile d'appels : chaque assemblage de chaque méthode de la pile d'appels est vérifié pour l'autorisation requise ; si un assembly ne reçoit pas l'autorisation, une exception de sécurité est levée.

Le bytecode CIL géré est plus facile à rétroconcevoir que le code natif, à moins qu'il ne soit obscurci . [29] Les programmes de décompilation .NET permettent aux développeurs sans compétences en rétro-ingénierie de visualiser le code source derrière les assemblys .NET non obscurcis. En revanche, les applications compilées en code machine natif sont beaucoup plus difficiles à rétroconcevoir, et le code source n'est presque jamais produit avec succès, principalement à cause des optimisations du compilateur et du manque de réflexion . [30] Cela crée des inquiétudes dans la communauté des affaires concernant la perte possible de secrets commerciaux et le contournement des mécanismes de contrôle des licences. Pour atténuer cela, Microsoft a inclusDotfuscator Community Edition avec Visual Studio .NET depuis 2002. [b] Des outils d'obscurcissement tiers sont également disponibles auprès de fournisseurs tels que VMware , Vi Labs , Turbo et Red Gate Software . Des outils de chiffrement au niveau de la méthode pour le code .NET sont disponibles auprès de fournisseurs tels que SafeNet .

Gestion de la mémoire

CLR libère le développeur du fardeau de la gestion de la mémoire (allocation et libération une fois terminée) ; 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 managé ; un pool de mémoire géré par CLR. Tant qu'il existe une référence à un objet, qui peut être soit directe, soit via un graphe d'objets, l'objet est considéré comme en cours d'utilisation. Lorsqu'aucune référence à un objet n'existe et qu'il ne peut pas être atteint ou utilisé, il devient inutile, éligible pour la collecte.

.NET Framework inclut un garbage collector (GC) qui s'exécute périodiquement, sur un thread séparé du thread 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 ramasse - miettes non déterministe, compact, de marquage et de balayage . Le GC ne s'exécute que lorsqu'une quantité définie de mémoire a été utilisée ou qu'il y a suffisamment de pression pour la mémoire sur le système. Comme il n'est pas garanti que les conditions de récupération de mémoire soient atteintes, les analyses GC sont non déterministes . Chaque application .NET a un ensemble de racines, qui sont des pointeurs vers des objets sur le tas managé ( objets managés). Ceux-ci incluent des références à des objets statiques, des objets définis comme des variables locales ou des paramètres de méthode actuellement dans la portée, et des objets référencés par les registres CPU. [31] Lorsque GC s'exécute, il met l'application en pause puis, pour chaque objet référencé dans la racine, il énumère récursivement tous les objets accessibles à partir des objets racine et les marque comme accessibles. Il utilise les métadonnées et la réflexion CLI pour découvrir les objets encapsulés par un objet, puis les parcourir de manière récursive. Il énumère ensuite tous les objets du tas (qui ont été initialement alloués de manière contiguë) à l'aide de la réflexion. Tous les objets non marqués comme accessibles sont des ordures. [31] Telle est la marque phase. [32]Étant donné que la mémoire détenue par les ordures n'a aucune conséquence, 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 ensuite compactés pour rendre à nouveau contigu l'espace libre sur le tas géré. [31] [32] Toute référence à un objet invalidé en déplaçant l'objet est mise à jour par GC pour refléter le nouvel emplacement. [32] L'application reprend une fois la récupération de place terminée. La dernière version du framework .NET utilise la récupération de place simultanée avec le code utilisateur, rendant les pauses imperceptibles, car elles sont effectuées en arrière-plan. [33]

Le ramasse-miettes utilisé par .NET Framework est également générationnel . [34] 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 à un ramasse-miettes sont étiquetés Génération 1 . Les objets de génération 1 qui survivent à une autre collection sont de génération 2 . Le framework utilise jusqu'à des objets de génération 2. [34]​ Les objets de génération supérieure sont ramassés moins souvent que les objets de génération inférieure. Cela augmente l'efficacité de la récupération de place, car les objets plus anciens ont tendance à avoir une durée de vie plus longue que les objets plus récents. [34]En ignorant les objets plus anciens dans la plupart des cycles de collecte, moins de vérifications et d'opérations de compactage sont nécessaires au total. [34]

Performance

Lorsqu'une application est lancée pour la première fois, 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 cache d'image natif .NET. [35] [36] En raison de la mise en cache, l'application se lance plus rapidement pour les 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 à l' avance toute application .NET. [36]

Le ramasse-miettes, 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 applications volumineuses, le nombre d'objets avec lesquels le ramasse-miettes doit travailler peut devenir très important, ce qui signifie qu'il peut prendre beaucoup de temps pour tous les visiter et les réorganiser. » [37]

.NET Framework prend en charge l'appel d' extensions SIMD en continu (SSE) via un code managé à partir d'avril 2014 dans Visual Studio 2013 Update 2. Cependant, Mono a pris en charge les extensions SIMD à partir de la version 2.2 dans l'espace de noms Mono.Simd en 2009. [38 ] Le développeur principal de Mono, Miguel de Icaza, a exprimé l'espoir que ce support SIMD sera adopté par la norme ECMA de CLR. [39] Les extensions SIMD en streaming sont disponibles dans les processeurs x86 depuis l'introduction du Pentium III . Certaines autres architectures telles que ARM et MIPSont également des extensions SIMD. Si le CPU ne prend pas en charge ces extensions, les instructions sont simulées dans le logiciel. [ citation nécessaire ]

Implémentations alternatives

.NET Framework est l'implémentation prédominante des technologies .NET. D'autres implémentations pour des parties du cadre existent. Bien que le moteur d'exécution soit décrit par une spécification ECMA-ISO, d'autres implémentations de celui-ci peuvent être encombrées par des problèmes de brevets ; Les normes ISO peuvent inclure la clause de non-responsabilité : « L'attention est attirée sur la possibilité que certains des éléments de ce document puissent faire l'objet de droits de brevet. L'ISO ne sera pas tenue responsable de l'identification de tout ou partie de ces droits de brevet. » [40] Il est plus difficile de développer des alternatives au FCL, qui n'est pas décrit par un standard ouvert et peut être soumis à des restrictions de droit d'auteur. De plus, certaines parties de FCL ont des fonctions et un comportement spécifiques à Windows, de sorte que la mise en œuvre sur des plates-formes non Windows peut être problématique.

Certaines implémentations alternatives de certaines parties du cadre sont répertoriées ici.

  • .NET Micro Framework est une plate-forme .NET pour les appareils aux ressources extrêmement limitées. Il comprend une petite version de CLR et prend en charge le développement en C# (bien que certains développeurs aient pu utiliser VB.NET , [41] bien qu'avec une quantité de piratage et des fonctionnalités limitées) et le débogage (dans un émulateur ou sur du matériel), à la fois en utilisant Microsoft Visual Studio . Il comprend également un sous-ensemble de la bibliothèque de classes .NET Framework (environ 70 classes avec environ 420 méthodes), un framework GUI vaguement basé sur WPF et des bibliothèques supplémentaires spécifiques aux applications embarquées.
  • Mono est une implémentation de CLI et FCL et fournit des fonctions supplémentaires. Il est licencié en tant que logiciel libre sous la licence MIT . Il inclut la prise en charge des bibliothèques ASP.NET, ADO.NET et Windows Forms pour un large éventail d'architectures et de systèmes d'exploitation. Il inclut également les compilateurs C# et VB.NET.
  • Portable.NET (partie de DotGNU ) fournit une implémentation de CLI, des parties de FCL et un compilateur C#. Il prend en charge une variété de processeurs et de systèmes d'exploitation. Le projet a été interrompu, avec la dernière version stable en 2009.
  • Microsoft Shared Source Common Language Infrastructure est une implémentation non libre de CLR. Cependant, la dernière version fonctionne uniquement sur Windows XP SP2 et n'a pas été mise à jour depuis 2006. Ainsi, elle ne contient pas toutes les fonctionnalités de la version 2.0 de .NET Framework.
  • CrossNet [42] est une implémentation de CLI et de parties de FCL. Il s'agit d'un logiciel libre utilisant une licence MIT open source .

Licence

Les frameworks de code managé Microsoft et leurs composants sont concédés sous licence comme suit :

Composant Licence
.NET Framework (package redistribuable) Logiciel propriétaire [43]
Code source de référence de .NET Framework 4.5 et versions antérieures Licence de référence Microsoft (Ms-RSL [a] ) [9] [44]
Code source de référence de .NET Framework 4.6 Licence MIT [45]
Mono Licence MIT [46]
.NET (anciennement .NET Core)
CoreFX, CoreCLR et CLI
Licence MIT [47]
Micro-cadre .NET Licence Apache 2.0 [48]
Plateforme de compilateur .NET (nom de code "Roslyn") Licence MIT [49]
ASP.NET MVC , API Web et pages Web ( Razor ) Licence Apache 2.0 [50]
ASP.NET Core Licence Apache 2.0 [51]
Boîte à outils de contrôle ASP.NET Ajax Licence BSD [52]
Signal R ASP.NET Licence Apache 2.0 [53]
Cadre d'entité Licence Apache 2.0 [54]
NuGet Licence Apache 2.0 [55]

Voir aussi

Remarques

  1. ^ a b La licence était autrefois abrégée Ms-RL, mais Ms-RL fait maintenant référence à la licence réciproque de Microsoft .
  2. ^ Dotfuscator Community Edition 4.0

Références

  1. ^ "Télécharger le programme d'installation hors ligne de .NET Framework 4.8" . Microsoft . Archivé de l'original le 15 août 2019 . Consulté le 15 août 2019 .
  2. ^ "Microsoft se lance dans l'open source" . Opensource.com . 19 novembre 2014 . Consulté le 2 janvier 2020 .
  3. ^ gewarren. ".NET Framework et versions du système d'exploitation Windows" . docs.microsoft.com . Consulté le 21 novembre 2020 .
  4. Sauter^ « Norme ECMA-335 : Infrastructure de langage commun (CLI) » . ecma-international.org (6 éd.). ECMA . Juin 2012. Archivé de l'original le 26 juin 2013 . Récupéré le 31 août 2005 .
  5. ^ " Norme ECMA-334 : Spécification du langage C# " . ecma-international.org (4 éd.). ECMA . Juin 2006. Archivé de l'original le 31 octobre 2010 . Récupéré le 31 août 2005 .
  6. ^ "ISO/IEC 23271:2012 Technologies de l'information - Common Language Infrastructure" . iso.org (3 éd.). Organisation internationale de normalisation . 13 février 2012.
  7. ^ "ISO/IEC 23270:2006 - Technologies de l'information - Langages de programmation - C#" . iso.org (2 éd.). Organisation internationale de normalisation . 26 janvier 2012. Archivé de l'original le 6 décembre 2010 . Récupéré le 1er avril 2008 .
  8. ^ "La promesse vide de Microsoft" . Fondation du logiciel libre . 16 juillet 2009. Archivé de l'original le 19 août 2009 . Consulté le 3 août 2009 . Cependant, il existe plusieurs bibliothèques incluses avec Mono, et couramment utilisées par des applications comme Tomboy, qui ne sont pas requises par la norme. Et juste pour être clair, nous ne parlons pas de bibliothèques spécifiques à Windows comme ASP.NET et Windows Forms. Au lieu de cela, nous parlons de bibliothèques sous l'espace de noms System qui fournissent des fonctionnalités communes que les programmeurs attendent dans les langages de programmation modernes
  9. ^ un b Guthrie, Scott (3 octobre 2007). "Libérer le code source pour le NET Framework" . Le blog de Scott Guthrie . Microsoft . Archivé de l'original le 7 septembre 2010 . Consulté le 15 septembre 2010 .
  10. ^ Guthrie, Scott (16 janvier 2008). « Le code source de la bibliothèque .NET Framework est désormais disponible » . Le blog de Scott Guthrie . Microsoft . Consulté le 28 février 2015 .
  11. ^ "Promesse de brevet Microsoft pour les bibliothèques .NET et les composants d'exécution" . Archivé de l'original le 21 février 2021 . Consulté le 16 novembre 2014 .
  12. ^ Krill, Paul (1er avril 2016). "Le runtime Mono de Xamarin obtient une licence plus souple" . InfoMonde . IDG .
  13. ^ Ferraira, Bruno (31 mars 2016). "Xamarin est désormais gratuit avec Visual Studio" . Le rapport technique . Archivé de l'original le 2 avril 2016 . Consulté le 12 avril 2016 .
  14. ^ "Promesse de brevet Microsoft pour Mono" . Mono sur GitHub . Projet Mono. 28 mars 2016. Archivé de l'original le 16 avril 2016 . Consulté le 16 avril 2016 .
  15. ^ "Xamarin pour tous" . Blog Xamarin . Xamarin. 31 mars 2016. Archivé de l'original le 12 avril 2016 . Consulté le 12 avril 2016 .
  16. ^ "Annonce Open Source de WPF, Windows Forms et WinUI à Microsoft Connect 2018" . Blog des développeurs Windows . Microsoft. Archivé de l'original le 15 décembre 2018 . Consulté le 24 décembre 2018 .
  17. ^ reperusha. "Compiler des applications avec .NET Native" . docs.microsoft.com . Archivé de l'original le 3 décembre 2017 . Consulté le 2 décembre 2017 .
  18. ^ "Bibliothèque de classes de base" . Récupéré le 1er juin 2008 .
  19. ^ "Norme de plate-forme .NET" . Archivé de l'original le 19 mai 2016 . Consulté le 23 avril 2016 .
  20. ^ "Une mise à jour sur ASP.NET Core 1.0 RC2" . Consulté le 23 avril 2016 .
  21. ^ "Galerie NuGet - Accueil" . nuget.org . Archivé de l'original le 21 février 2021 . Récupéré le 21 février 2021 .
  22. ^ Assemblages mixtes (natifs et gérés) archivés le 22 octobre 2014, à la Wayback Machine , MSDN
  23. ^ "Scott Guthrie : Silverlight et le CLR multiplateforme" . Canal 9 . 30 avril 2007. Archivé de l'original le 25 mars 2015 . Consulté le 16 avril 2016 .
  24. ^ "ECMA 335 - Standard ECMA-335 Common Language Infrastructure (CLI) 4ème édition (Juin 2006)" . ECMA. 1er juin 2006. Archivé de l'original le 14 juin 2008 . Récupéré le 1er juin 2008 .
  25. Sauter^ "ISO/CEI 23271:2006" . Normes.iso.org. 29 septembre 2006. Archivé de l'original le 1er juillet 2018 . Consulté le 17 avril 2012 .
  26. ^ "Rapport technique TR/84 Common Language Infrastructure (CLI) - Informations dérivées du fichier XML de la partition IV" . ECMA. 1er juin 2006. Archivé de l'original le 25 mars 2015 . Consulté le 16 avril 2016 .
  27. ^ "Spécification du langage C# ECMA-334" . ECMA. 1er juin 2006. Archivé de l'original le 31 octobre 2010 . Récupéré le 31 août 2005 .
  28. ^ "Spécification standard du langage ECMA-372 C++/CLI" . ECMA. 1er décembre 2005. Archivé de l'original le 10 août 2008 . Consulté le 16 janvier 2008 .
  29. ^ Gartner, Inc. tel que rapporté dans "Hype Cycle for Cyberthreats, 2006", septembre 2006, Neil MacDonald; Amrit Williams, et al.
  30. ^ Cifuentes, Cristina (juillet 1994). "6 : Analyse du flux de contrôle" (PDF) . Techniques de compilation inversée (thèse). Université de technologie du Queensland . Archivé de l'original (PDF) le 22 novembre 2016.
  31. ^ A b c "Collecte des déchets: gestion automatique de la mémoire dans le Microsoft .NET Framework" . Archivé de l'original le 3 juillet 2007 . Récupéré le 1er juin 2008 .
  32. ^ A b c "garbage collection .NET" . Archivé de l'original le 25 mai 2008 . Récupéré le 1er juin 2008 .
  33. ^ "Le .NET Framework 4.5 inclut de nouvelles améliorations du ramasse-miettes pour les applications client et serveur" . Consulté le 2 octobre 2015 .
  34. ^ A b c d "Collecte des déchets-Partie 2: Gestion automatique de la mémoire dans le Microsoft .NET Framework" . Archivé de l'original le 26 juin 2007 . Récupéré le 1er juin 2008 .
  35. ^ "Comprendre la compilation juste-à-temps .NET" . telerik.com . 28 mai 2013. Archivé de l'original le 11 juin 2013 . Consulté le 21 mai 2015 .
  36. ^ a b Compilation MSIL en code natif Archivé le 19 avril 2015, à la Wayback Machine , MSDN, Microsoft
  37. ^ "Comprendre la collecte des ordures dans .NET" . 17 juin 2009.
  38. ^ "Notes de publication Mono 2.2 - Mono" . mono-project.com .
  39. ^ "Prise en charge SIMD de Mono: Rendre Mono sûr pour les jeux" . Tirania.org. 3 novembre 2008. Archivé de l'original le 4 novembre 2010 . Consulté le 17 avril 2012 .
  40. ^ ISO 9001:2008, Avant-propos
  41. ^ "Utilisation de VB.NET avec le .NET Micro Framework «/dev/mobile" . Christec.co.nz. 1er avril 2008 . Consulté le 17 avril 2012 .[ lien mort permanent ]
  42. ^ "CrossNet" . Codeplex.com. Archivé de l'original le 25 janvier 2010 . Consulté le 17 avril 2012 .
  43. ^ "EULA redistribuable Microsoft .NET Framework" . MSDN . Microsoft . Archivé de l'original le 2 avril 2015 . Consulté le 28 février 2015 .
  44. ^ Bray, Brandon (15 août 2012). "Annonce de la sortie de .NET Framework 4.5 RTM - Code produit et source" . Blog .NET Framework . Microsoft . Archivé de l'original le 4 octobre 2016 . Consulté le 18 août 2016 .
  45. ^ "Annonce de l'aperçu de .NET 2015 : une nouvelle ère pour .NET" . Blog .NET Framework . Microsoft . 12 novembre 2014. Archivé de l'original le 19 août 2016 . Consulté le 18 août 2016 .
  46. ^ "Xamarin pour tous" . Blog Xamarin . Microsoft . 17 avril 2016. Archivé de l'original le 12 avril 2016 . Consulté le 12 avril 2016 .
  47. ^ ".NET Core 5" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .
  48. ^ ".NET Micro Framework" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .
  49. ^ "Licence Roslyn" . GitHub . Fondation .NET. 5 février 2020. Archivé de l'original le 24 mars 2018 . Consulté le 14 avril 2018 .
  50. ^ "ASP.NET MVC, API Web et pages Web (Razor)" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .
  51. ^ "Licence de base ASP.NET" . GitHub . Fondation .NET. 5 juillet 2017. Archivé de l'original le 21 février 2021 . Consulté le 14 avril 2018 .
  52. ^ "Boîte à outils de contrôle ASP.NET Ajax" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .
  53. ^ "Signal ASP.NET" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .
  54. ^ "Cadre d'entité" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 18 avril 2016 . Consulté le 16 avril 2016 .
  55. ^ "NuGet" . dotnetfoundation.org . Fondation .NET. Archivé de l'original le 17 février 2015 . Consulté le 17 février 2015 .

Liens externes