Dans la continuité de l’ article où nous avons discuté de ce qui est le plus approprié pour les conteneurs Docker : .NET Core ou .NET Framework, examinons de plus près les avantages et les inconvénients d’ASP.NET Core.
En tant qu’ entreprise de développement .NET, nous comprenons que .NET Core et ASP.NET Core sont deux technologies indépendantes, similaires et différentes à la fois, tout comme le .NET Framework et ASP.NET. Dans cet article, nous passerons en revue l’historique, les avantages et les inconvénients d’ASP.NET Core et de .NET Core. De plus, nous examinerons certains changements apportés à l’architecture du projet ASP.NET Core, basés sur l’avis des programmeurs ASP.NET.
Que sont .NET Core et ASP.NET Core, et pourquoi ont-ils été créés ?
Des millions de développeurs ont utilisé et utilisent encore ASP.NET 4.x pour le développement web. C’est une technologie formidable qui a une longue histoire de développement, remontant à sa première sortie début 2002. Beaucoup de choses ont changé depuis pour s’adapter à ces évolutions, y compris le framework lui-même. Il y a au moins quelques raisons majeures qui ont conduit à la création d’un nouveau framework à partir de zéro.
Premièrement, pendant de nombreuses années, Microsoft a fourni des logiciels propriétaires, ce qui a découragé de nombreux développeurs qui soutenaient l’open source. Certains des partenaires Microsoft avaient accès au code source, ce qui n’est évidemment pas la même chose que l’open source. Même si vous ne contribuez pas au code source, y avoir accès peut vous aider à comprendre clairement comment fonctionne le framework et quelle est la fonction d’un système particulier. Cela permet également à la communauté de contribuer au processus de développement : améliorations faciles, discussions rapides, résolution de problèmes. C’est ce que les développeurs n’avaient pas auparavant.
Deuxièmement, le framework .NET prend en charge une plateforme spécifique, il n’est donc pas étonnant que les gens l’associent uniquement à Windows. Ce fait était également un inconvénient majeur pour les personnes qui ne peuvent ou ne veulent pas utiliser le système d’exploitation Windows.
Troisièmement, le .NET Framework a progressivement abandonné l’idée de séparer complètement les installations côte à côte, en n’ayant aucune séparation entre les versions mineures et parfois même majeures. Par exemple, les applications utilisant deux versions différentes du .NET Framework coexisteront avec le risque de partager des dépendances, ce qui peut causer des problèmes. Quant à ASP.NET, qui est basé sur System.Web.dll, son architecture reflète étroitement la manière dont IIS traite les requêtes. C’est pourquoi la ségrégation d’ASP.NET d’IIS est presque impossible aujourd’hui. System.Web contient également de nombreuses fonctionnalités dans un seul module, ce qui rend difficile la modularisation de la fonctionnalité et la modification du comportement au niveau du système d’ASP.NET. Vous ne pouvez pas obtenir uniquement une partie de la fonctionnalité dont vous avez besoin ; vous obtenez tout en un, ou rien.
Toutes ces raisons ont poussé à repenser et à changer l’approche de la manière dont la plateforme .NET devait évoluer. C’est ainsi que .NET Core et ASP.NET Core ont été créés. Ils ont tous deux le mot “Core” dans leur nom pour une raison. Cela a été fait pour éviter l’impression qu’il ne s’agissait que d’une nouvelle mise à jour du framework .NET et pour souligner leur idée de changer le concept lui-même. Malgré tous ces faits, cela ne rend pas vos compétences existantes obsolètes. C’est juste un investissement majeur dans l’avenir de la plateforme entière.
Avantages d’ASP.Net Core
Comme mentionné ci-dessus, ASP.NET Core est un framework nouveau, open source, modulaire, multiplateforme, extensible, asynchrone et beaucoup plus léger. C’est maintenant le seul framework qui s’exécute sur le runtime .NET Core 5 (Core-CLR) ou sur le runtime .NET Framework (CLR) et qui présente de nombreux avantages, dont la plupart seront examinés ci-dessous.
NuGet
Contrairement au framework .NET monolithique, la plateforme .NET Core est un ensemble de packages NuGet qui fournissent une petite pièce de fonctionnalité discrète. Cela vous permet d’optimiser les applications, de les rendre plus légères et beaucoup plus performantes. Vous pouvez également distribuer une version privée du .NET Core Framework pour votre application spécifique, sans aucun risque que d’autres versions d’applications ne modifient le comportement de votre application.
C’est une valeur clé d’ASP.NET Core, qui n’est plus basé sur System.Web.dll. Il peut s’exécuter sur plusieurs versions de .NET Core sur la même machine. NuGet permet à l’équipe ASP.NET de fournir de nouvelles fonctionnalités et des correctifs plus facilement et plus rapidement. Ainsi, si Microsoft fournit une mise à niveau pour l’un des packages, vous pouvez simplement le mettre à jour, et c’est tout. Avec ASP.NET Core 2.1, Microsoft a introduit un métapaquet appelé Microsoft.AspNetCore.App, qui contient toutes les bibliothèques fournies par les équipes .NET et ASP.NET, et offre un support direct sans vous enfermer dans des versions spécifiques de dépendances tierces. Tout cela améliore les performances et l’évolutivité des applications.
Open Source
.NET Core et ASP.NET Core sont désormais open source. C’est une grande avancée pour toute la communauté .NET, car cela rend le processus de développement transparent et propre, permettant aux développeurs de participer à la revue de code, à la correction de bugs, à la fourniture de nouvelles fonctionnalités, et offre la possibilité d’étudier en détail les bibliothèques utilisées. L’un implique l’autre, et l’open source permet à Microsoft d’étendre l’unification .NET au développement multiplateforme, y compris le développement d’applications de bureau. .NET Core dispose d’une base de code unique qui peut être utilisée pour construire et prendre en charge toutes les plateformes, y compris Windows, Linux et Mac OS. Évidemment, certains composants individuels, tels que le système de fichiers spécifique à l’OS, nécessitent une implémentation distincte. Le modèle de distribution via NuGet permet d’abstraire ces différences.
API unique
L’élément important pour les développeurs est qu’il s’agit d’une API unique qui s’exécute sur différentes plateformes. Ils n’ont pas à s’en soucier car le package contient déjà différentes implémentations pour chacun des environnements. Les fonctionnalités de configuration sont également devenues plus conviviales pour les plateformes croisées, remplaçant les anciennes par des fichiers JSON ou INI et des variables d’environnement. Le multiplateforme signifie également que vous disposez d’une gamme plus étendue de systèmes d’exploitation que vous pouvez utiliser pour le déploiement, car Azure prendra en charge ASP.NET Core sur les machines virtuelles Linux et Windows. C’est à vous de choisir.
Visual Studio Code
Un grand avantage pour ceux qui ne veulent pas installer Visual Studio : vous pouvez désormais choisir Visual Studio Code, Atom, Emacs, ou même travailler avec l’invite de commandes. Par exemple, Visual Studio Code est l’éditeur de code multiplateforme pour Linux, MacOS et Windows. Il vous permet de créer, déboguer et exécuter des applications web ASP.NET Core, des applications web Node ou des applications console .NET Core, avec la capacité d’utiliser IntelliSense, la complétion de code et l’intégration Git. Si vous êtes un partisan des outils en ligne de commande, vous serez heureux d’apprendre que tout ce qui est impliqué dans la création, la compilation ou l’exécution d’applications .NET Core peut être fait en ligne de commande.
Avantages en termes de performances
En raison de l’empreinte plus petite d’ASP.NET Core, il existe également des avantages en termes de performances spécifiques à .NET Core, mais la plupart d’entre eux s’appliquent à la fois au .NET Framework et à .NET Core.
Concernant le lien entre ASP.NET et IIS, ASP.NET Core ne nécessite désormais plus IIS pour fonctionner. Il est livré avec les implémentations de serveur suivantes :
- Kestrel est le serveur HTTP par défaut et multiplateforme pour ASP.NET Core ;
- IIS HTTP Server (IISHttpServer) est une implémentation de serveur IIS en processus utilisée avec le module ASP.NET Core ;
- HTTP.sys est un serveur HTTP uniquement sous Windows, basé sur le pilote noyau HTTP.sys et l’API du serveur HTTP.
Le plus populaire parmi eux est Kestrel et c’est aussi celui par défaut dans les modèles ASP.NET Core. Lorsque vous créez un nouveau projet dans Visual Studio, il est automatiquement configuré pour s’exécuter sur Kestrel. Ce dernier est en fait basé sur libuv, qui est utilisé pour le travail d’E/S et prend en charge l’exécution de plusieurs boucles d’événements. Cependant, malgré sa rapidité, sa nature multiplateforme et son optimisation pour les performances de débit, il ne fournit pas toutes les fonctionnalités qu’un service Web complet (comme IIS) offre, notamment le partage de ports, la configuration SSL facile et les réécritures d’URL. Certaines de ces fonctionnalités pourraient apparaître à l’avenir, mais aujourd’hui Kestrel est normalement utilisé avec un serveur proxy inverse, tel que IIS, Nginx ou Apache. C’est à la fois un avantage et un inconvénient. Kestrel est vraiment rapide, en fait, six fois plus rapide que Node.js pour les opérations statiques et en texte brut, et il offre de meilleures performances de traitement des requêtes, mais tout cela est obtenu parce que ce n’est pas un serveur Web riche en fonctionnalités. Alors, pourquoi était-il nécessaire de créer un tel serveur Web si vous avez toujours besoin d’utiliser un serveur proxy ? Parce que sans lui, vous ne pouvez pas démarrer votre application sur différentes plateformes sans modifications. Sans Kestrel sur d’autres serveurs Web multiplateformes, le code de l’application ASP.NET Core devrait être modifié pour chaque serveur Web afin de répondre à leurs critères de démarrage.
Comme vous pouvez le constater, ASP.NET Core représente un changement majeur. Vous pouvez toujours utiliser des frameworks comme MVC, Web API, SignalR, et leur syntaxe ne changera pas radicalement, tout comme la logique métier écrite avec Entity Framework. Il s’agit toujours du même code C#, F#, etc., et le .NET Framework est derrière tout cela. En fin de compte, l’objectif ultime n’était pas de remplacer le .NET Framework par .NET Core, mais d’ajouter une alternative pour les développeurs, d’engager la nouvelle communauté, de fournir une pile technologique entièrement nouvelle pour s’adapter aux nouveaux changements dans le développement, et d’étendre la plateforme à l’avenir.
Inconvénients d’ASP.NET Core
Certaines technologies du .NET Framework ne sont pas disponibles dans la version actuelle de .NET Core. En fait, certaines d’entre elles sont prévues pour les versions ultérieures, mais d’autres pourraient ne jamais voir le jour. Voici une courte liste de scénarios où vous ne pouvez pas utiliser .NET Core :
- ASP.NET Web Forms et ASP.NET Web Pages. Ils ne sont pris en charge et fournis que par le .NET Framework complet. Dans le fil GitHub, vous pouvez trouver une réponse de l’un des développeurs Microsoft qui a expliqué qu’il n’était pas prévu de porter WebForms vers ASP.NET Core.
- Implémentation des services WCF. Ce scénario pourrait être envisagé pour les versions futures de .NET Core, mais pour l’instant, la réponse la plus précise serait “Non, actuellement ce n’est pas disponible pour .NET Core”. La seule bibliothèque disponible est WCF-Client, qui convient aux “appareils mobiles ou aux serveurs intermédiaires pour communiquer avec les services WCF existants”, comme l’indique leur page GitHub.
- Services liés au workflow, y compris Windows Workflow Foundation (WF), Workflow Services (WCF + WF dans un seul service), et WCF Data Services (anciennement connu sous le nom d’ADO.NET Data Services). Il n’est actuellement prévu de les porter vers .NET Core.
- Les applications Windows Forms et Windows Presentation Foundation (WPF) ne sont pas encore prises en charge. Cependant, la bonne nouvelle est qu’au début de cette année, Microsoft a annoncé qu’ils prévoyaient une première version preview de .NET Core 3 vers la fin de cette année et une version finale en 2019. Cette nouvelle version inclura la capacité d’exécuter des applications de bureau Windows nouvelles et existantes sur .NET Core. et vous permettra de bénéficier de tous les avantages que .NET Core a à offrir. La prise en charge du bureau Windows sera ajoutée sous forme d’un ensemble de “Windows Desktop Packs”, qui ne fonctionneront que sous Windows.
- Absence de prise en charge des bibliothèques tierces. .NET Core 2.0 fournit un adaptateur de compatibilité entre le .NET Framework et .NET Core, mais vous pourriez encore rencontrer des problèmes de compatibilité si la bibliothèque de classes utilise des API .NET Framework non prises en charge.
- Vous ne pouvez pas utiliser d’API spécifiques à Windows dans ASP.NET Core et .NET Core car ces frameworks sont conçus pour être plus indépendants du système d’exploitation. Par exemple, vous ne pouvez pas utiliser l’espace de noms System.Drawing ou travailler avec le registre Windows ; pour cela, vous devriez utiliser le .NET Framework.
Il y a beaucoup de discussions dans les fils GitHub sur le sujet du portage des bibliothèques .NET Framework vers .NET Core, et c’est un très bon exemple de la façon dont l’open source peut impacter le développement de projets. Si vous ouvrez ces fils, vous verrez que sur chaque problème, les employés de Microsoft répondent sur les plans de portage des technologies, discutent des raisons pour lesquelles ils ont eu besoin de ce portage afin de savoir ce qui est exactement nécessaire pour les développeurs. Évidemment, il y aura des technologies qui ne seront pas portées du tout, car elles sont liées au système d’exploitation Windows alors que .NET Core a été créé pour offrir un support multiplateforme.
Maintenant que nous avons passé en revue tous les changements majeurs dans .NET Core et ASP.NET Core, passons à une nouvelle structure d’application et aux changements qui persistent dans un nouveau type de projet.
Fondamentaux d’ASP.NET Core
Dans ce paragraphe, nous allons créer un projet de test pour examiner les changements dans la structure sur un exemple concret. Supposons que vous ayez déjà créé un nouveau projet avec Visual Studio au moins une fois, et nous allons examiner l’option de création d’une nouvelle solution avec le projet ensemble en utilisant une console.
Pour créer une solution, ouvrez la console (nous utiliserons Windows PowerShell, mais vous pouvez également utiliser l’invite de commandes) et exécutez la commande suivante :
dotnet new sln -n reviewCoreAppIci, dotnet new est une commande avec laquelle vous pouvez créer un nouveau projet, un fichier de configuration ou une solution basée sur le modèle spécifié avec toutes les dépendances nécessaires. Nous y avons indiqué que nous voulons créer une Solution avec l’option sln et ajouté l’option -n pour définir le nom du projet. Si vous ne spécifiez pas le nom, il sera automatiquement défini sur le nom équivalent du dossier. Vous pouvez également utiliser la commande dotnet new -l pour obtenir la liste de tous les modèles disponibles. Après avoir exécuté cette commande, si vous ouvrez le dossier, vous verrez une solution nouvellement créée. Par rapport à la structure standard du projet, créez un nouveau dossier à côté de la solution de quelque manière que ce soit :
- manuellement dans l’explorateur de fichiers ;
- dans PowerShell avec la commande md CoreAppProj ;
- dans la console Linux avec la commande mkdir CoreAppProj.
Entrez dans ce nouveau répertoire et créez le projet avec la commande :
dotnet new mvcL’option « mvc » signifie que le type de projet sera « ASP.NET Core Web App (Model-View-Controller) » et le nom sera défini sur le nom du dossier. Pour lier la solution et le projet, revenez au dossier de la solution et exécutez la commande suivante :
dotnet sln add .CoreAppProjCoreAppProj.csprojSi vous ouvrez maintenant le projet dans Visual Studio, vous verrez un projet créé standard :
Si vous examinez attentivement les fichiers du projet, vous remarquerez que le format de fichier .csproj a été simplifié dans ASP.NET Core. Examinons les principaux changements étape par étape.
Program.cs
Dans ASP.NET Core, le point d’entrée d’une application est Startup.cs, et vous n’avez plus de dépendance à Global.asax. ASP.NET Core gère l’entrée via la méthode Main de Program.cs (similaire aux applications console, et une application ASP.NET Core est en fait une application console) et Startup est chargé à partir de là :
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
namespace CoreAppProj {
public class Program {
public static void Main(string[] args) {
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup();
}
}
La méthode “Main” utilise WebHostBuilder, qui suit le modèle builder pour créer un hôte d’application web. Le builder comprend :
- la méthode qui initialise une nouvelle instance de la classe WebHostBuilder avec des paramètres par défaut préconfigurés – CreateDefaultBuilder(args) ;
- la méthode qui définit la classe de démarrage – UseStartup(). Lorsque vous démarrez l’application, l’environnement ASP.NET recherchera une classe nommée Startup dans l’assembly de l’application et la chargera. Le nom “Startup” est le nom par défaut, mais vous pouvez le renommer à votre guise. Seule une construction standard de cette classe est requise.
Comme mentionné ci-dessus, le serveur par défaut doit être Kestrel et vous pouvez souvent rencontrer la réalisation suivante :
using Microsoft.AspNetCore.Hosting;
namespace CoreAppProj {
public class Program {
public static void Main(string[] args) {
var host = new WebHostBuilder()
.UseKestrel()
.UseStartup()
.Build();
host.Run();
}
}
}
Les deux (la réalisation ci-dessus et dans notre exemple) sont valables. Vous devez juste savoir qu’utiliser la méthode “CreateDefaultBuilder” signifie que les paramètres par défaut suivants seront appliqués (fournis par la documentation officielle de Microsoft) :
- utiliser Kestrel comme serveur Web et le configurer à l’aide des fournisseurs de configuration de l’application ;
- définir ContentRootPath sur le résultat de GetCurrentDirectory() ;
- charger IConfiguration à partir de “appsettings.json” et “appsettings.[EnvironmentName].json” ;
- charger IConfiguration à partir des secrets utilisateur lorsque EnvironmentName est ‘Development’ en utilisant l’assembly d’entrée ;
- charger IConfiguration à partir des variables d’environnement ;
- configure le ILoggerFactory pour logger dans la console et la sortie de débogage ;
- active l’intégration IIS ;
- active la possibilité pour les frameworks de lier leurs options à leurs sections de configuration par défaut.
Vous pouvez modifier manuellement les paramètres et définir un autre serveur Web. Les méthodes Build et Run construisent le IWebHost qui hébergera l’application et la démarrera pour écouter les requêtes HTTP entrantes.
Startup.cs
La méthode UseStartup sur WebHostBuilder définit la classe Startup de l’application, où le pipeline de requêtes de l’application est défini et où tous les services sont configurés. Une classe Startup doit inclure une méthode Configure où les middlewares nécessaires sont ajoutés au pipeline. Ci-dessous un extrait de code généré que vous devriez voir après la création d’un projet :
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
namespace CoreAppProj {
public class Startup {
public Startup(IConfiguration configuration) {
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services) {
services.Configure(options => {
// This lambda determines whether user consent for non-essential cookies is needed for a given request.
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env) {
if (env.IsDevelopment()) {
app.UseDeveloperExceptionPage();
}
else {
app.UseExceptionHandler("/Home/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseMvc(routes => {
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
}
}
ConfigureServices définit les services utilisés par l’application et Configure définit les middlewares dans le pipeline de requêtes. Dans l’exemple ci-dessus, la méthode Configure configure le pipeline avec la prise en charge de :
- Pages d’erreurs ;
- HTTP Strict Transport Security ;
- Redirection HTTP vers HTTPS ;
- ASP.NET Core MVC.
Middleware
Les middlewares ASP.NET Core sont des morceaux de code qui effectuent une logique asynchrone sur un HttpContext. Les requêtes entrantes sont transmises à travers le pipeline où chaque middleware appelle le middleware suivant dans le pipeline ou termine la requête. Les middlewares peuvent effectuer tout type d’opérations, telles que la gestion de l’authentification, des erreurs, des fichiers statiques, etc. Par exemple, MVC dans ASP.NET Core est également implémenté comme un middleware. En fait, vous pouvez soit créer des middlewares personnalisés, soit utiliser ceux dont vous avez besoin parmi un vaste ensemble de middlewares intégrés, et vous pouvez écrire vos propres middlewares personnalisés. Dans l’exemple ci-dessus, les middlewares sont :
- UseDeveloperExceptionPage – permet de voir des informations détaillées sur les exceptions. Il est fortement recommandé de l’utiliser uniquement en pré-production. L’appel de ce middleware doit être placé avant le middleware où vous souhaitez capturer les exceptions, par exemple, avant app.UseMvc() ;
- UseExceptionHandler – configure une page de traitement des exceptions. Généralement, il est utilisé en production au lieu de UseDeveloperExceptionPage, de sorte que lorsque l’utilisateur obtient une erreur, la page spécifiée dans ce middleware sera affichée ;
- UseHsts – est utilisé pour envoyer des en-têtes HTTP Strict Transport Security Protocol (HSTS) aux clients ;
- UseHttpsRedirection – est utilisé pour rediriger les requêtes HTTP vers HTTPS ;
- UseStaticFiles – la méthode UseStaticFiles sans paramètre active la fonctionnalité permettant d’accéder aux fichiers dans le dossier via le navigateur Web. Par exemple, vous pouvez inclure le chemin d’accès à n’importe quel fichier du dossier wwwroot dans le balisage, et il sera visible par les utilisateurs. Le dossier wwwroot (/wwwroot) est le répertoire par défaut, mais il peut être modifié manuellement ;
- UseCookiePolicy – active les fonctionnalités de politique de cookies dans une application. N’affecte également que les composants enregistrés après lui dans le pipeline.
Configuration
ASP.NET Core a également modifié son modèle de configuration pour gérer des paires nom-valeur simples. Le nouveau modèle de configuration est basé sur des paires clé-valeur établies par des fournisseurs de configuration au lieu de s’appuyer sur System.Configuration ou web.config. Les fournisseurs de configuration peuvent lire les données de configuration à partir d’une variété de formats de fichiers : XML, JSON, INI, ainsi que des variables d’environnement, des arguments de ligne de commande, ou une collection en mémoire. Vous pouvez également écrire votre propre fournisseur de configuration personnalisé. Par défaut, dans votre projet de test, que nous avons créé ci-dessus, vous devriez voir un fichier JSON créé automatiquement nommé “appsettings.json”. Vous pouvez y ajouter des chaînes de connexion, définir des hôtes autorisés, etc.
Fournisseur de configuration de variables d’environnement
Le nouveau modèle de configuration permet également d’utiliser les variables d’environnement via EnvironmentVariablesConfigurationProvider, qui charge la configuration à partir de paires clé-valeur de variables d’environnement au moment de l’exécution. Pour activer la configuration des variables d’environnement, vous devez ajouter un appel à la méthode d’extension AddEnvironmentVariables sur une instance de ConfigurationBuilder. Lorsque l’application s’exécutera, le Fournisseur de configuration des variables d’environnement sera appelé juste après que la configuration soit établie à partir des secrets utilisateur et des fichiers appsettings. Appeler le fournisseur à cette position permet aux variables d’environnement lues au moment de l’exécution de remplacer la configuration définie par les secrets utilisateur et les fichiers appsettings.
Exécution de l’application
Au début de la section, nous avons déjà brièvement examiné les moyens de démarrer le développement d’applications à l’aide des outils .NET Core CLI, nous allons donc maintenant passer en revue quelques commandes supplémentaires pour terminer cet aperçu rapide du tutoriel.
Si vous commencez à chercher des informations sur l’exécution d’une application via la CLI, vous trouverez au moins 3 commandes :
- dotnet restore – il fait appel à NuGet, qui analyse le fichier CoreAppProj.csproj, télécharge les dépendances définies dans le fichier (ou les récupère dans un cache sur votre machine) et écrit le fichier obj/project.assets.json, qui est nécessaire pour compiler et exécuter le code ;
- dotnet build – compile un projet et toutes ses dépendances ;
- dotnet run – exécute le code source.
En fait, si vous utilisez le SDK .NET Core 2.0, vous n’aurez besoin d’utiliser que la dernière commande de cette liste. La commande dotnet restore s’exécute implicitement par toutes les commandes qui nécessitent un redémarrage : dotnet new, dotnet build et dotnet run. Cette commande est toujours utilisée dans certains cas, mais dans celui-ci, elle n’est pas nécessaire. Quant à dotnet build, il est également appelé par la commande dotnet restore pour s’assurer que les cibles de build ont été construites. C’est pourquoi, si nous exécutons la commande dotnet run, les dépendances du projet sont téléchargées, le projet est compilé et l’application s’exécute. Et c’est tout ! Vous pouvez maintenant commencer à utiliser ces concepts de base pour créer une application et améliorer vos compétences.
Conclusion
.NET Core et ASP.NET Core incluent de nombreuses nouvelles améliorations et des changements fondamentaux qui devraient vous aider dans le développement quotidien. Croiriez-vous si quelqu’un disait dans le passé que Microsoft fournirait des solutions open source et multiplateformes ? Probablement pas. Mais les temps changent, et aujourd’hui Microsoft propose d’excellentes solutions qui attirent de plus en plus de développeurs. C’est pourquoi nous pensons que l’avenir réserve des changements encore plus importants que nous couvrirons dans d’autres articles.
Découvrez comment nous avons développé une solution pour la logistique de remise en forme claire avec ASP.NET core
