Héberger et déployer ASP.NET Core Blazor

Cet article explique comment héberger et déployer des applications Blazor.

Publier l’application

Les applications sont publiées pour le déploiement dans la configuration Release.

Visual Studio

1. Sélectionnez la commande Publier {APPLICATION} dans le menu Build, où l’espace réservé {APPLICATION} correspond au nom de l’application.
2. Sélectionnez l’onglet Cible de publication. Pour publier localement, sélectionnez Dossier. Cliquez sur Suivant.
3. Lors de la publication localement, acceptez l’emplacement du dossier par défaut ou spécifiez un autre emplacement. Sélectionnez Terminer pour enregistrer le profil. Sélectionnez Fermer.
4. Pour nettoyer le dossier de publication de la cible avant de publier l’application, sélectionnez Afficher tous les paramètres. SélectionnezOptions> de publication de fichier paramètres>Supprimer tous les fichiers existants avant la publication. Cliquez sur Enregistrer.
5. Cliquez sur le bouton Publier.

Visual Studio Code et l’interface CLI .NET

Ouvrez un interpréteur de commandes dans le répertoire racine du projet.

Utilisez la dotnet publish commande pour publier l’application :

dotnet publish

Avant .NET 8, la configuration de publication par défaut est Debug. Lors de la publication d’une application qui cible .NET 7 ou une version antérieure, passez l’option -c|--configuration à la commande avec «Release» pour publier dans la configuration indiquée par Release.

dotnet publish -c Release

La publication de l’application déclenche une restauration des dépendances du projet et crée le projet avant de créer les ressources pour le déploiement. Dans le cadre du processus de génération, les assemblys et méthodes inutilisés sont supprimés pour réduire la durée du chargement et la taille du téléchargement de l’application.

Vider le dossier de publication cible

Lorsque vous utilisez la dotnet publish commande dans un interpréteur de commandes pour publier une application, la commande génère les fichiers nécessaires pour le déploiement en fonction de l’état actuel du projet et place les fichiers dans le dossier de sortie spécifié. La commande ne nettoie pas automatiquement le dossier cible avant de publier l’application.

Pour vider automatiquement le dossier cible avant la publication de l’application, ajoutez la cible MSBuild suivante au fichier projet de l’application (.csproj) sous l’élément racine <Project> :

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

Emplacements de publication par défaut

• Blazor Web App: L'application est publiée dans le dossier /bin/Release/{TARGET FRAMEWORK}/publish, où le placeholder {TARGET FRAMEWORK} est le framework cible. Déployez le contenu du dossier publish sur l’hôte.
• Autonome Blazor WebAssembly : l'application est publiée dans le dossier bin/Release/{TARGET FRAMEWORK}/publish ou bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish. Pour déployer l’application en tant que site statique, copiez le contenu du dossier wwwroot sur l’hôte de site statique.

IIS

Pour héberger une application Blazor dans IIS, consultez les ressources suivantes :

• Hébergement IIS
  • Publier une application ASP.NET Core sur IIS
  • Héberger ASP.NET Core sur Windows avec IIS
• Héberger et déployer des applications Blazor côté serveur ASP.NET Core : Blazor Web Apps (.NET 8 ou version ultérieure) et applications Blazor Server (.NET 7 ou version antérieure) s’exécutant sur IIS, y compris IIS avec des machines virtuelles (VM) Azure exécutant le système d’exploitation Windows et Azure App Service.
• Héberger et déployer ASP.NET Core Blazor WebAssembly avec IIS : applications autonomes Blazor WebAssembly (toutes les versions .NET) et applications hébergées Blazor WebAssembly (.NET 7 ou antérieures).
• Hébergement de sous-applications IIS
  • Suivez les instructions du chemin d’accès de base de l’application avant de publier l’application. Les exemples utilisent un chemin d’accès de base de l’application /CoolApp et montrent comment obtenir le chemin d’accès de base à partir des paramètres de l’application ou d’autres fournisseurs de configuration.
  • Suivez les conseils de configuration des sous-applications dans Configuration avancée. Le chemin d’accès au dossier de la sous-application sous le site racine devient le chemin d’accès virtuel de la sous-application. Pour un chemin d’accès de base de l’application /CoolApp, l’application Blazor est placée dans un dossier nommé CoolApp sous le site racine et la sous-application prend un chemin d’accès virtuel /CoolApp.

Le partage d’un pool d’applications entre des applications ASP.NET Core n’est pas pris en charge, y compris pour les applications Blazor. Utilisez un pool d’applications par application lors de l’hébergement avec IIS et évitez d’utiliser les répertoires virtuels d’IIS pour héberger plusieurs applications.

Support de l'outil de regroupement JavaScript

Le Blazor runtime s’appuie sur des fichiers JavaScript (JS), le runtime .NET compilé dans du code WebAssembly et les assemblys managés empaquetés en tant que fichiers WebAssembly. Lorsqu’une Blazor application est générée, le Blazor runtime dépend de ces fichiers à partir de différents emplacements de build. En raison de cette contrainte, Blazorla sortie de build n’est pas compatible avec JS les bundlers, tels que Gulp, Webpack et Rollup.

Pour produire une sortie de build compatible avec JS les bundlers lors de la publication, définissez la WasmBundlerFriendlyBootConfig propriété true MSBuild sur dans le fichier projet de l’application :

