Plusieurs applications hébergées ASP.NET Core Blazor WebAssembly

  • Article

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 dossier Client, MultipleBlazorApps.Server dans le dossier Server et MultipleBlazorApps.Shared dans le dossier Shared.
  • 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 de secondapp.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 dossier Client, MultipleBlazorApps.Server dans le dossier Server et MultipleBlazorApps.Shared dans le dossier Shared.
  • 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 projet MultipleBlazorApps.Server dans sa valeur de applicationUrl. 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 et secondapp.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 :

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 dossier Client/Pages vers le dossier SecondClient/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 composant FetchData 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 fichier weather.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 valeur SecondApp :

    <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 et admin.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 ou secondapp.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 exemple www.contoso.com pour les visiteurs du site et admin.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(); de Program.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 :

  • 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(); de Program.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 :

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 IndexRazor 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()
    {
        return View();
    }
}

using Microsoft.AspNetCore.Mvc;

namespace MultipleBlazorApps.Server.Controllers
{
    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            return 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 des composants Razor de l’une des applications clientes dans les pages ou les vues de l’application serveur, consultez Pre-afficher et intégrer les composants Razor ASP.NET Core.

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 sur https://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 sur https://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

Lorsque vous exécutez l’application avec la commande dotnet run (CLI .NET), 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 Prise en charge des pages et des 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’assembly ComponentLibrary :

    @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’assembly ComponentLibrary :

    <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" />

Ressources supplémentaires