Que s'est -il passé de .NET Framework à .NET Core ? Avec ASP.NET nous sommes au dessus de ces Frameworks avec les Applications Webs qui les utilisent. Nous allons comparer tranquillement les deux solutions d'une part une application ASP.NET Framework et d'autre part une application créée avec ASP.NET Core.
Dans un premier article sur
ASP.NET Framework vs ASP.NET Core je détaillais la création des applications avec Visual Studio 2017 ici, je vais les comparer.
 |
| Comparaison des Solutions .NET Framework vs .NET Core |
Première
chose qui saute aux yeux :
où sont les Packages NuGets dans le cas de .NET Core ?
ASP.NET Core - Dépendances
J'ouvre la solution ASP.NET Core :
 |
| Solution .NET Core où sont les NuGets ? |
Des petits triangles jaunes, hum que c'est pénible ! Mais au bout d'un certain temps Visual finit par trouver les bonnes références sur ma machine et les triangles jaunes disparaissent ...
Alors regardons dans les dépendances de la solution .NET Core :
 |
| Dépendances - Microsoft.AspNetCore.App |
NuGet
Donc la dépendance
Microsoft.AspNetCore.App se trouve dans le répertoire :
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.app\2.1.1
La dépendance
Microsoft.VisualStudio.Web.CodeGeneration.Design se trouve dans le répertoire :
D:\Users\UserName\.nuget\packages\microsoft.visualstudio.web.codegeneration.design\2.1.1
SDK
Microsoft.AspNetCore.App
plétore de DLLs
Microsoft.NETCore.App
plétore de DLLs
Analyseurs
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.analyzers\2.1.1\analyzers\dotnet\cs\Microsoft.AspNetCore.Mvc.Analyzers.dll
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.codeanalysis.analyzers\1.1.0\analyzers\dotnet\cs\Microsoft.CodeAnalysis.Analyzers.dll
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.codeanalysis.analyzers\1.1.0\analyzers\dotnet\cs\Microsoft.CodeAnalysis.CSharp.Analyzers.dll
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.entityframeworkcore.analyzers\2.1.1\analyzers\dotnet\cs\Microsoft.EntityFrameworkCore.Analyzers.dll
A vue de nez comme ça on peut déjà dire que c'est un sacré bordel, les dépendances sont éparpillées un petit peu partout sur ma machine.
ASP.NET Framework - Références
En ce qui concerne ASP.NET Framework, toutes les Références sont dans le répertoire Packages :
 |
| Ensemble des Références de l'application ASP.NET Framework |
A vue de nez, c'est quand même un peu mieux rangé et surtout c'est bien
plus facile pour le déploiement ... D'ailleurs ma prochaine question sera ; comment fait-on pour le déploiement d'une application ASP.NET Core ?
Comparaison des applications
L'idée, c'est de se rendre compte du gap qu'il y a entre les technos .NET Framework standard et .NET Core afin de mieux comprendre la migration éventuelle à faire pour passer de l'un vers l'autre. Où vont être les difficultés ?
Les comparaisons sont effectuées avec le logiciel
BeyongCompare que personnellement je trouve fabuleux pour ce genre d'exercice !
 |
| Ajouter une légende |
A gauche nous avons l'application ASP.NET Framework à droite ASP.NET Core
App_Data : où est donc la BD dans Core ? Avec Entity Core certainement ...
Comparaison des View _VeiwStart
Dans le répertoire Views :
 |
| _ViewsStart.cshtml |
C'est bluffant la différence :
@{
Layout = "~/Views/Shared/_Layout.cshtml";
}
@{
Layout = "_Layout";
}
Franchement ! Pourquoi cette différence ?
Voilà une comparaison qui vaut le coup. C'est bien le problème récurrent de toutes ces versions de technos nous avons l'impression que c'est développé par des amateurs, aujourd'hui personne ne se permettrai de Chekiner (push, commit) un fichier avec juste une différence de ce genre. Mais les ingé de Redmond eux pas de problème, ils se permettent !
Nous allons voir que les règles de routage s'en trouvent changées.
Global.asax
Le fichier Global.asax n'existe pas dans .NET Core car .NET Core introduit une nouveau mécanisme de démarrage d'une application avec
OWIN (Open Web Interface for .NET).
Et là il nous faut découvrir plus avant OWIN. Ce sont eux qui développent
ASP.NET SignalR.
Dans ASP.NET Standard le démarrage de l'application est couplée avec l'implémentation du Framework sur le serveur.
Vous pouvez utiliser OWIN avec .NET Standard et configurer le Pipeline :
Migration d’ASP.NET vers ASP.NET Core - Remplacement du fichier Global.asax
ASP.NET Core Pipeline de démarrage de l'application :
 |
