Démarrage de l’application

Conseil / Astuce

Ce contenu est un extrait du livre électronique, Blazor pour les développeurs Web Forms ASP NET pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

Les applications écrites pour ASP.NET ont généralement un global.asax.cs fichier qui définit l’événement Application_Start qui contrôle les services configurés et mis à disposition pour le traitement HTML et .NET. Ce chapitre explique comment les choses sont légèrement différentes avec ASP.NET Core et Blazor Server.

Application_Start et Web Forms

La méthode de formulaires Application_Start web par défaut a augmenté au fil des années pour gérer de nombreuses tâches de configuration. Un nouveau projet de formulaires web avec le modèle par défaut dans Visual Studio contient la logique de configuration suivante :

• RouteConfig - Routage d’URL d’application
• BundleConfig - Regroupement et minification de CSS et de JavaScript

Chacun de ces fichiers individuels réside dans le App_Start dossier 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 configure les FriendlyUrlSettings pour les formulaires web afin de permettre aux URL de l'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 .ASPX pages vers l’URL conviviale avec le nom de fichier qui omet l’extension.

Avec ASP.NET Core et Blazor, ces méthodes sont soit simplifiées et consolidées dans la Startup classe, soit elles sont éliminées en faveur des technologies web courantes.

Structure de démarrage du serveur Blazor

Les applications Blazor Server résident sur une version ASP.NET Core 3.0 ou ultérieure. ASP.NET applications web principales sont configurées dans Program.cs, ou par le biais d’une paire de méthodes dans la Startup.cs classe. 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 WebApplicationBuilder de l’instance Services. C’est ainsi que les différents services d’infrastructure core ASP.NET sont configurés avec le conteneur d’injection de dépendances intégré de l’infrastructure. Les différentes builder.Services.Add* méthodes ajoutent des services qui activent des fonctionnalités telles que l’authentification, les Pages Razor, le routage du contrôleur MVC, SignalR et les interactions Blazor Server, entre autres. Cette méthode n’a pas été nécessaire dans les formulaires web, car l’analyse et la gestion des fichiers ASPX, ASCX, ASHX et ASMX ont été définis en référençant ASP.NET dans le fichier de configuration web.config. Pour plus d’informations sur l’injection de dépendances dans ASP.NET Core, consultez 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é dispersées dans les fichiers de configuration des formulaires web et sont désormais à un seul endroit pour faciliter la référence.

La configuration de la page d’erreur personnalisée n’est plus placée dans un web.config fichier, mais elle est désormais configurée pour toujours s’afficher si l’environnement de l’application n’est pas étiqueté Development. En outre, les applications ASP.NET Core sont désormais configurées pour servir des pages sécurisées avec TLS par défaut grâce à l'appel de la méthode UseHttpsRedirection.

Ensuite, un appel inattendu de méthode de configuration est effectué à UseStaticFiles. Dans ASP.NET Core, la prise en charge des demandes de fichiers statiques (par exemple, JavaScript, CSS et fichiers image) doit être explicitement activée, 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 de formulaires web : UseRouting. Cette méthode ajoute le routeur ASP.NET Core au pipeline et peut être configuré ici ou dans les fichiers individuels auxquels il peut envisager le routage. Vous trouverez plus d’informations sur la configuration du routage dans la section Routage.

Les appels finaux app.Map* de cette section définissent les points de terminaison sur lesquels ASP.NET Core est à l'écoute. Ces itinéraires sont les emplacements accessibles sur le web auxquels vous pouvez accéder sur le serveur web et recevoir du contenu géré par .NET et retourné à vous. La première entrée MapBlazorHub configure un hub SignalR à utiliser pour fournir la connexion en temps réel et persistante au serveur où l’état et le rendu des composants Blazor sont gérés. L’appel MapFallbackToPage de méthode 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 demandes de liaison approfondie du côté client. Vous verrez cette fonctionnalité au travail si vous ouvrez un navigateur et accédez directement à l’itinéraire géré par Blazor dans votre application, par /counter exemple 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 obligatoire dans les formulaires web (car il s’appuyait sur IIS pour être en cours d’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 changé de manière significative, d’autres technologies fournissant des outils et techniques en évolution rapide 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 à l'intérieur de votre fichier projet avec une syntaxe similaire à celle qui suit, ce qui déclencherait un script gulp et la min cible à l'intérieur de ce script :

<Target Name="MyPreCompileTarget" BeforeTargets="Build">
  <Exec Command="gulp min" />
</Target>

Vous trouverez plus d’informations sur les deux stratégies pour gérer vos fichiers CSS et JavaScript dans la documentation Bundle et minifier les ressources statiques dans ASP.NET documentation Core .

PrécédentSuivant