Microsoft revient sur sa décision de supprimer une fonctionnalité clé de sa prochaine version .NET 6, après un tollé général de la communauté open source. Il y a quelques jours, l'éditeur a décidé de supprimer un élément clé de Hot Reload dans la prochaine version de .NET 6, une fonctionnalité qui permet aux développeurs de modifier le code source pendant qu'une application est en cours d'exécution et de voir immédiatement les résultats. C'est une fonctionnalité que beaucoup attendaient avec impatience d'utiliser dans Visual Studio Code et sur plusieurs plateformes, jusqu'à ce que Microsoft prenne une décision controversée de dernière minute de la verrouiller à Visual Studio 2022.L'expérience .NET Hot Reload a été annoncée pour la première fois dans Visual Studio 2019 version 16.11 (Preview 1) et via les outils de ligne de commande dotnet watch dans .NET 6 (Preview 4). Avec Hot Reload, vous pouvez désormais modifier le code source géré de vos applications pendant que l'application est en cours d'exécution, sans avoir besoin de mettre manuellement en pause ou d'atteindre un point d'arrêt. Effectuez simplement une modification prise en charge pendant l'exécution de votre application et, dans la nouvelle expérience Visual Studio, utilisez le bouton « Appliquer les modifications de code » pour appliquer vos modifications.
Hot Reload fonctionne avec de nombreux types de projets existants et à venir tels que WPF, Windows Forms, les Preview .NET MAUI, les applications ASP.NET Core code-behind, les applications console, WinUI 3 (débogueur géré requis) et bien d'autres. Cette prise en charge est très large avec l'expérience de base de tout projet alimenté par les environnements d'exécution .NET Framework ou CoreCLR.
Avec Hot Reload, l'objectif de Microsoft est de rendre cette expérience disponible quelle que soit la manière dont vous préférez lancer votre application. Avec la version d'aujourd'hui, vous pouvez désormais utiliser cette expérience via l'expérience de débogage Visual Studio entièrement intégrée ou l'outil de ligne de commande dotnet watch, avec plus d'options à venir dans les versions ultérieures.
Mise à jour vers la prise en charge du rechargement à chaud via dotnet watch
Il y a quelques jours, dans un billet de blog, Dmitry Lyalin, Principal Program Manager, .NET (Hot Reload, XAML Tooling & .NET MAUI) indiquait que l'expérience complète de Hot Reload sera livré avec Visual Studio 2022 :
« Plus tôt cette année, nous avons annoncé .NET Hot Reload, un projet ambitieux visant à proposer Hot Reload au plus grand nombre de développeurs .NET possible. Nous avons commencé ce voyage avec un premier aperçu disponible dans Visual Studio 2019 et promis beaucoup plus à venir dans Visual Studio 2022 où l'expérience complète serait livrée. Je suis ravi d'utiliser ce billet de blog pour vous tenir au courant de nos progrès vers cet objectif et de toutes les merveilleuses fonctionnalités qui arriveront le 8 novembre 2021 lorsque nous publierons en disponibilité générale.
« Pour tous ceux qui découvrent Hot Reload, voici une introduction rapide. L'expérience Hot Reload dans Visual Studio fonctionne à la fois pour les applications managées .NET et C++ natives (fait amusant, nous n'avions pas prévu à l'origine de prendre en charge C++ dans la première version, mais nous y sommes parvenus !).
« Quel que soit le type d'application sur laquelle vous travaillez, notre objectif avec Hot Reload est de vous économiser autant de redémarrages d'applications que possible entre les modifications, ce qui vous rend plus productif en réduisant le temps que vous passez à attendre que les applications soient reconstruites, redémarrées, re- accédez à l'emplacement précédent où vous étiez dans l'application elle-même, etc. Nous y parvenons en vous permettant de modifier les fichiers de code de vos applications et d'appliquer ces modifications de code immédiatement à l'application en cours d'exécution, également appelée "recharge à chaud" ».
Lors de son annonce, une partie à susciter la polémique, notamment :
« Tout au long de l'année dernière, nous avons travaillé pour permettre la meilleure expérience de rechargement à chaud possible dans Visual Studio 2022 et .NET 6. Une partie de notre objectif était d'explorer également la mise à disposition de cette fonctionnalité aux clients via une variété de mécanismes tels que l'apport de la pleine la puissance de Hot Reload à autant de développeurs .NET et C++ que possible lors de l'exécution via le débogueur Visual Studio 2022, la prise en charge de Hot Reload lors de l'exécution d'applications .NET 6 sans le débogueur, et la prise en charge très basique de Hot Reload que nous avons ajoutée aux outils .NET SDK via dotnet watch.
« Au fur et à mesure que nous réfléchissons à ce qui a été accompli et à ce qui nous attend encore, le retard continue de croître. Cela inclut de nombreux scénarios de grande valeur qui profiteront au plus grand nombre de développeurs, y compris des domaines d'intérêt tels que .NET MAUI, Blazor, l'ajout de la prise en charge de plus de types de modifications, une expérience plus optimisée lors de l'utilisation d'applications XAML, et bien plus encore.
« Compte tenu de ces considérations, nous avons décidé qu'à partir de la prochaine version en disponibilité générale .NET 6, nous activerons la fonctionnalité de rechargement à chaud uniquement via Visual Studio 2022 afin que nous puissions nous concentrer sur la fourniture des meilleures expériences au plus grand nombre d'utilisateurs. Nous continuerons également à ajouter Hot Reload à Visual Studio pour Mac dans une future version ».
Les développeurs l'ont interprété de différentes manières. Aussi, dans un soucis de clarification, Lyalin a indiqué : « Pour clarifier les choses, nous ne publions pas Hot Reload en tant que fonctionnalité de l'outil dotnet watch. Nous investissons toute notre énergie dans Visual Studio 2022 et travaillons pour prendre en charge le rechargement à chaud dans Visual Studio pour Mac dans une future version ».
Cette précision a entraîné de vives critiques au sein de la communauté des développeurs, poussant l'équipe à rectifier sa trajectoire. Dans un billet de blog, Scott Hunter, Director Program Management, .NET s'est excusé au nom de l'équipe, demandant de l'indulgence, et a annoncé qu'elle revenait sur sa décision :
« La semaine dernière, notre article de blog et la suppression de la capacité de rechargement à chaud du référentiel .NET SDK ont suscité de nombreux retours de la communauté.
« Tout d'abord, nous voulons nous excuser. Nous avons fait une erreur en exécutant notre décision et avons pris plus de temps que prévu pour répondre à la communauté. Nous avons approuvé le Pull Request visant à réactiver ce chemin de code et il fera parti de la version en disponibilité générale .NET 6.
« En tant qu'équipe, nous nous engageons à ce que .NET soit une plateforme ouverte et la développons de manière transparente. Le fait même que nous ayons décidé d'adopter une posture ouverte par défaut dès le départ pour développer la fonctionnalité Hot Reload en est la preuve. Cela dit, comme toute équipe de développement, nous devons de temps en temps examiner la qualité, le temps, les ressources pour faire des compromis tout en continuant à progresser. La grande majorité des développeurs .NET utilisent Visual Studio et nous voulons nous assurer que VS offre la meilleure expérience pour .NET 6.
« Le temps étant de plus en plus court pour la publication des versions .NET 6 et Visual Studio 2022, nous avons choisi de nous concentrer d'abord sur l'introduction de Hot Reload vers VS 2022. Nous avons fait une erreur en exécutant ce plan dans la façon dont il a été exécuté. Dans notre effort de portée, nous avons fini par supprimer le code source par inadvertance au lieu de simplement ne pas appeler ce chemin de code. Nous avons sous-estimé le nombre de développeurs qui dépendent de cette capacité dans leurs environnements dans tous les scénarios, et comment la CLI était utilisée avec Visual Studio pour stimuler la productivité de la boucle interne par beaucoup.
« Nous sommes toujours à l'écoute des commentaires de nos clients pour répondre à leurs besoins. Merci d'avoir fait entendre vos commentaires. Nous sommes désolés d'avoir bouleversé tant de membres de la communauté à cause de ce changement sur de nombreux paramètres, notamment le timing et l'exécution.
« Notre volonté est de créer un écosystème ouvert et dynamique pour .NET. Comme c'est le cas pour de nombreuses entreprises, nous apprenons à équilibrer les besoins de la communauté OSS et à être un sponsor d'entreprise pour .NET. Parfois, nous ne comprenons pas bien. Lorsque nous ne le faisons pas, le mieux que nous puissions faire est d'apprendre de nos erreurs et de mieux avancer ».
Frameworks et scénarios d'application pris en charge
« Depuis que nous avons annoncé cette fonctionnalité en mai 2021, une question très courante était "Est-ce que Hot Reload fonctionnera avec mon combo d'applications .NET (framework/version) ?", nous avons fait d'énormes progrès pour répondre OUI dans la plupart des situations, ici sont les points forts :
- Lorsque vous utilisez Visual Studio 2022 et démarrez votre application avec le débogueur, l'expérience de base de rechargement à chaud fonctionne avec la plupart des types d'applications .NET et de versions de framework, cela inclut .NET Framework, .NET Core et .NET 5+ (pour C# et VB. NET le cas échéant). Les types d'applications prises en charge incluent le Web (modifications de code), le bureau, le mobile, le cloud et d'autres types de projets. La règle clé ici est que si vous utilisez le débogueur, supposez que Hot Reload est disponible et essayez-le !
- Lorsque vous utilisez Visual Studio 2022 mais que vous n'utilisez pas le débogueur (par exemple, en utilisant CTRL-F5 pour démarrer l'application), le rechargement à chaud est désormais disponible même sans le débogueur lors du ciblage de la plupart des types d'applications .NET 6. Cela signifie que les applications ne ciblant pas .NET 6 (.NET 5 ou inférieur) ne prendront pas en charge le scénario «*pas de débogueur*» et doivent utiliser le débogueur pour obtenir la prise en charge du rechargement à chaud.
- Lorsque vous utilisez Visual Studio 2022 avec une application .NET 6, la plupart des types de scénarios sont pris en charge. Cela ne se limite pas simplement au scénario « sans débogueur » mentionné ci-dessus, il inclut également la prise en charge des types de projets tels que .NET MAUI et Blazor et plus généralement l'édition des fichiers Razor et CSS Hot Reload dans les applications ASP.NET. Il inclut également d'autres optimisations mineures dans des frameworks d'applications supplémentaires. L'utilisation à la fois de Visual Studio 2022 et la mise à jour de vos applications vers .NET 6 vous offriront définitivement l'expérience de rechargement à chaud la plus puissante et nous espérons que vous l'essayerez.
Visual Studio 2022 lors de l'utilisation du débogueur
Lors de l'utilisation de Visual Studio 2022 et du démarrage de l'application avec le débogueur, Hot Reload fonctionne avec la plupart des frameworks d'applications, y compris les types d'applications typiques tels que Console, Windows Forms (WinForms), WPF, UWP, WinUI 3 et la plupart des types de sites Web ASP.NET projets (pour les modifications de code-behind), y compris ASP.NET MVC, Web API et même des projets Web Forms plus anciens. WinUI 3 utilise par défaut le débogage en mode mixte qui ne prend pas en charge le rechargement à chaud. Vous pouvez modifier cela dans les paramètres du projet en activant le débogueur géré qui permettra au rechargement à chaud de fonctionner correctement.
Cette liste n'est également qu'un exemple. La vraie réponse est partout où vous avez .NET et que vous utilisez le débogueur managé Visual Studio, vous devriez obtenir une prise en charge de base du rechargement à chaud.
Cela signifie que même des projets tels que Azure Functions fonctionneront parfaitement dans ce scénario. Microsoft vous encourage à essayer votre combinaison et à l'informer si vous rencontrez des problèmes.
Lors de l'utilisation de Visual Studio 2022 mais sans utiliser le débogueur
Le rechargement à chaud est désormais disponible sans le débogueur lors du ciblage de la plupart des types d'applications .NET 6, y compris les types de projets tels que Console, WPF, Windows Forms (WinForms), ASP.NET Core MVC, Web API et Blazor. Microsoft sait que certains développeurs ont une bonne raison ou une préférence pour démarrer leurs applications sans le débogueur et espère que cette fonctionnalité supplémentaire leur donnera une valeur pour peu ou pas d'impact sur le temps de démarrage.
Cette fonctionnalité est exclusive à .NET 6+ et les applications ne ciblant pas .NET 6 (.NET 5 ou inférieur) ne prendront pas en charge le scénario « pas de débogueur » et doivent utiliser le débogueur pour accéder à la fonctionnalité de rechargement à chaud.
Sachez également que tous les types de projets ne seront pas pris en charge pour le scénario « pas de débogueur » dans la première version. Spécifiquement:
- Les applications .NET MAUI et WinUI 3 continueront de fonctionner uniquement avec le rechargement à chaud lors de l'utilisation du débogueur. Microsoft espère améliorer cette situation dans une future version, mais n'est pas encore en mesure de communiquer un calendrier précis.
- Les applications UWP ne sont pas non plus prises en charge pour le rechargement à chaud sans le débogueur, c'est par conception et il n'y a actuellement aucun plan pour améliorer cela.
Lors de l'utilisation de Visual Studio 2022 avec une application .NET 6, la plupart des types de scénarios sont pris en charge
Les développeurs capables d'utiliser à la fois Visual Studio 2022 et de travailler sur des applications qui ciblent .NET 6 bénéficieront de l'expérience de rechargement à chaud la plus aboutie et la plus performante.
Voici les points saillants de ce qui est pris en charge :
- Applications .NET MAUI (iOS, Android et WinUI), y compris les applications .NET MAUI standard et .NET MAUI Blazor Hybrid
- Applications Blazor (Serveur et WebAssembly). Dans la version Visual Studio 2022 en disponibilité générale, la prise en charge du rechargement à chaud pour Blazor WebAssembly lors de l'utilisation du débogueur Visual Studio n'est pas encore activée. Vous pouvez toujours obtenir un rechargement à chaud si vous démarrez votre application via Visual Studio sans le débogueur, et Microsoft travaille pour résoudre ce problème dans la prochaine mise à jour de Visual Studio.
- Édition de fichiers Razor dans les sites Web Blazor et ASP.NET Core standard
- Rechargement à chaud CSS
- Possibilité d'obtenir la prise en charge du rechargement à chaud lors de l'exécution d'applications sans le débogueur.
- Les développeurs ciblant .NET 6 continueront à bénéficier d'améliorations supplémentaires dans les futures mises à jour de Visual Studio 2022, la bande de fonctionnalités .NET et les versions majeures. Ce n'est que le début*!
Scénarios non pris en charge
Même dans la version finale, il y aura toujours des scénarios non pris en charge que vous devez connaître :
- Les applications Xamarin.Forms ne prendront pas en charge le rechargement à chaud .NET dans les scénarios iOS et Android. Vous obtiendrez un rechargement à chaud lorsque vous ciblerez une application UWP. C'est par conception, et Microsoft ne prévoie pas d'apporter d'autres améliorations.
- Les applications créées à l'aide de F# ou celles ciblant .NET Native ne prendront pas en charge le rechargement à chaud. (Remarque : XAML Hot Reload continuera d'être disponible et pris en charge pour les clients Xamarin.Forms sur le dernier SDK) Il existe d'autres limitations mineures connues et Microsoft va faire des communications sur certains problèmes et documents GitHub avec plus de détails dans les semaines à venir.
Source : Microsoft
Envoyé par Issam
