Saveurs de la plateforme .NET

Quelques raccourcis :

Ce texte est écrit en 2020, peu de temps après les premières annonces de ce que sera C# 9.

On me demande parfois de distinguer les déclinaisons Framework, Standard, Core, etc. de la plateforme .NET. Bien que ce ne soit pas un sujet qui me passionne, la question est légitime et j'ai essayé de mettre sur la présente page un peu d'informations pour y répondre.

Notez que la question qui vous intéresse probablement en priorité est : « si je développe avec un langage .NET, quelle devrait être ma plateforme de choix? » et la réponse simple, au momet d'écrire ceci, est .NET version 5 si possible, sinon la version de .NET Core la plus à jour permise par les outils à votre disposition. Si vos outils vous imposent des restrictions plus rigides, alors il vous faudra vous adapter (accepter ces restrictions, changer d'outils, contourner le problème avec un peu de créativité, etc.).

Saveur « .NET Framework »

Le terme « cadriciel » est l'équivalent français communément reconnu pour le terme anglas Framework. J'utiliserai toutefois ici le terme « .NET Framework » car je réfère au produit du même nom, pas au concept général de cadriciel.

À l'origine (fin des années 1990 / début des années 2000), le cadriciel .NET se présentait pour l'essentiel comme une réponse à Java (certains enjeux légaux entre les compagnies derrière ces produits ont sûrement joué un rôle dans l'avènement de cette compétition, mais passons).

Là où la JVM de Java se voulait de prime abord une plateforme pour ce langage bien précis (même si plusieurs langages utilisent la JVM comme plateforme aujourd'hui), la plateforme .NET a été pensée dès le début pour supporter plusieurs langages.

Le langage C# était l'un des premiers « habitants » de cette plateforme, et il est vite devenu clair qu'il s'agissait du langage servant de moteur à la popularité de la plateforme dans son ensemble, mais d'autres langages (notablement VB.NET, successeur de VB 6, et le langage fonctionnel F#) ont rapidement été livrés pour profiter de la plateforme .NET.

Le cadriciel original a rapidement été standardisé en partie à travers l'organisme ECMA, alors qu'une partie de la technologie est demeurée propriétaire. Des implémentations à code ouvert de la partie standardisée ont été réalisées (DotGNU, aujourd'hui abandonné pour l'essentiel, mais surtout Mono) et utilisées pour des fins commerciales.

Compiler du code dans un langage .NET implique utiliser une version ou l'autre du .NET Framework. Quand vous utilisez des .dll tierces, les incompatibilités de versions du .NET Framework pour lesquelles elles sont compilées et de celle pour laquelle votre propre programme est compilé peuvent être un irritant.

Saveur « .NET Standard »

Comme l'explique Immo Landwerth dans .NET Standard: Demystifying .NET Core and .NET Standard en 2017, .NET Standard est un ensemble de classes destinées à être livrées pour .NET Core sur toutes les plateformes. L'objectif de .NET Standard était de permettre l'écriture de code .NET portable.

On peut voir .NET Standard comme un outil de transition. Avec l'avènement de la version 5 de .NET, la recommandation des artisans de cette plateforme est de produire le code destiné au présent et au futur avec .NET Core, du moins pour le code devant être portable.

Saveur « .NET Core »

Comme l'écrit Immo Landwerth dans Introducing .NET Core en 2014, le .NET Framework original était une architecture « verticale », peu modulaire, ce qui compliquait la conception de versions plus ciblées de .NET comme par exemple la version Compact, destinée aux appareils dont les ressources sont plus limitées. À chaque nouvelle déclinaison de la plateforme .NET, il fallait extraire une partie du .NET Framework, faire un projet distinct, et l'entretenir séparément des autres déclinaisons, ce qui entraînait une fragmentation de la plateforme et compliquait son entretien et sa mise à jour.

L'un des enjeux de cette fragmentation est que les systèmes informatiques contemporains ont des composants qui s'exécutent sur diverses plateformes et qui doivent interopérer; la plateforme .NET ayant été pensée pour supporter divers langages à travers un système de types commun, l'introduction de difficultés pour faire interopérer des composants conçus pour diverses déclinaisons de la plateforme peut surprendre.

Ce qui est devenu .NET Core est donc né du besoin d'avoir un ensemble de classes et d'autres outils qui seraient utilisables tels quels peu importe la plateforme ou la déclinaison de la plateforme .NET. Le projet .NET Core est un projet à la fois à code ouvert et multiplateforme.

Saveur « .NET version»

L'évolution de .NET Core est .NET version 5, qui se veut multiplateforme et devrait servir de base aux produits .NET portables (du moins, jusqu'à ce qu'elle soit remplacée par quelque chose de plus récent). Au moment d'écrire ceci, il s'agit de la version la plus récente de la plateforme.

Saveur « .NET version»

La version 5 de la plateforme .NET a été publiée officiellement en 2020. Vers la fin de 2020, Immo Landwerth a publié un texte expliquant sa vision de ce que serait éventuellement .NET version: https://github.com/microsoft/dotnet/blob/214c8c343587461f161198cdf5e9084abddde179/docs/ecosystem-issues.md

Lectures complémentaires

Quelques liens pour enrichir le propos.

À propos de .NET Standard :

À propos de .NET Core :

À propos de .NET version:

À propos de .NET version:


Valid XHTML 1.0 Transitional

CSS Valide !