| ASP.NET Core Pipeline de démarrage de l'application : |
On retrouve au démarrage de l'application un Main :
 |
| Progam - Main |
Web.config
Pas de fichier web.config pour ASP.NET Core, il stocke les configurations dans le fichier : appsettings.json. On reconnait la ConnectionString nommée DefaultConnection :
 |
| ASP.NET Core stockage des configuration dan le fichier : appsettings.json |
Le chargement de ce fichier se fait dans une instance de
IConfiguration dans le Startup.cs à la racine du projet :
 |
| Chargement du fichier de configuration |
Ce qu'on voit c'est qu'ASP.NET Core utilise des DesignPatterns comme l'injection des dépendances,
les principes d'Unity sont intégrés au Framework.
Runtime exécution de l'application ASP.NET Core
Lançons l'exécution de l'application et tentons de nous enregistrer :
 |
| ASP.NET Core page d'Accueil |
Clique sur Register :
 |
| ASP.NET Core Registration |
Clique sur Register :
 |
| Registration et boom |
Et boom ! Mais ce n'est pas grave, j'ai quand même cliqué sur le bouton "
Apply Migation" et puis j'ai réactualisé la page et là pouf pouf, je suis connecté !
 |
| ASP.NET Core - Création d'un User Account |
En passant au dessus de mon User Account, je peux le manager :
 |
| ASP.NET Core manage Account |
Manage User Account :
 |
| ASP.NET Core - Manage User Account |
C'est un peu plus complet que pour ASP.NET Standard le processus de gestion d'un utilisateur suit la mode et l'on a un onglet "Personal data" qui permet de gérer les données personnelles.
Data Base Management
Où est la base de données ?
C'est toujours une bonne question lorsque l'on explore pour la première fois une nouvelle techno Microsoft. Les ingés de Redmonds prennent un malin plaisir à changer la manière de gérer les bases de données des applications web.
Je cherche la ConnectionString, je cherche donc dans le fichier appsettings.json :
 |
| ConnectionString dans le fichier appsettings.json |
Et voilà, ça recommence ... vous maitrisiez parfaitement IIS Express et le moteur de bases de données SQLServer ou SQL Express ou SQL Compact Edition et bien il faut recommencer !
ASP.NET Core utilise
Microsoft Local DB et où est la base de donnée, elle est où ? Mais où qu'elle est la bas de données ?
Et ben au fin fond du Système donc, si pour vos application Web vous utilisiez le répertoire
App_Data pour y mettre les BD de vos applications Web et bien avec ASP.NET Core vous repartez au début. Chouette ! Tout le monde applaudit.
EntityFrameworkCore c'est la nouvelles dénomination de l'Entity Framework pour ASP.NET Core.
Au bout d'un certain temps le processus de recherche de la BD qui s'appelle "
aspnet-WebApplication1-7687E68F-1A61-4DF1-B629-EA7B3646ED01" fini par la trouver à la racine du répertoire de mon utilisateur ... glurps du coup je regarde, j'ai également des trucs du genre à cet endroit ...
AzureStorageEmulatorDb56.mdf
Depuis que j'utilise ASP.NET Core il va falloir faire un peu de ménage dans tout ça.
Controller ASP.NET Core
Différences au niveau des contrôleurs :
 |
| ASP.NET Core - Controller |
Le HomeController implante maintenant l'interface
IActionResult
 |
| ASP.NET Controller |
Razor et le cshtml
Là encore des différence notables, on trouve l'inclusion de JavaScript et de CSS en fonction de la configuration :
 |
| ASP.NET Core - cshtml |
Avec des différences suivantes :
<
title>@ViewBag.Title - Mon application ASP.NET</title>
Remplacé par :
<title>@ViewData[
"Title"] - WebApplication1</title>
Et une autre :
@Html.ActionLink("Nom d'application", "Index", "Home", new { area = "" }, new { @class = "navbar-brand" })
Remplacé par :
<a asp-area=""
asp-controller="Home"
asp-action="Index" class="navbar-brand">WebApplication1</a>
 |
| ASP.NET Core - TagHelper pour Razor |
asp-area est un TagHelper un astuce un peu ...
Le répertoire wwwroot
A quoi bien peut-il servir ?
 |
| ASP.NET Core wwwroot |
Nous verrons cela dans un prochain post ...
Migration d’ASP.NET vers ASP.NET Core
Il me faut bien en arriver finalement à la migration ... donc on retient que si nous utilisons des ressources du .NET Framework qui ne sont pas encore écrites dans .NET Core il faut rester avec .NET Framework sinon on peut migrer.
Migrer d’ASP.NET vers ASP.NET Core
Et voilà, maintenant on peut être à peu prêt certain que .NET Framework sera sans doute abandonné à terme ... au profit de ASP.NET Core.
Don't forget it's only software !
