Clever Geek Handbook

Présentation de .NET 5.0 Preview 6

La semaine dernière, nous avons publié .NET 5.0 Preview 6. La version contient un petit ensemble de nouvelles fonctionnalités et des améliorations de performances. .NET 5.0 Preview 4 post couvre ce que nous prévoyons de publier dans .NET 5.0. La plupart des fonctionnalités sont actuellement implémentées, mais certaines ne sont pas encore dans leur état final. Nous nous attendons à ce que la version soit entièrement fonctionnelle avec l'aperçu 8.



Vous pouvez  télécharger .NET 5.0 Preview 6 , pour Windows, macOS et Linux:





ASP.NET Core  et  EF Core  ont également été publiés la semaine dernière. Remarque: EF Core 5.0 ne prend pas en charge .NET Standard 2.0 ou .NET Framework. Lisez  le post de publication d'EF Core pour plus d'informations.



Vous devez utiliser  Visual Studio 2019 16.7  pour travailler avec .NET 5.0. .NET 5.0 est désormais pris en charge dans  Visual Studio pour Mac . Installez la dernière  extension C # pour utiliser .NET 5.0 avec  Visual Studio Code .



Remarques:









Mise à jour Windows ARM64



Nous avons annoncé la prise en charge de Windows ARM64 dans le cadre de l' aperçu 4 . À l'époque, nous n'incluions que les applications console et ASP.NET Core sur Windows ARM64. SDK Preview 6 inclut désormais la prise en charge de Windows Forms. Cela signifie que vous pouvez créer et exécuter des applications Windows Forms sur des appareils Windows ARM64, tout comme vous le pouvez sur x64. Nous travaillons toujours sur l'ajout de la prise en charge de WPF à Windows ARM64.



Vous pouvez voir un exemple d'application Windows Forms exécutée sur un ordinateur portable ARM64, comme illustré ci-dessous.







On s'attend à ce que Visual Studio 16.7 prenne en charge le débogueur distant Visual Studio .NET pour Windows ARM64. Nous nous attendons à voir la prise en charge du débogueur distant Visual Studio Code .NET peu de temps après. Pour éviter toute confusion, cette prise en charge s'applique à l'exécution de Visual Studio ou de Visual Studio Code sur un ordinateur x64 et à la connexion à distance à une application .NET en cours d'exécution sur un ordinateur Windows ARM64. De plus, Visual Studio Code ajoute la prise en charge d'ARM64. Nous ajouterons la prise en charge de l'extension C # et du débogueur .NET s'exécutant dans la version Windows ARM64 de Visual Studio Code, mais les dates ne sont pas encore connues.



Formulaires Windows



Les utilisateurs de Visual Basic sont habitués à rendre leurs applications à instance unique (une instance démarre à la fois). Ce comportement est désormais disponible via WindowsFormsApplicationBase.IsSingleInstance . Voici une excellente explication de ce comportement de Scott Hanselman.



L'équipe a ajouté la prise en charge de la réduction à ListViewGroup. Cette modification facilite la gestion d'un formulaire avec plusieurs ListViewGroups.



Et voici le résultat:







Améliorer la qualité du code RyuJIT



L'équipe RyuJIT continue d'apporter des améliorations vraiment importantes, aperçu par aperçu. Ils n'ont pas déçu dans Preview 6. Voyons voir:







Nous continuons à améliorer la prise en charge des applications à fichier unique dans .NET 5. Notre objectif est de faciliter la publication de votre application en tant que fichier unique pour Windows, macOS et Linux. Nous sommes déjà proches. Lorsque nous en avons parlé pour la dernière fois dans Preview 4 , j'ai mentionné que les applications Windows "à fichier unique" nécessitent quelques fichiers d'exécution supplémentaires. Nous avons ajouté une nouvelle option pour inclure des binaires natifs et tout contenu supplémentaire (comme des images) dans un fichier. Ces fichiers seront extraits au premier lancement. Les applications ciblant Linux et macOS ne doivent pas utiliser cette option pour les binaires d'exécution natifs, à moins qu'elles ne souhaitent l'utiliser pour des médias ou d'autres contenus.



Limitations actuelles:



  • Linux runtime- . ( Windows).
  • Linux , , IL.


-



Au fil des ans, nous avons vu de nombreux modèles d'hébergement pour .NET dans des applications natives. @rseanhall a proposé et implémenté un nouveau modèle pour cela, qui tire parti de toutes les fonctionnalités d'application intégrées fournies par le .NET Application Hosting Layer (en particulier, le chargement des dépendances), tout en permettant d'appeler un point d'entrée personnalisé à partir du code natif. C'est idéal pour de nombreux scénarios et il est entendu que cela devient une méthode populaire parmi les développeurs qui placent des composants .NET à partir d'applications natives.



Deux PR principaux:



  • Activer l'appel get_runtime_delegate à partir du contexte d'application
  • Implémentation de Hdt_get_function_pointer


Support de plate-forme



Nous avons mis à jour notre page .NET 5 - Versions de système d'exploitation prises en charge pour refléter nos derniers plans de prise en charge de la plate-forme .NET 5.0. Dites-nous ce que vous en pensez. Que nous manque-t-il?



Nous savons que le gestionnaire de packages et le support de conteneur que nous proposons ne sont pas répertoriés sur cette page. Cela devrait être corrigé. Nous prévoyons d'ajouter ces informations avant la sortie de .NET 5.0.


More articles:


All Articles