Introduit par .NET 5

Le 6 mai, il a été annoncé que la prochaine version après .NET Core 3.0 serait .NET 5. Ce serait la prochaine grande version de la famille .NET.

À l'avenir, il n'y aura qu'un seul .NET, et vous pouvez l'utiliser pour le développement sous Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly et d'autres plateformes.

Nous présenterons les nouvelles API .NET, les capacités d'exécution et les fonctionnalités de langage dans le cadre de .NET 5.



Depuis le lancement du projet .NET Core, nous avons ajouté environ 50 000 API .NET Framework à la plateforme. Dans la mesure du possible, .NET Core 3.0 s'est approché du .NET Framework 4.8, grâce à cela Windows Forms, WPF et Entity Framework 6 sont devenus disponibles. .NET 5 a pris le relais, il était basé sur .NET Core et tout le meilleur du projet Mono , résultant en il s'est avéré être une plate-forme unique qui peut être utilisée pour tout votre code .NET moderne.

Nous prévoyons de publier .NET 5 en novembre 2020, et la première version préliminaire sera disponible au premier semestre 2020. La plate-forme sera disponible avec les futures mises à jour de Visual Studio 2019, Visual Studio pour Mac et Visual Studio Code.

.NET 5 = .NET Core vNext

.NET 5 est la prochaine étape dans .NET Core. Le projet vise à améliorer .NET sous plusieurs aspects clés:

• Créez un environnement d'exécution et une infrastructure uniques qui peuvent être utilisés partout, avec le même comportement d'exécution et la même expérience de développement.
• Étendez .NET avec le meilleur de .NET Core, .NET Framework, Xamarin et Mono.
• Créez un produit à partir d'une base de code unique sur laquelle les développeurs (de Microsoft et de la communauté) peuvent travailler ensemble et l'étendre, ce qui améliorera tous les scénarios possibles.

Ce nouveau projet et cette nouvelle orientation changeront complètement la situation avec .NET. Grâce à .NET 5, votre code et vos fichiers de projet seront cohérents, quel que soit le type d'application que vous créez. Depuis chaque application, vous aurez accès au même runtime, à la même API et aux mêmes fonctionnalités linguistiques, y compris de nouvelles améliorations de performances qui sont implémentées dans corefx presque quotidiennement.

Tout ce que vous aimez à propos de .NET Core a été préservé:

• Open source et focus communautaire sur GitHub.
• Implémentation multiplateforme.
• Prise en charge de l'utilisation de fonctionnalités spécifiques à la plate-forme, telles que Windows Forms et WPF pour Windows, ainsi que des liaisons natives pour chaque plate-forme native de Xamarin.
• Haute performance.
• Installation côte à côte.
• Petite taille de fichier de projet (style SDK).
• Interface de ligne de commande puissante (CLI).
• Intégration avec Visual Studio, Visual Studio pour Mac et Visual Studio Code.

Innovations:

• Vous aurez plus de capacités d'exécution (plus d'informations ci-dessous).
• La possibilité d'appeler du code Java à partir de .NET 5 sera disponible sur toutes les plateformes.
• L'invocation de code Objective-C et Swift à partir de .NET 5 sera prise en charge sur plusieurs systèmes d'exploitation.
• CoreFX sera étendu pour prendre en charge la compilation statique .NET (à l'avance - AOT), pour réduire l'encombrement et prendre en charge davantage de systèmes d'exploitation.

.NET Core 3.0 sera disponible en septembre de cette année et .NET 5 sera disponible en novembre 2020. Après cela, nous allons publier des versions majeures de .NET une fois par an, en novembre:



Nous ignorons la quatrième version, car les utilisateurs peuvent rencontrer de la confusion avec le .NET Framework, qui a longtemps été publié dans la version 4.x. En outre, nous voulions préciser que .NET 5 est l'avenir de la plate-forme .NET.

Nous avons également décidé de saisir cette occasion et de simplifier l'ordre des noms. Nous pensons que si un seul .NET se développe, nous n'aurons pas besoin du terme explicatif «Core». Le nom court est plus simple, cela signifie que les fonctionnalités et le comportement de .NET 5 sont unifiés. Si vous le souhaitez, vous pouvez continuer à utiliser le nom. NET Core.

Environnements d'exécution

Mono est l'implémentation multiplateforme originale de .NET. Il a commencé comme une alternative open-source au .NET Framework, et plus tard, avec la popularité croissante des appareils iOS et Android, nous l'avons réorienté vers le segment mobile. Mono est un environnement d'exécution utilisé dans le cadre de Xamarin.

CoreCLR est un environnement d'exécution utilisé dans le cadre de .NET Core. Initialement axé sur la prise en charge des applications cloud, y compris les plus grands services de Microsoft, il est aujourd'hui également utilisé pour les applications de bureau Windows, l'IoT et l'apprentissage automatique.

Les runtimes .NET Core et Mono ont beaucoup en commun (néanmoins, les deux sont des runtimes .NET), mais chacun a ses propres capacités uniques. Par conséquent, il est logique de vous donner la possibilité de choisir l'expérience d'utilisation dont vous avez besoin. Nous travaillons actuellement à faire des remplacements de plug-in CoreCLR et Mono l'un pour l'autre. Le processus sera aussi simple que de basculer l'assemblage pour choisir entre différentes options d'exécution.

Dans les chapitres suivants, je décrirai nos plans clés pour .NET 5. Ils vous aideront à comprendre comment nous allons développer deux environnements d'exécution simultanément et en même temps séparément.

Productivité et productivité élevées

Dès le début, .NET s'est appuyé sur un compilateur JIT pour convertir le code du langage intermédiaire en code machine optimisé. Nous avons créé le meilleur environnement d'exécution de l'industrie avec JIT, avec des performances très élevées, tout en permettant aux développeurs d'écrire du code rapidement et facilement.

Les compilateurs JIT sont bien adaptés aux clouds de longue durée et aux scripts clients. Ils sont capables de générer du code qui prend en compte les caractéristiques de la configuration matérielle, y compris les instructions spécifiques du processeur. JIT peut également générer à nouveau des méthodes lors de l'exécution , cette technique vous permet de compiler à grande vitesse, tout en créant une version finement réglée du code si certaines méthodes sont utilisées fréquemment.

Nos efforts pour accélérer les performances d'ASP.NET Core, comme le montrent les résultats des benchmarks TechEmpower , sont un bon exemple des capacités JIT et constituent notre contribution à CoreCLR. Nous avons essayé de préparer .NET Core pour l'utilisation de conteneurs , cela démontre la capacité de l'environnement d'exécution à s'adapter dynamiquement à des environnements limités.

Les outils de développement sont un autre domaine dans lequel JIT a fait ses preuves, par exemple, la surveillance dotnet ou le mode «modifier et continuer». Les outils nécessitent souvent de compiler et de télécharger du code dans le même processus plusieurs fois sans redémarrer, et vous devez le faire très rapidement.

Les développeurs utilisant .NET Core ou .NET Framework s'appuient principalement sur JIT. Cela devrait donc leur sembler familier.

L'approche standard pour la plupart des charges de travail .NET 5 consiste à utiliser le runtime CoreCLR avec JIT. IOS et le client Blazor (WebAssembly) sont deux exceptions importantes, ils nécessitent une compilation préliminaire (à l'avance) native.

Démarrage rapide, faible encombrement et empreinte mémoire réduite

Dans le cadre du projet Mono, la plupart des efforts visaient le segment mobile et les consoles de jeux. La principale opportunité et résultat de ce projet est le compilateur AOT pour .NET, développé sur la base du compilateur LLVM . Le compilateur Mono AOT vous permet de compiler du code .NET en un seul code exécutable natif qui peut s'exécuter sur n'importe quelle machine, tout comme le code C ++. Les applications précompilées (AOT) peuvent être exécutées efficacement avec des ressources limitées (petites places) et, si nécessaire, sacrifier les performances pour leur lancement.

Le projet Blazor utilise déjà Mono AOT et est l'un des premiers à passer à .NET 5. Nous l'utilisons comme l'un des moyens de prouver nos plans.

Il existe deux types de solutions AOT:

• Nécessite une compilation AOT complète.
• Solutions, dont la plupart du code est compilé AOT, mais vous permettant toujours d'utiliser un JIT ou un interpréteur pour ces modèles de code qui ne sont pas amis avec AOT (par exemple, les génériques).

Mono AOT prend en charge les deux types. Un AOT du premier type est nécessaire pour iOS et certaines consoles de jeux, cela est principalement dû à des exigences de sécurité. Les solutions du deuxième type sont plus préférables car elles présentent tous les avantages de l'AOT sans ses inconvénients.

