Plusieurs applications hébergées ASP.NET Core Blazor WebAssembly
Remarque
Ceci n’est pas la dernière version de cet article. Pour la version la plus récente de cet article, consultez la version .NET 7.
Cet article explique comment configurer une application hébergée Blazor WebAssembly pour héberger plusieurs applications Blazor WebAssembly.
Configuration
Sélectionnez la version de cet article qui correspond à vos besoins d’hébergement, l’hébergement de port ou de domaine (par exemple, :5001
/:5002
ou firstapp.com
/secondapp.com
), ou l’hébergement de sous-chemin de routage (par exemple, /FirstApp
et /SecondApp
).
Avec la sélection actuelle de l’hébergement, cet article traite de l’hébergement de port ou de domaine (par exemple, :5001
/:5002
ou firstapp.com
/secondapp.com
).
Dans les exemples suivants :
- Le nom du projet de l’application hébergée Blazor WebAssembly est
MultipleBlazorApps
dans un dossier nomméMultipleBlazorApps
. - Les trois projets de la solution avant l’ajout d’une deuxième application cliente sont
MultipleBlazorApps.Client
dans le dossierClient
,MultipleBlazorApps.Server
dans le dossierServer
etMultipleBlazorApps.Shared
dans le dossierShared
. - La (première) application cliente initiale est le projet client par défaut de la solution créée à partir du modèle de projet Blazor WebAssembly.
- Une deuxième application cliente est ajoutée à la solution,
MultipleBlazorApps.SecondClient
dans un dossier nomméSecondClient
. - Si vous le souhaitez, le projet serveur (
MultipleBlazorApps.Server
) peut délivrer des pages ou des vues en tant qu’application Pages ou MVC Razor. - La première application cliente est accessible dans un navigateur au port 5001 ou avec un hôte de
firstapp.com
. La deuxième application cliente est accessible dans un navigateur au port 5002 ou avec un hôte desecondapp.com
.
Avec la sélection actuelle, cet article traite du routage de l’hébergement sous-tracé (par exemple, /FirstApp
et /SecondApp
).
Dans les exemples suivants :
- Le nom du projet de l’application hébergée Blazor WebAssembly est
MultipleBlazorApps
dans un dossier nomméMultipleBlazorApps
. - Les trois projets de la solution avant l’ajout d’une deuxième application cliente sont
MultipleBlazorApps.Client
dans le dossierClient
,MultipleBlazorApps.Server
dans le dossierServer
etMultipleBlazorApps.Shared
dans le dossierShared
. - La (première) application cliente initiale est le projet client par défaut de la solution créée à partir du modèle de projet Blazor WebAssembly.
- Une deuxième application cliente est ajoutée à la solution,
MultipleBlazorApps.SecondClient
dans un dossier nomméSecondClient
. - Si vous le souhaitez, le projet serveur (
MultipleBlazorApps.Server
) peut délivrer des pages ou des vues en tant qu’application Pages ou MVC formelle Razor. - Les deux applications clientes utilisent le port par défaut défini par le fichier
Properties/launchSettings.json
du projetMultipleBlazorApps.Server
dans sa valeur deapplicationUrl
. La première application cliente est accessible dans un navigateur dans le sous-tracé/FirstApp
. La seconde application cliente est accessible dans un navigateur dans le sous-tracé/SecondApp
.
Les exemples présentés dans cet article nécessitent une configuration supplémentaire pour :
- L’accès aux applications directement sur les exemples de domaines hôtes,
firstapp.com
etsecondapp.com
. - Les certificats pour les applications clientes pour activer la sécurité TLS/HTTPS.
- La configuration de l’application serveur en tant qu’application Pages Razor pour les fonctionnalités suivantes :
- L’intégration de composants Razor dans des pages ou des vues.
- Composants Razor de pré-affichage.
Les configurations précédentes dépassent l’étendue de cet article. Pour plus d'informations, reportez-vous aux ressources suivantes :
- Articles sur l’hôte et le déploiement
- Appliquer HTTPS dans ASP.NET Core
- Intégrer ASP.NET composants Core Razor à MVC ou Razor Pages dans des solutions hébergées Blazor WebAssembly
Utilisez une Blazor WebAssemblysolution hébergée existante ou créez une nouvelle solution Blazor WebAssembly hébergée depuis le modèle de projet Blazor WebAssembly en transmettant l’option -ho|--hosted
si vous utilisez l’interface de ligne de commande .NET ou en cochant la case ASP.NET Core hébergé dans Visual Studio ou Visual Studio pour Mac lorsque le projet est créé dans l’IDE.
Utilisez un dossier pour la solution nommé MultipleBlazorApps
et nommez le projet MultipleBlazorApps
.
Créez un dossier dans la solution nommé SecondClient
. Dans le nouveau dossier, ajoutez une deuxième application cliente Blazor WebAssembly nommée MultipleBlazorApps.SecondClient
. Ajoutez le projet en tant qu’application autonome Blazor WebAssembly. Pour créer une application autonome Blazor WebAssembly, ne transmettez pas l’option -ho|--hosted
si vous utilisez l’interface de ligne de commande .NET ou si vous n’utilisez pas la case à cocher Hébergé sur ASP.NET Core si vous utilisez Visual Studio.
Appliquez les modifications suivantes au projet MultipleBlazorApps.SecondClient
:
- Copiez le composant
FetchData
(Pages/FetchData.razor
) du dossierClient/Pages
vers le dossierSecondClient/Pages
. Cette étape est requise, car une application Blazor WebAssembly autonome n’appelle pas le contrôleur d’un projet Server pour les données météorologiques. Elle utilise un fichier de données statiques. En copiant le composantFetchData
dans le projet ajouté, la deuxième application cliente effectue également un appel d’API web à l’API serveur pour les données météorologiques. - Supprimez le dossier
SecondClient/wwwroot/sample-data
, car le fichierweather.json
dans le dossier n’est pas utilisé.
Le tableau suivant décrit les dossiers et les noms de projet de la solution après l’ajout du dossier SecondClient
et du projet MultipleBlazorApps.SecondClient
.
Dossier physique | Nom du projet | Description |
---|---|---|
Client |
MultipleBlazorApps.Client |
Application cliente Blazor WebAssembly |
SecondClient |
MultipleBlazorApps.SecondClient |
Application cliente Blazor WebAssembly |
Server |
MultipleBlazorApps.Server |
Application serveur ASP .NET Core |
Shared |
MultipleBlazorApps.Shared |
Projet de ressources partagées |
Le projet MultipleBlazorApps.Server
sert les deux applications clientes Blazor WebAssembly et fournit des données météorologiques aux composants FetchData
des applications clientes via un contrôleur MVC. Si vous le souhaitez, le projet Razor peut également délivrer des pages ou des vues, en tant qu’application Pages ou MVC MultipleBlazorApps.Server
traditionnelle. Les étapes permettant d’activer le traitement de pages ou de vues sont abordées plus loin dans cet article.
Remarque
La démonstration de cet article utilise des noms de chemins d’accès de ressources web statiques de FirstApp
pour le projet MultipleBlazorApps.Client
et de SecondApp
pour le projet MultipleBlazorApps.SecondClient
. Les noms « FirstApp
» et « SecondApp
» ne sont utilisés qu’à des fins de démonstration. D’autres noms sont acceptables pour distinguer les applications clientes, tels que App1
/App2
, Client1
/Client2
, 1
/2
, ou tout schéma de nommage similaire.
Lors du routage des demandes vers les applications clientes par un port ou un domaine, « FirstApp
» et « SecondApp
» sont utilisés en interne pour acheminer les requêtes et traiter les réponses pour les ressources statiques et ne sont pas visibles dans la barre d’adresses du navigateur.
Remarque
La démonstration de cet article utilise des noms de chemins d’accès de ressources web statiques de FirstApp
pour le projet MultipleBlazorApps.Client
et de SecondApp
pour le projet MultipleBlazorApps.SecondClient
. Les noms « FirstApp
» et « SecondApp
» ne sont utilisés qu’à des fins de démonstration. D’autres noms sont acceptables pour distinguer les applications clientes, tels que App1
/App2
, Client1
/Client2
, 1
/2
, ou tout schéma de nommage similaire.
« FirstApp
» et « SecondApp
» apparaissent également dans la barre d’adresses du navigateur, car les requêtes sont acheminées vers les deux applications clientes à l’aide de ces noms. D’autres segments d’itinéraire d’URL valides sont pris en charge et les segments de routage n’ont pas strictement besoin de correspondre aux noms utilisés pour router les ressources web statiques en interne. L’utilisation de « FirstApp
» et de « SecondApp
» pour le routage des ressources statiques internes ainsi que le routage des demandes d’application est simplement destinée aux exemples de cet article.
Dans le premier fichier projet de l’application cliente (MultipleBlazorApps.Client.csproj
), ajoutez une propriété <StaticWebAssetBasePath>
à un <PropertyGroup>
avec la valeur de FirstApp
pour définir le chemin d’accès de base des ressources statiques du projet :
<StaticWebAssetBasePath>FirstApp</StaticWebAssetBasePath>
Dans le Fichier projet de l’application MultipleBlazorApps.SecondClient
(MultipleBlazorApps.SecondClient.csproj
) :
Ajoutez une propriété
<StaticWebAssetBasePath>
à un<PropertyGroup>
avec la valeurSecondApp
:<StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
Ajoutez une référence de projet pour le projet
MultipleBlazorApps.Shared
à un<ItemGroup>
:<ItemGroup> <ProjectReference Include="..\Shared\MultipleBlazorApps.Shared.csproj" /> </ItemGroup>
Dans le Fichier projet de l’application serveur (Server/MultipleBlazorApps.Server.csproj
), créez une référence de projet pour l’application cliente MultipleBlazorApps.SecondClient
ajoutée dans un <ItemGroup>
:
<ProjectReference Include="..\SecondClient\MultipleBlazorApps.SecondClient.csproj" />
Dans le fichier Properties/launchSettings.json
de l’application serveur, configurez le applicationUrl
du profil Kestrel (MultipleBlazorApps.Server
) pour accéder aux applications clientes sur les ports 5001 et 5002. Si vous configurez votre environnement local pour qu’il utilise les exemples de domaines, les URL pour applicationUrl
peuvent utiliser firstapp.com
et secondapp.com
et ne pas utiliser les ports.
Remarque
L’utilisation de ports dans cette démonstration permet d’accéder aux projets clients dans un navigateur local sans devoir configurer un environnement d’hébergement local afin que les navigateurs web puissent accéder aux applications clientes via les configurations hôtes, firstapp.com
et secondapp.com
. Dans les scénarios de production, une configuration classique consiste à utiliser des sous-domaines pour distinguer les applications clientes.
Exemple :
- Les ports sont supprimés de la configuration de cette démonstration.
- Les hôtes sont modifiés pour utiliser des sous-domaines, par exemple
www.contoso.com
pour les visiteurs du site etadmin.contoso.com
pour les administrateurs. - Des hôtes supplémentaires peuvent être inclus pour des applications clientes supplémentaires, et au moins un hôte supplémentaire est requis si l’application serveur est également une application Pages ou MVC Razor qui fournit des pages ou des vues.
Si vous envisagez de délivrer des pages ou des vues à partir de l’application serveur, utilisez le paramètre suivant applicationUrl
dans le fichier Properties/launchSettings.json
, qui autorise l’accès suivant :
- Si vous le souhaitez, l’application Pages ou MVC Razor (projet
MultipleBlazorApps.Server
) répond aux requêtes sur le port 5000. - Les réponses aux requêtes pour le premier client (projet
MultipleBlazorApps.Client
) se trouvent sur le port 5001. - Les réponses aux requêtes pour le deuxième client (projet
MultipleBlazorApps.SecondClient
) sont sur le port 5002.
"applicationUrl": "https://localhost:5000;https://localhost:5001;https://localhost:5002",
Si vous ne prévoyez pas que l’application serveur délivre des pages ou des vues et qu’elle délivre uniquement les applications clientes Blazor WebAssembly, utilisez le paramètre suivant, qui autorise l’accès suivant :
- La première application cliente répond sur le port 5001.
- La deuxième application cliente répond sur le port 5002.
"applicationUrl": "https://localhost:5001;https://localhost:5002",
Dans le fichier Program.cs
de l’application serveur, supprimez le code suivant, qui s’affiche après l’appel à UseHttpsRedirection :
Si vous envisagez de délivrer des pages ou des vues à partir de l’application serveur, supprimez les lignes de code suivantes :
- app.UseBlazorFrameworkFiles();
- app.MapFallbackToFile("index.html");
Si vous envisagez que l’application serveur fournisse uniquement des services aux applications clientes Blazor WebAssembly, supprimez le code suivant :
- app.UseBlazorFrameworkFiles(); ... - app.UseRouting(); - app.MapRazorPages(); - app.MapControllers(); - app.MapFallbackToFile("index.html");
Laissez l’intergiciel de fichiers statiques à sa place :
app.UseStaticFiles();
Ajoutez un intergiciel qui mappe les requêtes aux applications clientes. L’exemple suivant configure l’intergiciel pour qu’il s’exécute lorsque le port de requête est 5001 pour la première application cliente, ou 5002 pour la deuxième application cliente, ou que l’hôte de requête est
firstapp.com
pour la première application cliente ousecondapp.com
pour la deuxième application cliente.Remarque
L’utilisation des hôtes (
firstapp.com
/secondapp.com
) sur un système local avec un navigateur local nécessite une configuration supplémentaire qui dépasse le cadre de cet article. Pour les tests locaux de ce scénario, nous vous recommandons d’utiliser des ports. Les applications de production classiques sont configurées pour utiliser des sous-domaines, par exemplewww.contoso.com
pour les visiteurs du site etadmin.contoso.com
pour les administrateurs. Avec la configuration DNS et serveur appropriée, qui dépasse le cadre de cet article et dépend des technologies utilisées, l’application répond aux requêtes à tous les hôtes nommés dans le code suivant.Là où vous avez supprimé la ligne
app.UseBlazorFrameworkFiles();
deProgram.cs
, placez le code suivant :app.MapWhen(ctx => ctx.Request.Host.Port == 5001 || ctx.Request.Host.Equals("firstapp.com"), first => { first.Use((ctx, nxt) => { ctx.Request.Path = "/FirstApp" + ctx.Request.Path; return nxt(); }); first.UseBlazorFrameworkFiles("/FirstApp"); first.UseStaticFiles(); first.UseStaticFiles("/FirstApp"); first.UseRouting(); first.UseEndpoints(endpoints => { endpoints.MapControllers(); endpoints.MapFallbackToFile("/FirstApp/{*path:nonfile}", "FirstApp/index.html"); }); }); app.MapWhen(ctx => ctx.Request.Host.Port == 5002 || ctx.Request.Host.Equals("secondapp.com"), second => { second.Use((ctx, nxt) => { ctx.Request.Path = "/SecondApp" + ctx.Request.Path; return nxt(); }); second.UseBlazorFrameworkFiles("/SecondApp"); second.UseStaticFiles(); second.UseStaticFiles("/SecondApp"); second.UseRouting(); second.UseEndpoints(endpoints => { endpoints.MapControllers(); endpoints.MapFallbackToFile("/SecondApp/{*path:nonfile}", "SecondApp/index.html"); }); });
Warning
L’API qui s’appuie sur l’en-tête d’hôte, comme HttpRequest.Host et RequireHost, est soumise à une usurpation potentielle par les clients.
Pour éviter l’usurpation d’hôte ou de port, utilisez l’une des approches suivantes :
- Utilisez HttpContext.Connection (ConnectionInfo.LocalPort) où les ports sont vérifiés.
- Utilisez le filtrage d’hôtes.
Ajoutez un intergiciel qui mappe les requêtes aux applications clientes. L’exemple suivant configure l’intergiciel pour qu’il s’exécute lorsque le sous-chemin de requête est
/FirstApp
pour la première application cliente ou/SecondApp
pour la deuxième application cliente.Là où vous avez supprimé la ligne
app.UseBlazorFrameworkFiles();
deProgram.cs
, placez le code suivant :app.MapWhen(ctx => ctx.Request.Path.StartsWithSegments("/FirstApp", StringComparison.OrdinalIgnoreCase), first => { first.UseBlazorFrameworkFiles("/FirstApp"); first.UseStaticFiles(); first.UseStaticFiles("/FirstApp"); first.UseRouting(); first.UseEndpoints(endpoints => { endpoints.MapControllers(); endpoints.MapFallbackToFile("/FirstApp/{*path:nonfile}", "FirstApp/index.html"); }); }); app.MapWhen(ctx => ctx.Request.Path.StartsWithSegments("/SecondApp", StringComparison.OrdinalIgnoreCase), second => { second.UseBlazorFrameworkFiles("/SecondApp"); second.UseStaticFiles(); second.UseStaticFiles("/SecondApp"); second.UseRouting(); second.UseEndpoints(endpoints => { endpoints.MapControllers(); endpoints.MapFallbackToFile("/SecondApp/{*path:nonfile}", "SecondApp/index.html"); }); });
Définissez le chemin d’accès de base dans chaque application cliente :
Dans le premier fichier
index.html
de l’application cliente (Client/wwwroot/index.html
), mettez à jour la valeur de balise<base>
pour qu’elle reflète le sous-chemin. La barre oblique de fin est requise :<base href="/FirstApp/" />
Dans le deuxième fichier
index.html
de l’application cliente (SecondClient/wwwroot/index.html
), mettez à jour la valeur de balise<base>
pour qu’elle reflète le sous-chemin. La barre oblique de fin est requise :<base href="/SecondApp/" />
Pour plus d’informations sur UseStaticFiles, consultez Fichiers statiques Blazor ASP.NET Core.
Pour plus d’informations sur UseBlazorFrameworkFiles
et MapFallbackToFile
, consultez les ressources suivantes :
- Microsoft.AspNetCore.Builder.ComponentsWebAssemblyApplicationBuilderExtensions.UseBlazorFrameworkFiles (source de référence)
- Microsoft.AspNetCore.Builder.StaticFilesEndpointRouteBuilderExtensions.MapFallbackToFile (source de référence)
Remarque
Les liens de documentation vers la source de référence .NET chargent généralement la branche par défaut du référentiel, qui représente le développement actuel pour la prochaine version de .NET. Pour sélectionner une balise pour une version spécifique, utilisez la liste déroulante Échanger les branches ou les balises. Pour plus d’informations, consultez Comment sélectionner une balise de version du code source ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Les demandes des applications clientes à /WeatherForecast
dans l’API serveur sont soit pour /FirstApp/WeatherForecast
, soit pour /SecondApp/WeatherForecast
, en fonction de l’application cliente qui effectue la requête. Par conséquent, les routes du contrôleur qui renvoient les données météorologiques de l’API serveur nécessitent d’être modifiées pour inclure les segment de tracé.
Dans le contrôleur de prévisions météorologiques de l’application serveur (Controllers/WeatherForecastController.cs
), remplacez la route existante ([Route("[controller]")]
) vers WeatherForecastController
par les routes suivantes, qui prennent en compte les chemins de demande du client.
[Route("FirstApp/[controller]")]
[Route("SecondApp/[controller]")]
Si vous envisagez de délivrer des pages à partir de l’application serveur, ajoutez une page Index
Razor au dossier Pages
de l’application serveur :
Pages/Index.cshtml
:
@page
@model MultipleBlazorApps.Server.Pages.IndexModel
@{
ViewData["Title"] = "Home";
}
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Home</title>
</head>
<body>
<div class="main">
<div class="content px-4">
<div>
<h1>Welcome</h1>
<p>Hello from Razor Pages!</p>
</div>
</div>
</div>
</body>
</html>
Pages/Index.cshtml.cs
:
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;
namespace MultipleBlazorApps.Server.Pages;
public class IndexModel : PageModel
{
public void OnGet()
{
}
}
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;
namespace MultipleBlazorApps.Server.Pages
{
public class IndexModel : PageModel
{
public void OnGet()
{
}
}
}
Remarque
La page précédente Index
est un exemple minimal uniquement utilisé à des fins de démonstration. Si l’application nécessite des ressources Pages supplémentaires Razor, telles qu’une disposition, des styles, des scripts et des importations, obtenez-les à partir d’une application créée à partir du modèle de projet Pages Razor. Pour plus d’informations, consultez Introduction aux Razor Pages dans ASP.NET Core.
Si vous envisagez de délivrer des vues MVC à partir de l’application serveur, ajoutez une vue Index
et un contrôleur Home
:
Views/Home/Index.cshtml
:
@{
ViewData["Title"] = "Home";
}
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Home</title>
</head>
<body>
<div class="main">
<div class="content px-4">
<div>
<h1>Welcome</h1>
<p>Hello from MVC!</p>
</div>
</div>
</div>
</body>
</html>
Controllers/HomeController.cs
:
using Microsoft.AspNetCore.Mvc;
namespace MultipleBlazorApps.Server.Controllers;
public class HomeController : Controller
{
public IActionResult Index() => View();
}
Remarque
La vue précédente Index
est un exemple minimal uniquement utilisé à des fins de démonstration. Si l’application nécessite des ressources MVC supplémentaires, telles qu’une disposition, des styles, des scripts et des importations, obtenez-les à partir d’une application créée à partir du modèle de projet MVC. Pour plus d’informations, consultez Prise en main de ASP.NET Core MVC.
Pour plus d’informations sur l’utilisation Razor des composants de l’une des applications clientes dans des pages ou des vues de l’application serveur, consultez Intégrer ASP.NET composants Core Razor avec MVC ou Razor Pages dans des solutions hébergéesBlazor WebAssembly.
Exécuter l’application
Exécutez le projet MultipleBlazorApps.Server
:
- Accédez à l’application cliente initiale à
https://localhost:5001
. - Accédez à l’application cliente ajoutée à
https://localhost:5002
. - Si l’application serveur est configurée pour délivrer des pages ou des vues, accédez à la page
Index
ou à l’affichage surhttps://localhost:5000
.
- Accédez à l’application cliente initiale à
https://localhost:{DEFAULT PORT}/FirstApp
. - Accédez à l’application cliente ajoutée à
https://localhost:{DEFAULT PORT}/SecondApp
. - Si l’application serveur est configurée pour délivrer des pages ou des vues, accédez à la page
Index
ou à l’affichage surhttps://localhost:{DEFAULT PORT}
.
Dans l’exemple d’URL précédent, l’espace réservé {DEFAULT PORT}
est le port par défaut défini par le fichier Properties/launchSettings.json
du projet MultipleBlazorApps.Server
dans sa valeur de applicationUrl
.
Important
Lors de l’exécution de l’application avec la commande dotnet watch
(ou dotnet run
) (.NET CLI), vérifiez que l’interpréteur de commandes est ouvert dans le dossier Server
de la solution.
Lorsque vous utilisez le bouton Démarrer de Visual Studio pour exécuter l’application, vérifiez que le projet MultipleBlazorApps.Server
est défini comme projet de démarrage (mis en surbrillance dans l’explorateur de solutions).
Les ressources statiques
Lorsqu’une ressource se trouve dans le dossier wwwroot
d’une application cliente, fournissez le chemin d’accès de la requête de la ressource statique dans les composants :
<img alt="..." src="{PATH AND FILE NAME}" />
L’espace réservé {PATH AND FILE NAME}
correspond au chemin et au nom de fichier sous wwwroot
.
Par exemple, la source d’une image Jeep (jeep-yj.png
) dans le dossier vehicle
de wwwroot
:
<img alt="Jeep Wrangler YJ" src="vehicle/jeep-yj.png" />
Prise en charge de la bibliothèque de classes Razor (RCL)
Ajoutez la bibliothèque de classes Razor (RCL) à la solution en tant que nouveau projet :
- Cliquez avec le bouton droit sur la solution dans l’Explorateur de solutions, puis sélectionnez Ajouter>Nouveau projet.
- Utilisez le modèle de projet Razor Bibliothèque de classes pour créer le projet. Les exemples de cette section utilisent le nom du projet
ComponentLibrary
, qui est également le nom de l’assembly RCL. Ne cochez pas la case Prendre en charge les pages et les vues.
Pour chaque application cliente hébergée Blazor WebAssembly, créez une référence de projet pour le projet RCL en faisant un clic droit sur chaque projet client dans Explorateur de solutions et en sélectionnant Ajouter>Référence de projet.
Utilisez des composants de la RCL dans les applications clientes avec l’une des approches suivantes :
Placez une directive
@using
en haut du composant pour l’espace de noms RCL et ajoutez la syntaxe Razor du composant. L’exemple suivant est destiné à une RCL avec le nom de l’assemblyComponentLibrary
:@using ComponentLibrary ... <Component1 />
Fournissez l’espace de noms de la RCL, ainsi que la syntaxe Razor du composant. Cette approche ne nécessite pas de directive
@using
en haut du fichier de composant. L’exemple suivant est destiné à une RCL avec le nom de l’assemblyComponentLibrary
:<ComponentLibrary.Component1 />
Remarque
Une directive @using
peut également être placée dans le fichier _Import.razor
de chaque application cliente, ce qui rend l’espace de noms RCL globalement disponible pour les composants dans ce projet.
Quand une autre ressource statique se trouve dans le dossier wwwroot
d’une RCL, référencez la ressource statique dans une application cliente conformément aux instructions de l’interface utilisateur Réutilisable Razor dans les bibliothèques de classes avec ASP.NET Core :
<img alt="..." src="_content/{PACKAGE ID}/{PATH AND FILE NAME}" />
L’espace réservé {PACKAGE ID}
correspond à l’ID du package de la RCL. L’ID de package est défini par défaut sur le nom d’assembly du projet si <PackageId>
n’est pas spécifié dans le fichier projet. L’espace réservé {PATH AND FILE NAME}
correspond au chemin d’accès et au nom de fichier sous wwwroot
.
L’exemple suivant montre le balisage d’une image Jeep (jeep-yj.png
) dans le dossier vehicle
du dossier wwwroot
RCL. L’exemple suivant est destiné à une RCL avec le nom de l’assembly ComponentLibrary
:
<img alt="Jeep Wrangler YJ" src="_content/ComponentLibrary/vehicle/jeep-yj.png" />