Démarrage des applications
Conseil
Ce contenu est un extrait du livre électronique, Blazor for ASP NET Web Forms Developers for Azure (Blazor pour les développeurs ASP NET Web Forms pour Azure), disponible sur la documentation .NET ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.
Les applications écrites pour ASP.NET ont généralement un fichier global.asax.cs qui définit l’événement Application_Start qui contrôle les services configurés et mis à disposition pour le rendu HTML et le traitement .NET. Ce chapitre explique les légères différences entre ASP.NET Core et Blazor Server.
Application_Start et Web Forms
La méthode de formulaires web par défaut Application_Start a évolué au fil des ans pour gérer de nombreuses tâches de configuration. Un nouveau projet web forms avec le modèle par défaut dans Visual Studio 2022 contient désormais la logique de configuration suivante :
RouteConfig- Routage d’URL d’applicationBundleConfig- Regroupement et minimisation CSS et JavaScript
Chacun de ces fichiers individuels réside dans le dossier App_Start et ne s’exécute qu’une seule fois au début de notre application. RouteConfig dans le modèle de projet par défaut ajoute FriendlyUrlSettings pour les web forms afin de permettre aux URL d’application d’omettre l’extension de fichier .ASPX. Le modèle par défaut contient également une directive qui fournit des codes d’état de redirection HTTP permanents (HTTP 301) pour les pages .ASPX vers l’URL conviviale avec le nom de fichier qui omet l’extension.
Avec ASP.NET Core et Blazor, ces méthodes sont simplifiées et consolidées dans la classe Startup ou sont éliminées au profit des technologies web courantes.
Structure de démarrage du serveur Blazor
Les applications Blazor Server résident sur ASP.NET Core 3.0 ou version ultérieure. Le applications web ASP.NET Core sont configurées dans Program.cs ou par le biais d’une paire de méthodes dans la classe Startup.cs. Un exemple de fichier Program.cs est illustré ci-dessous :
using BlazorApp1.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
var app = builder.Build();
// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");
app.Run();
Les services requis de l’application sont ajoutés à la collection Services de l’instance WebApplicationBuilder. C’est ainsi que les différents services d’infrastructure ASP.NET Core sont configurés avec le conteneur d’injection de dépendances intégré de l’infrastructure. Les différentes méthodes builder.Services.Add* ajoutent des services qui activent des fonctionnalités telles que l’authentification, Razor Pages, le routage du contrôleur MVC, SignalR et les interactions Blazor Server, entre autres. Cette méthode n’était pas nécessaire dans les web forms, car l’analyse et la gestion des fichiers ASPX, ASCX, ASHX et ASMX étaient définis en référençant ASP.NET dans le fichier de configuration web.config. Des informations supplémentaires sur l’injection de dépendances dans ASP.NET Core sont disponibles dans la documentation en ligne.
Une fois le app généré par le builder, le reste des appels sur app configurent son pipeline HTTP. Avec ces appels, nous déclarons de haut en bas le Middleware qui gérera chaque requête envoyée à notre application. La plupart de ces fonctionnalités de la configuration par défaut ont été réparties dans les fichiers de configuration de web forms et se trouvent désormais à un seul endroit pour pouvoir s’y référer facilement.
De même, la configuration de la page d’erreur personnalisée n’est plus placée dans un fichier web.config, mais elle est maintenant configurée pour toujours être affichée si l’environnement d’application n’est pas étiqueté Development. En outre, ASP.NET Core applications sont désormais configurées pour traiter des pages sécurisées avec TLS par défaut avec l’appel de méthode UseHttpsRedirection.
Ensuite, un appel de méthode de configuration inattendu est effectué à UseStaticFiles. Dans ASP.NET Core, la prise en charge des requêtes de fichiers statiques (comme les fichiers JavaScript, CSS et image) doit être activée explicitement, et seuls les fichiers du dossier wwwroot de l’application sont adressables publiquement par défaut.
La ligne suivante est la première qui réplique l’une des options de configuration à partir des web forms : UseRouting. Cette méthode ajoute le routeur ASP.NET Core au pipeline et peut être configuré ici ou dans les fichiers individuels vers lesquels il peut envisager d’effectuer le routage. Vous trouverez plus d’informations sur la configuration du routage dans la section Routage.
Les appels app.Map* finaux de cette section définissent les points de terminaison qu’écoute ASP.NET Core. Ces itinéraires correspondent aux emplacements accessibles sur le web auxquels vous pouvez accéder sur le serveur web et sur lesquels vous pouvez recevoir du contenu géré par .NET que vous avez retourné. La première entrée MapBlazorHub configure un hub SignalR à utiliser pour fournir la connexion en temps réel et persistante au serveur où sont gérés l’état et le rendu des composants Blazor. L’appel de méthode MapFallbackToPage indique l’emplacement accessible sur le web de la page qui démarre l’application Blazor et configure également l’application pour gérer les requêtes de liaison approfondie côté client. Vous verrez cette fonctionnalité si vous ouvrez un navigateur et accédez directement à l’itinéraire géré par Blazor dans votre application, comme /counter dans le modèle de projet par défaut. La requête est gérée par la page de secours _Host.cshtml, qui exécute ensuite le routeur Blazor et affiche la page du compteur.
La dernière ligne démarre l’application, ce qui n’était pas nécessaire dans les web forms (car IIS était utilisé pour l’exécution).
Mise à niveau du processus BundleConfig
Les technologies de regroupement de ressources telles que les feuilles de style CSS et les fichiers JavaScript ont considérablement évolué, avec le développement d’autres technologies offrant des outils et des techniques qui évoluent rapidement pour la gestion de ces ressources. À cette fin, nous vous recommandons d’utiliser un outil en ligne de commande Node tel que Grunt / Gulp / WebPack pour empaqueter vos ressources statiques.
Les outils en ligne de commande Grunt, Gulp et WebPack et leurs configurations associées peuvent être ajoutés à votre application et ASP.NET Core ignore silencieusement ces fichiers pendant le processus de génération de l’application. Vous pouvez ajouter un appel pour exécuter leurs tâches en ajoutant un Target dans votre fichier de projet avec une syntaxe similaire à ce qui suit pour déclencher un script Gulp et la cible min à l’intérieur de ce script :
<Target Name="MyPreCompileTarget" BeforeTargets="Build">
<Exec Command="gulp min" />
</Target>
Pour plus d’informations sur les deux stratégies de gestion de vos fichiers CSS et JavaScript, consultez la documentation Regrouper et minimiser les ressources statiques dans ASP.NET Core.
