Avvio dell'app

Suggerimento

Questo contenuto è un estratto dell'eBook Blazor for ASP NET Web Form Developers for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.

Scarica PDF

Le applicazioni scritte per ASP.NET in genere hanno un file global.asax.cs che definisce l'evento Application_Start che controlla quali servizi sono configurati e resi disponibili sia per il rendering HTML che per l'elaborazione .NET. Questo capitolo illustra come le cose sono leggermente diverse con ASP.NET Core e Blazor Server.

Application_Start e Web Forms

Il metodo web form Application_Start predefinito è cresciuto nello scopo nel corso degli anni per gestire molte attività di configurazione. Un nuovo progetto web forms con il modello predefinito in Visual Studio 2022 contiene ora la logica di configurazione seguente:

• RouteConfig - Routing dell'URL dell'applicazione
• BundleConfig - Creazione di bundle e minimizzazione CSS e JavaScript

Ognuno di questi singoli file si trova nella cartella App_Start ed esegue una sola volta all'inizio dell'applicazione. RouteConfig nel modello di progetto predefinito aggiunge il FriendlyUrlSettings per i Web form per consentire agli URL dell'applicazione di omettere l'estensione di file .ASPX. Il modello predefinito contiene anche una direttiva che fornisce codici di stato di reindirizzamento HTTP permanenti (HTTP 301) per le pagine .ASPX all'URL descrittivo con il nome file che omette l'estensione.

Con ASP.NET Core e Blazor, questi metodi sono semplificati e consolidati nella classe Startup o vengono eliminati a favore di tecnologie Web comuni.

Struttura di avvio del server Blazor

Le applicazioni Blazor Server si trovano in una versione ASP.NET Core 3.0 o successiva. Le applicazioni Web di base di ASP.NET vengono configurate in Program.cso tramite una coppia di metodi nella classe Startup.cs. Di seguito è riportato un file di esempio Program.cs:

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();

I servizi necessari dell'app vengono aggiunti alla raccolta di Services dell'istanza di WebApplicationBuilder. Questo è il modo in cui i vari servizi framework di ASP.NET Core vengono configurati con il contenitore di inserimento delle dipendenze predefinito del framework. I vari metodi di builder.Services.Add* aggiungono servizi che abilitano funzionalità come, tra le altre, l'autenticazione, le pagine razor, il routing del controller MVC, SignalR e le interazioni del server Blazor. Questo metodo non era necessario nei web form, perché l'analisi e la gestione dei file ASPX, ASCX, ASHX e ASMX sono stati definiti facendo riferimento ad ASP.NET nel file di configurazione web.config. Altre informazioni sull'inserimento delle dipendenze in ASP.NET Core sono disponibili nella documentazione online.

Dopo che app è stato compilato da builder, il resto delle chiamate su app configura la sua pipeline HTTP. Con queste chiamate, dichiariamo dall'alto verso il basso il middleware che gestirà ogni richiesta inviata all'applicazione. La maggior parte di queste funzionalità nella configurazione predefinita è stata distribuita tra i file di configurazione dei web form e ora si trova in un'unica posizione per facilitare il riferimento.

Non è più la configurazione della pagina di errore personalizzata inserita in un file web.config, ma ora è configurata per essere sempre visualizzata se l'ambiente dell'applicazione non è etichettato Development. Inoltre, ASP.NET le applicazioni Core sono ora configurate per gestire pagine sicure con TLS per impostazione predefinita con la chiamata al UseHttpsRedirection metodo.

Successivamente, viene eseguita una chiamata imprevista del metodo di configurazione a UseStaticFiles. In ASP.NET Core, il supporto per le richieste di file statici (ad esempio i file JavaScript, CSS e image) deve essere abilitato in modo esplicito e solo i file nella cartella wwwroot sono indirizzabili pubblicamente per impostazione predefinita.

La riga successiva è la prima che replica una delle opzioni di configurazione dai web form: UseRouting. Questo metodo aggiunge il router ASP.NET Core alla pipeline e può essere configurato qui o nei singoli file verso cui può prendere in considerazione il routing. Altre informazioni sulla configurazione del routing sono disponibili nella sezione routing.

Le chiamate app.Map* finali in questa sezione definiscono gli endpoint su cui ASP.NET Core è in ascolto. Queste route sono le posizioni accessibili dal Web a cui è possibile accedere sul server Web e ricevono contenuto gestito da .NET e restituito all'utente. La prima voce, MapBlazorHub configura un hub SignalR da usare per fornire la connessione in tempo reale e permanente al server in cui viene gestito lo stato e il rendering dei componenti Blazor. La chiamata al metodo MapFallbackToPage indica il percorso accessibile dal Web della pagina che avvia l'applicazione Blazor e configura anche l'applicazione per gestire le richieste di deep linking dal lato client. Questa funzionalità verrà visualizzata al lavoro se si apre un browser e si passa direttamente alla route gestita Blazor nell'applicazione, ad esempio /counter nel modello di progetto predefinito. La richiesta viene gestita dalla pagina di fallback _Host.cshtml, che esegue quindi il router Blazor ed esegue il rendering della pagina del contatore.

L'ultima riga avvia l'applicazione, un elemento che non era necessario nei Web form (poiché si basava su IIS per l'esecuzione).

Aggiornamento del processo BundleConfig

Le tecnologie per la creazione di bundle di asset come fogli di stile CSS e file JavaScript sono cambiate in modo significativo, con altre tecnologie che forniscono strumenti e tecniche in rapida evoluzione per la gestione di queste risorse. A questo scopo, è consigliabile usare uno strumento da riga di comando Node, ad esempio Grunt/Gulp/WebPack, per creare un pacchetto degli asset statici.

Gli strumenti da riga di comando Grunt, Gulp e WebPack e le configurazioni associate possono essere aggiunti all'applicazione e ASP.NET Core ignoreranno tranquillamente tali file durante il processo di compilazione dell'applicazione. È possibile aggiungere una chiamata per eseguire le attività aggiungendo un Target all'interno del file di progetto con una sintassi simile alla seguente che attiverebbe uno script gulp e la destinazione min all'interno di tale script:

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

Altre informazioni su entrambe le strategie per gestire i file CSS e JavaScript sono disponibili nella documentazione bundle e minimizza gli asset statici nella documentazione di ASP.NET Core.

PrecedenteSuccessivo