Nouvelles
.NET 7 Preview 3 concerne l’AOT natif
Le nouveau .NET 7 Preview 3 présente la compilation native à l’avance (AOT), une fonctionnalité très demandée et attendue depuis longtemps pour .NET, Microsoft prenant même le temps d’expliquer de quoi il s’agit.
L’équipe de développement .NET 7 a fait passer l’AOT natif du statut expérimental au développement grand public dans l’aperçu 2 du mois dernier, notant qu’il lui restait encore à ajouter une prise en charge de première classe dans le SDK dotnet pour la publication de projets avec l’AOT natif.
Dans l’annonce Preview 3, Jon Douglas, responsable principal du programme, NuGet, a fourni une mise à jour sur la façon dont l’AOT natif promet d’aider à créer des applications plus rapides et plus légères, tout en expliquant ce que c’est pour ceux qui ne sont pas familiers, notant que ses principaux avantages affectent :
- Temps de démarrage
- Utilisation de la mémoire
- Accès à des plateformes restreintes (où aucune compilation juste à temps (JIT) n’est autorisée)
- Taille plus petite sur le disque
Voici une partie de son “Qu’est-ce que l’AOT natif ?” la description:
La compilation anticipée (AOT) fait référence à un ensemble de technologies qui génèrent du code au moment de la construction de l’application, plutôt qu’au moment de l’exécution. AOT n’est pas nouveau pour .NET. Aujourd’hui, nous livrons ReadyToRun pour les scénarios client et serveur, et Mono AOT pour mobile et WASM. Native AOT apporte une pré-compilation native complète aux scénarios client et serveur de bureau .NET. L’AOT natif ne remplace pas ces technologies existantes, mais offre plutôt un nouvel ensemble de fonctionnalités qui débloque de nouveaux facteurs de forme.
Les assemblages .NET compilés par AOT existants contiennent des structures de données spécifiques à la plate-forme et du code natif pour précharger le travail généralement effectué au moment de l’exécution. La précompilation de ces artefacts permet de gagner du temps au démarrage (par exemple, ReadyToRun) et permet d’accéder à des plateformes sans JIT (par exemple, iOS). Si les artefacts précompilés ne sont pas présents, .NET revient au JIT ou à l’interprétation (selon la plate-forme).
L’AOT natif est similaire aux technologies AOT existantes de .NET, mais il ne produit que des artefacts natifs. En fait, le runtime AOT natif ne sait pas comment lire les formats de fichiers d’assemblage .NET – tout est natif de la plate-forme. L’analyse du format de fichier exécutable est entièrement gérée par le système d’exploitation sous-jacent.
L’AOT natif était une considération importante pour de nombreux développeurs il y a quelques années lorsqu’une enquête a indiqué que son absence freinait l’adoption de .NET.
L’AOT natif n’est pas pour tous les projets, cependant, et Microsoft dit que dans .NET 7, il aidera principalement les développeurs qui créent des applications de console ou des bibliothèques natives.
“Pour l’avenir, la compatibilité Native AOT sera améliorée au cours des prochaines versions de .NET, mais il y aura toujours des raisons de préférer JIT pour de nombreux scénarios. Nous ajouterons également un support de première classe dans le SDK dotnet pour la publication de projets avec Native AOT “, a déclaré Douglas, qui a également noté quelques améliorations du schéma dans Preview 3.
D’autres améliorations dans Preview 3 affectent l’observabilité, les temps de démarrage, le codegen, les régions GC et plus encore.
Cependant, c’est l’AOT natif qui a encore dominé la discussion des lecteurs dans divers commentaires sur le message d’annonce, ladite discussion traitant du manque de son support dans les projets WPF et WinForms.
Par exemple, un commentaire disait :
Mes réflexions sur NativeAOT sont :
- Il est incroyablement décevant qu’il ne soit pas pris en charge par WPF / Winforms (je ne sais pas pour MAUI). Cela en fait uniquement une fonctionnalité de console / bibliothèque. Cela signifie que je ne peux l’utiliser dans aucune de mes applications plus importantes, mais pour celles-ci, cela n’a d’importance que. Je n’ai pas besoin d’amélioration de démarrage pour les petits projets de console.
- La taille de sortie d’un simple hello world est ridicule (5 Mo). Le même écrit en C++ ou Pascal finit avec ~100kb. Malheureusement, il a été rejeté pour améliorer cela.
Donc merci pour cela, mais la façon dont il est (non) implémenté n’est pas vraiment utile, du moins pour moi.
En réponse, un développeur Microsoft a souligné les efforts de la communauté pour atteindre cet objectif :
Nous prévoyons d’envisager d’élargir les scénarios où NativeAOT convient bien au fil du temps. C’est une fonction de temps et de ressources. Il est déjà possible d’utiliser WinForms avec NativeAOT, mais cela nécessite un peu de peaufinage et ne sera pas annoncé comme un scénario pris en charge à cause de cela. Je suggère le membre suivant de la communauté .NET qui a contribué à faire beaucoup de progrès à ce sujet au fil des ans : Andrey Kurdyumov — https://twitter.com/Kurdiumov. Voici l’un de ses articles où il a apporté des modifications à diverses applications WinForms open source pour les rendre compatibles avec NativeAOT sous la forme actuelle : https://codevision.medium.com/again-winforms-and-nativeaot-fd068425cc13. Cela peut vous donner une idée d’où nous en sommes maintenant.
D’autres indices sur la situation actuelle de l’équipe de développement peuvent être trouvés dans le problème NativeAOT in .NET 7 #61231 GitHub, qui montre le travail initial en cours de vérification et ce qui reste dans la première phase (photo ci-dessus).
.