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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
