Microsoft assure qu'il va continuer de supporter le .NET Framework avec ASP.NET Core 2.0
Microsoft assure qu'il va continuer de supporter le .NET Framework avec ASP.NET Core 2.0,
et annonce la Preview 1 de ASP.NET Core 2.0
Il existe maintenant deux formes distinctes de la plateforme .NET de Microsoft : la première s’appelle .NET Framework et s'exécute uniquement sur Windows, tandis que la seconde est baptisée .NET Core et est open source et multiplateforme.
Vendredi dernier, ASP.NET Core a changé de support de .NET Standard 1. * et .NET 4. * pour ne soutenir que .NET Core 2.0. Cela signifiait que les applications ASP.NET Core 1.0 / 1.1 exécutant Mono ou .NET Framework ne seraient pas mises à jour sur ASP.NET Core 2.0 lorsqu'elles seront diffusées dans les mois à venir. Ce qui a provoqué la consternation de la communauté étant donné que de nombreux développeurs ont estimé qu’il s’agit là d’une rupture majeure sur la plateforme sans une discussion publique au préalable, encore moins sans annonce formelle.
Le support du cross-framework était considéré comme un élément essentiel pour ASP.NET Core. L'idée de base était que les entreprises pouvaient passer à ASP.NET Core immédiatement tandis qu’elles utilisaient leurs classes de service existantes, leurs dépôts et leurs bibliothèques tierces.
Dans une discussion, Eilon Lipton, responsable du développement sur ASP.NET, a expliqué le raisonnement derrière cette manœuvre : « Oui, pour ASP.NET Core 2, la plupart des bibliothèques ciblent .NET Core 2 afin d'utiliser de nouvelles API qui ne sont pas encore disponibles dans un .NET TFM standard. Le code qui doit cibler plusieurs plateformes, telles que Microsoft.Extensions. *, Entity Framework Core et quelques autres bibliothèques, continuera d'utiliser .NET Standard » .
Après avoir demandé pourquoi Microsoft n'a pas simplement créé .NET Standard 2.1 avec les API nécessaires, le développeur Kévin Chalet a dit dans un nouveau sujet de discussion : « Ma question est simple : allez-vous modifier/rétablir ces changements à un moment donné avant la RTM, afin que les utilisateurs puissent se servir des packages ASP.NET Core 2.0 sur .NET Desktop ou alors ASP.NET Core 2.0 sur .NET Desktop est définitivement mort ? (Ce qui constitue un grave blocage pour beaucoup de gens, y compris moi.) »
Une autre préoccupation est que cette décision a été prise en privé, sans une période d'annonce ou de discussion publique. Le développeur Demis Bellot a écrit : « Étant donné qu'il n'y a pas eu d'annonce officielle préalable, une demande de commentaires, de sondage ou une raison, cette décision “semble” avoir été effectuée sans implication communautaire ou analyse d'impact dans l'écosystème .NET existant et fragmentera probablement l'ensemble de l'écosystème pour beaucoup dans les années à venir. La suppression du support .NET v4.x supprime un chemin de migration en douceur pour de nombreuses entreprises afin de pouvoir migrer leurs bases de code existantes vers le nouveau modèle de développement d'ASP.NET. Cela ne les encouragera pas à passer à .NET Core plus rapidement. Cela les empêche même efficacement de le faire, provoquant une fragmentation massive qui fracture l'écosystème .NET en deux. Je ne vois pas comment cela finira par être différent de Python 2/3 qui a été irrémédiablement lésé par la fragmentation dont il n'a toujours pas réussi à se remettre en une décennie ».
Face à la polémique, lors de la Build, Microsoft s’est ravisée et a décidé de se départir de cette limitation. Miguel de Icaza, ingénieur distingué de Microsoft et également directeur de la Fondation .NET, qui supervise les projets .NET Core et ASP.NET Core, a déclaré que « Certains ingénieurs sont arrivés à penser que nous devrions utiliser cette opportunité pour ne pas supporter cela [le .NET Framework]. C'est de ça qu’il s’agissait dans le fil de discussion Github. Nous allons soutenir .NET Standard et .NET Framework avec ASP.NET Core 2.0 .»
Microsoft va continuer de prendre en charge l'exécution d'ASP.NET Core sur .NET Framework a déclaré Icaza : « Nous avons beaucoup de développeurs sur .NET Framework, et aussi longtemps que c'est le cas, nous devons le soutenir là-bas. »
« .NET Core ne supporte pas toutes les API que possède .NET Framework. Il y a beaucoup de choses qui ne sont pas là sur lesquelles les gens s’appuient aujourd'hui. Ensuite, il existe un très grand écosystème d'ISV aujourd'hui qui s'appuie dessus. Donc, ce sont des développeurs qui doivent fonctionner sur .NET Framework, peut-être qu'ils veulent accéder à .NET Core, mais la réalité est qu'ils ont besoin de certaines de ces fonctionnalités », a-t-il précisé.
« Il pourrait y avoir un jour où .NET Core va posséder tout ce dont les gens ont besoin. Quand ce jour viendra, nous allons devoir reconsidérer la question. Mais jusqu’à l’arrivée de ce jour, et il ne viendra pas avant des années, cela ne peut pas arriver. »
L’entreprise en a profité pour présenter la préversion de .NET Core 2.0 dont voici quelques nouveautés :
- un nouveau métapackage ASP.NET Core qui inclut toutes les fonctionnalités dont vous avez besoin pour créer une application. Vous n'avez plus besoin de choisir les fonctionnalités individuelles ASP.NET Core dans des paquets distincts, car toutes les fonctionnalités sont maintenant incluses dans un package Microsoft.AspNetCore.All dans les modèles par défaut. S'il existe des fonctionnalités dont vous n'avez pas besoin, nos nouvelles fonctionnalités de recadrage des paquets excluront les fichiers binaires de votre sortie d'application publiée par défaut ;
- une nouvelle configuration d'hôte Web par défaut, codant les valeurs par défaut typiques de l'hôte Web avec l'API WebHost.CreateDefaultBuilder (). Cela ajoute Kestrel, la configuration IIS, les sources de configuration par défaut, les fournisseurs de journalisation et la racine du contenu ;
- configuration mise à jour et enregistrement simplifié. Microsoft a amélioré l'objet LoggerFactory pour supporter facilement un dictionnaire <chaîne, LogLevel> qui définit les filtres de journal au lieu d'un objet FilterLoggerSettings, ce qui simplifie le contrôle de la source et du niveau des journaux qui se propagent de votre application à vos fournisseurs de journaux configurés ;
- créez des pages sans contrôleurs dans ASP.NET Core avec les nouvelles fonctionnalités RazorPages. Créez simplement un dossier Pages et déposez un fichier cshtml avec la nouvelle directive @page pour démarrer ;
- le débogage de votre application sur le cloud est facilité avec des applications Azure Application Insights et des diagnostics lors du débogage dans Visual Studio et après déploiement sur Azure App Service ;
- un modèle d'authentification nouvellement remanié qui facilite la configuration de l'authentification pour votre application à l'aide de DI ;
- nouveaux modèles pour configurer l'authentification pour vos applications Web et vos API Web en utilisant Azure AD B2C ;
- nouveau support dans ASP.NET Core Identity pour fournir l'identité en tant que service. Les modèles mis à jour découplent vos applications de leur identité concernant les protocoles standard (OpenID Connect, OAuth 2.0). Migrez facilement des applications à l'aide d'ASP.NET Core Identity pour l'authentification pour utiliser Azure AD B2C ou tout autre fournisseur d'identité compatible avec OpenID Connect ;
- créez des API Web sécurisées à l'aide d'ASP.NET Core Identity. Acquérir des jetons d'accès pour accéder à vos API Web à l'aide de la bibliothèque d'authentification Microsoft (MSAL) ;
- avec NET Core, HTMLEncode, la méthode qui convertit une chaîne en une chaîne codée au format HTML, peut être utilisé sur votre contenu par défaut. Avec la nouvelle version, Microsoft a décidé d’incrémenter le niveau de protection pour éviter les attaques de contrefaçon de demande (XSRF) entre sites : ASP.NET Core émettra désormais des jetons anti-falsification par défaut et va les valider sur les actions POST de formulaire et les pages sans configuration supplémentaire.
Source : fil de discussion, annonce de la Preview 1 de .NET Core 2.0, note de version
Voir aussi :
:fleche: .NET Core : que pensez-vous de l'abandon du project.json et le retour du format .csproj ? Êtes-vous d'accord avec l'orientation de Microsoft ?