<WasmBundlerFriendlyBootConfig>true</WasmBundlerFriendlyBootConfig>

Important

Cette fonctionnalité produit uniquement la sortie conviviale du bundler lors de la publication de l’application.

La sortie n’est pas directement exécutable dans le navigateur, mais elle peut être consommée par JS des outils pour regrouper JS des fichiers avec le reste des scripts fournis par le développeur.

Lorsqu’il WasmBundlerFriendlyBootConfig est activé, le produit JS contient import des directives pour toutes les ressources de l’application, ce qui rend les dépendances visibles pour le bundler. La plupart des ressources ne peuvent pas être chargées par le navigateur, mais les bundlers peuvent généralement être configurés pour reconnaître les ressources par leur type de fichier pour gérer le chargement. Pour plus d’informations sur la configuration de votre bundler, reportez-vous à la documentation du bundler.

Remarque

Le regroupement de la sortie de build doit être possible en mappant des importations vers des emplacements de fichiers individuels à l’aide d’un JS plug-in personnalisé bundler. Nous ne fournissons pas ce plug-in pour le moment.

Remarque

En remplaçant le files plug-in urlpar , tous les fichiers de JS l’application, y compris le Blazorruntime -WebAssembly (encodé en base64 dans le JS), sont regroupés dans la sortie. La taille du fichier est beaucoup plus grande (par exemple, 300% plus grande) que lorsque les fichiers sont organisés avec le files plug-in. Nous vous déconseillons donc d’utiliser le url plug-in comme pratique générale lors de la production d’une sortie JS conviviale pour le traitement de bundler.

Les exemples d’applications suivants sont basés sur rollup. Les concepts similaires s’appliquent lors de l’utilisation d’autres JS bundlers.

Les exemples d’applications de démonstration pour Blazor WebAssembly une application React (BlazorWebAssemblyReact) et .NET sur WebAssembly dans une application React (DotNetWebAssemblyReact) pour .NET 10 ou version ultérieure sont disponibles dans les Blazor exemples de référentiel GitHub (dotnet/blazor-samples).

Les aspects de Blazor WebAssembly mise en cache s’appliquent à Blazor Web Apps

Blazor La mise en cache groupée et les conseils de mise en cache HTTP dans la Blazor WebAssembly section se concentrent sur les applications autonomes Blazor WebAssembly, mais plusieurs aspects de la mise en cache côté client dans ces articles s'appliquent également à Blazor Web App celles qui adoptent des modes de rendu WebAssembly interactif ou de rendu interactif automatique. Si un Blazor Web App qui rend le contenu côté client rencontre un problème de mise en cache de ressources statiques ou de paquets, consultez les instructions de ces articles pour résoudre le problème :

• Échecs de mise en cache et de vérification de l’intégrité dans ASP.NET Core Blazor WebAssembly
• Éviter les problèmes de mise en cache HTTP lors de la mise à niveau d’applications ASP.NET Core Blazor

Blazor Server Configuration MapFallbackToPage

Cette section s’applique uniquement aux applications Blazor Server. MapFallbackToPage n’est pas pris en charge dans les Blazor Web Apps et les applications Blazor WebAssembly.

Dans les scénarios où une application nécessite une zone distincte avec des ressources et des composants Razor personnalisés :

• Créez un dossier dans le dossier Pages de l’application pour y placer les ressources. Par exemple, une section d’administrateur d’une application est créée dans un nouveau dossier nommé Admin (Pages/Admin).

• Créez une page racine (_Host.cshtml) pour la zone. Par exemple, créez un fichier Pages/Admin/_Host.cshtml à partir de la page racine principale de l’application (Pages/_Host.cshtml). Ne fournissez pas de directive @page dans la page _Host d’administration.

• Ajoutez une disposition au dossier de la zone (par exemple, Pages/Admin/_Layout.razor). Dans la disposition de la zone distincte, définissez l’étiquette <base>href pour qu’elle corresponde au dossier de la zone (par exemple, <base href="/Admin/" />). À des fins de démonstration, ajoutez ~/ aux ressources statiques dans la page. Par exemple :

  • ~/css/bootstrap/bootstrap.min.css
  • ~/css/site.css
  • ~/BlazorSample.styles.css (L’espace de noms de l’exemple d’application est BlazorSample.)
  • ~/_framework/blazor.server.js (script Blazor)

• Si la zone doit avoir son propre dossier de ressources statiques, ajoutez le dossier et spécifiez son emplacement sur Middleware de fichiers statiques dans Program.cs (par exemple, app.UseStaticFiles("/Admin/wwwroot")).

• Les composants Razor sont ajoutés au dossier de la zone. Au minimum, ajoutez un composant Index au dossier de zone avec la directive @page correcte pour cette zone. Par exemple, ajoutez un fichier Pages/Admin/Index.razor en fonction du fichier Pages/Index.razor par défaut de l’application. Indiquez la zone Administration comme modèle de route en haut du fichier (@page "/admin"). Ajoutez des composants supplémentaires si nécessaire. Par exemple, Pages/Admin/Component1.razor avec une directive @page et un modèle de route @page "/admin/component1.

• Dans Program.cs, appelez MapFallbackToPage pour le chemin de demande de la zone immédiatement avant le chemin de la page racine de secours vers la page _Host :

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