Ospitare e pubblicare ASP.NET Core Blazor

Questo articolo illustra come ospitare e distribuire le app Blazor.

Pubblicazione dell'app

Le app vengono pubblicate per la distribuzione in configurazione di rilascio.

Visual Studio

1. Selezionare il comando Pubblica {APPLICATION} dal menu Generazione, dove il segnaposto {APPLICATION} rappresenta il nome dell'app.
2. Selezionare la destinazione di pubblicazione. Per pubblicare in locale, selezionare Cartella. Seleziona Avanti.
3. Quando si esegue la pubblicazione in locale, accettare il percorso predefinito della cartella o specificare un percorso diverso. Selezionare Fine per salvare il profilo. Seleziona Chiudi.
4. Per pulire la cartella di pubblicazione della destinazione prima di pubblicare l'app, selezionare Mostra tutte le impostazioni. Selezionare Impostazioni>Opzioni di Pubblicazione File>Elimina tutti i file esistenti prima della pubblicazione. Seleziona Salva.
5. Selezionare il pulsante Pubblica.

Visual Studio Code e l'interfaccia della riga di comando di .NET

Aprire una shell dei comandi nella directory radice del progetto.

Usare il dotnet publish comando per pubblicare l'app:

dotnet publish

Prima di .NET 8, la configurazione di pubblicazione predefinita è Debug. Quando si pubblica un'app che ha come target .NET 7 o versioni precedenti, passare l'opzione -c|--configuration al comando con "Release" per pubblicare nella configurazione Release.

dotnet publish -c Release

La pubblicazione dell'app attiva un ripristino delle dipendenze del progetto e compila il progetto prima di creare gli asset per la distribuzione. Come parte del processo di compilazione, vengono rimossi gli assembly e i metodi non usati per ridurre le dimensioni del download e i tempi di caricamento dell'app.

Svuotare la cartella di pubblicazione di destinazione

Quando si usa il dotnet publish comando in una shell dei comandi per pubblicare un'app, il comando genera i file necessari per la distribuzione in base allo stato corrente del progetto e inserisce i file nella cartella di output specificata. Il comando non pulisce automaticamente la cartella di destinazione prima di pubblicare l'app.

Per svuotare automaticamente la cartella di destinazione prima della pubblicazione dell'app, aggiungere la destinazione MSBuild seguente al file di progetto dell'app (.csproj) sotto l'elemento radice <Project> :

<Target Name="_RemovePublishDirBeforePublishing" BeforeTargets="BeforePublish">
  <RemoveDir Directories="$(PublishDir)" Condition="'$(PublishDir)' != ''" />
</Target>

Percorsi di pubblicazione predefiniti

• Blazor Web App: L'applicazione viene pubblicata nella cartella /bin/Release/{TARGET FRAMEWORK}/publish, in cui il segnaposto {TARGET FRAMEWORK} è il framework di destinazione. Distribuire il contenuto della cartella publish nell'host.
• L'app viene pubblicata in modalità autonoma nella cartella Blazor WebAssembly o bin/Release/{TARGET FRAMEWORK}/publish. Per distribuire l'app come sito statico, copiare il contenuto della cartella wwwroot nell'host del sito statico.

IIS

Per ospitare un'app Blazor in IIS, vedere le risorse seguenti:

• Hosting IIS
  • Pubblicare un'app ASP.NET Core in IIS
  • Host ASP.NET Core in Windows con IIS
• Ospitare e distribuire app lato server ASP.NET Core: s (.NET 8 o versione successiva) e app (.NET 7 o versioni precedenti) in esecuzione in IIS, incluso IIS con macchine virtuali di Azure che eseguono il sistema operativo Windows e Azure App Service.
• Ospitare e distribuire ASP.NET Core Blazor WebAssembly con IIS: app autonome Blazor WebAssembly (tutte le versioni .NET) e app ospitate Blazor WebAssembly (.NET 7 o versioni precedenti).
• Hosting di applicazioni secondarie IIS
  • Seguire le indicazioni sul percorso di base dell'app prima di pubblicare l'app. Gli esempi usano un percorso di base dell'app di /CoolApp e illustrano come ottenere il percorso di base dalle impostazioni dell'app o da altri provider di configurazione.
  • Seguire le indicazioni sulla configurazione dell'applicazione secondaria in Configurazione avanzata. Il percorso della cartella dell'app secondaria nel sito radice diventa il percorso virtuale dell'app secondaria. Per un percorso di base dell'app di /CoolApp, l'app Blazor viene inserita in una cartella denominata CoolApp nel sito radice e l'app secondaria assume un percorso virtuale di /CoolApp.

La condivisione di un pool di app tra app ASP.NET Core non è supportata, nemmeno per le app Blazor. Usare un pool di app per ogni app in caso di hosting con IIS ed evitare l'uso delle directory virtuali di IIS per ospitare più app.

Supporto del bundler JavaScript

Il Blazor runtime si basa su file JavaScript (JS), il runtime .NET compilato nel codice WebAssembly e gli assembly gestiti compressi come file WebAssembly. Quando un'app Blazor viene compilata, il runtime Blazor dipende da questi file provenienti da diverse posizioni di build. A causa di questo vincolo, Blazorl'output di compilazione non è compatibile con JS i bundler, ad esempio Gulp, Webpack e Rollup.

Per produrre output di compilazione compatibile con JS i bundler durante la pubblicazione, impostare la WasmBundlerFriendlyBootConfig proprietà MSBuild su true nel file di progetto dell'app:

<WasmBundlerFriendlyBootConfig>true</WasmBundlerFriendlyBootConfig>

Importante

Questa funzionalità genera solo l'output compatibile con il bundler quando si pubblica l'app.

L'output non può essere eseguito direttamente nel browser, ma può essere utilizzato dagli JS strumenti per combinare i JS file con il resto degli script forniti dallo sviluppatore.

Quando WasmBundlerFriendlyBootConfig è abilitata, l'oggetto prodotto JS contiene import direttive per tutti gli asset nell'applicazione, che rende le dipendenze visibili per il bundler. Molti degli asset non sono caricabili dal browser, ma i bundler in genere possono essere configurati per riconoscere gli asset in base al tipo di file per gestire il caricamento. Per informazioni dettagliate su come configurare il bundler, vedere la documentazione del bundler.

Nota

L'output di compilazione in bundle deve essere possibile eseguendo il mapping delle importazioni a singoli percorsi di file usando un JS plug-in personalizzato bundler. Al momento non viene fornito un plug-in di questo tipo.

Nota

Sostituendo il plugin files con url, tutti i file dell'app JS incluso il runtime WebAssembly (codificato in base64 in Blazor) vengono raggruppati nell'output. Le dimensioni del file sono significativamente più grandi (ad esempio, 300% più grandi) rispetto a quando i file vengono curati con il plug-in files, quindi non è consigliabile usare il plug-in url come procedura generale quando si produce output adatto al bundler per l'elaborazione con il bundler JS.

Le app di esempio seguenti sono basate su Rollup. Concetti simili si applicano quando si usano altri JS bundler.

Le app di esempio dimostrative per Blazor WebAssembly in un'app React (BlazorWebAssemblyReact) e .NET in WebAssembly in un'app React (DotNetWebAssemblyReact) per .NET 10 o versione successiva sono disponibili nel Blazor repository GitHub degli esempi (dotnet/blazor-samples).

Aspetti della memorizzazione nella Blazor WebAssembly cache si applicano a Blazor Web Apps

Blazor La memorizzazione nella cache dei bundle e le linee guida per la Blazor WebAssembly memorizzazione nella cache HTTP nel nodo sono incentrate sulle app autonome Blazor WebAssembly , ma diversi aspetti della memorizzazione nella cache sul lato client in questi articoli si applicano anche alle Blazor Web Appmodalità di rendering interattivo WebAssembly o Interactive Auto. Se un Blazor Web App che renderizza contenuti lato client riscontra un problema di cache con risorse statiche o pacchetti, consultare questi articoli per la risoluzione del problema.

• Errori di memorizzazione nella cache e di controllo dell'integrità in ASP.NET Core Blazor WebAssembly
• Evitare problemi di memorizzazione nella cache HTTP durante l'aggiornamento delle app ASP.NET Core Blazor

Configurazione Blazor ServerMapFallbackToPage

Questa sezione si applica solo alle Blazor Server app. MapFallbackToPage non è supportato nei Blazor Web App e nelle app Blazor WebAssembly.

Negli scenari in cui un'app richiede un'area separata con risorse personalizzate e componenti di Razor:

• Creare una cartella all'interno della cartella Pages dell'app per conservare le risorse. Ad esempio, una sezione amministratore di un'app viene creata in una nuova cartella denominata Admin (Pages/Admin).

• Creare una pagina radice (_Host.cshtml) per l'area. Ad esempio, creare un file Pages/Admin/_Host.cshtml dalla pagina radice principale dell'app (Pages/_Host.cshtml). Non fornire una direttiva @page nella pagina _Host di Admin.

• Aggiungere un layout alla cartella dell'area (ad esempio, Pages/Admin/_Layout.razor). Nel layout dell'area separata impostare il valore <base> del tag href in modo che corrisponda alla cartella dell'area (ad esempio, <base href="/Admin/" />). Per scopi dimostrativi, aggiungere ~/ alle risorse statiche nella pagina. Ad esempio:

  • ~/css/bootstrap/bootstrap.min.css
  • ~/css/site.css
  • ~/BlazorSample.styles.css (il namespace dell'app di esempio è BlazorSample)
  • ~/_framework/blazor.server.js (script Blazor)

• Se l'area deve avere la propria cartella degli asset statici, aggiungere la cartella e specificarne la posizione nel middleware dei file statici in Program.cs (ad esempio, app.UseStaticFiles("/Admin/wwwroot")).

• I componenti di Razor vengono aggiunti alla cartella dell'area. Aggiungere almeno un componente Index alla cartella dell'area con la direttiva @page corretta per quell'area. Ad esempio, aggiungere un file Pages/Admin/Index.razor basato sul file Pages/Index.razor predefinito dell'app. Indicare l'area Admin come modello di route all'inizio del file (@page "/admin"). Aggiungi ulteriori componenti come necessario. Ad esempio, Pages/Admin/Component1.razor con una direttiva @page e un modello di route @page "/admin/component1.

• In Program.cs, chiamare MapFallbackToPage per il percorso di richiesta dell'area immediatamente prima del percorso radice di fallback alla pagina _Host:

  ...
  app.UseRouting();
  
  app.MapBlazorHub();
  app.MapFallbackToPage("~/Admin/{*clientroutes:nonfile}", "/Admin/_Host");
  app.MapFallbackToPage("/_Host");
  
  app.Run();