Le .NET Native est le compilateur AOT que nous utilisons pour les applications Windows UWP. Il appartient au premier type de solutions AOT. Dans cette implémentation particulière, nous avons limité l'API .NET et les options disponibles pour vous. Cela nous a aidés à comprendre que les solutions AOT devraient couvrir la gamme complète des API et des modèles .NET.

La compilation AOT restera nécessaire pour iOS, WebAssembly et certaines consoles de jeux. Nous le rendrons facultatif pour les applications intégrées dans des appliances (de type appliance), qui nécessitent un démarrage rapide et / ou une faible consommation de CPU.

Bases et exigences connexes

Il est essentiel pour nous de continuer à évoluer en tant que plate-forme avec des contrôles pour le lancement, les performances, la consommation de mémoire, la fiabilité et les diagnostics. Dans le même temps, il est conseillé de concentrer nos efforts. Nous travaillerons davantage pour améliorer les performances et la fiabilité de CoreCLR, ainsi que pour améliorer le lancement et la réduction de la taille des fichiers du compilateur Mono AOT. Cela nous semble une bonne combinaison. Les performances et la fiabilité vont de pair, tout comme la vitesse de démarrage avec des tailles de fichiers réduites.

Il est conseillé d'investir différentes ressources pour améliorer certaines caractéristiques, mais pas pour en améliorer d'autres.

Les capacités de diagnostic doivent être les mêmes dans .NET 5, cela s'applique à la fois aux fonctionnalités et aux performances. Il est également important de prendre en charge les mêmes processeurs et OS (à l'exception d'iOS et de WebAssembly).

Nous continuerons d'optimiser .NET 5 pour toutes sortes de charges de travail et de scripts pour lesquels cela a du sens. L'accent sera mis sur les optimisations, en particulier dans les cas où différentes charges imposent des exigences similaires.

Toutes les applications .NET 5 utiliseront le framework CoreFX . Nous nous assurerons que CoreFX fonctionne bien là où il n'est pas utilisé aujourd'hui, principalement les tâches Blazor du client Xamarin.

Toutes les applications .NET 5 peuvent être créées à l'aide de la CLI .NET , de sorte que dans tous les projets, vous disposerez d'une boîte à outils unique basée sur la ligne de commande.

C # évoluera avec .NET 5. Les développeurs écrivant des applications .NET 5 auront accès à la dernière version de C # et à ses propriétés.

Naissance du projet

En tant qu'équipe technique, nous nous sommes réunis en décembre 2018 à Boston pour démarrer ce projet. Les principaux architectes de l'équipe .NET (Mono / Xamarin et .NET Core) et Unity ont parlé de diverses capacités techniques et de l'orientation du développement de l'architecture.

Nous déplaçons maintenant le projet en équipe. Depuis décembre, nous avons fait de grands progrès dans plusieurs projets:

• Nous avons déterminé le niveau minimum qui détermine l'interaction du runtime et de la couche de code managé afin de faire> 99% de CoreFX un code commun.
• MonoVM peut désormais utiliser CoreFX et ses bibliothèques de classes.
• Nous avons exécuté tous les tests CoreFX sur MonoVM en utilisant son implémentation.
• Lancement des applications ASP.NET Core 3.0 sur MonoVM.
• Lancement de MonoDevelop et de Visual Studio pour Mac sur CoreCLR.

La poursuite d'une implémentation unique de .NET soulève des questions importantes. Quel sera le cadre final? Les règles de compatibilité des packages NuGet resteront-elles? Quelle charge le SDK .NET 5 prendra-t-il en charge? Comment écrire du code pour une architecture spécifique? Avons-nous besoin de .NET Standard? Maintenant, nous travaillons sur tout cela et nous serons bientôt en mesure de partager avec vous la documentation du projet afin que vous puissiez la lire et donner votre avis.

Conclusion

Le projet .NET 5 est une nouvelle direction importante et inspirante pour .NET. Vous verrez que .NET deviendra plus facile, mais en même temps il sera utilisé plus largement, il gagnera plus d'opportunités. Toutes les nouvelles fonctionnalités de développement feront partie de .NET 5, y compris les nouvelles versions de C #.

Nous avons un bel avenir devant vous dans lequel vous pourrez utiliser les mêmes API et langages .NET pour une large gamme d'applications, de systèmes d'exploitation et d'architectures de processeur. Vous pouvez facilement modifier la configuration de génération en assemblant les applications comme vous le souhaitez - dans Visual Studio, Visual Studio pour Mac, Visual Studio Code, Azure DevOps ou à partir de la ligne de commande.