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

Note

Ceci n’est pas la dernière version de cet article. Pour obtenir la dernière version de cet article, consultez la version .NET 7.

Cet article explique comment configurer une application hébergée Blazor WebAssembly pour héberger plusieurs Blazor WebAssembly applications.

Paramétrage

Sélectionnez la version de cet article qui correspond à vos besoins d’hébergement, soit l’hébergement de port/domaine (par exemple, :5001/:5002 soitfirstapp.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/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 se trouve MultipleBlazorApps dans un dossier nommé MultipleBlazorApps.
Les trois projets de la solution avant l’ajout d’une deuxième application cliente se trouvent MultipleBlazorApps.Client dans le Client dossier, MultipleBlazorApps.Server dans le Server dossier et MultipleBlazorApps.Shared dans le Shared dossier.
L’application cliente initiale (première) est le projet client par défaut de la solution créée à partir du Blazor WebAssembly modèle de projet.
Une deuxième application cliente est ajoutée à la solution, MultipleBlazorApps.SecondClient dans un dossier nommé SecondClient.
Si vous le souhaitez, le projet de serveur (MultipleBlazorApps.Server) peut servir de pages ou de vues en tant qu’application Razor Pages ou MVC.
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 de l’hébergement de sous-chemin d’itinéraire (par exemple, /FirstApp et /SecondApp).

Dans les exemples suivants :

Le nom du projet de l’application hébergée Blazor WebAssembly se trouve MultipleBlazorApps dans un dossier nommé MultipleBlazorApps.
Les trois projets de la solution avant l’ajout d’une deuxième application cliente se trouvent MultipleBlazorApps.Client dans le Client dossier, MultipleBlazorApps.Server dans le Server dossier et MultipleBlazorApps.Shared dans le Shared dossier.
L’application cliente initiale (première) est le projet client par défaut de la solution créée à partir du Blazor WebAssembly modèle de projet.
Une deuxième application cliente est ajoutée à la solution, MultipleBlazorApps.SecondClient dans un dossier nommé SecondClient.
Si vous le souhaitez, le projet de serveur (MultipleBlazorApps.Server) peut servir de pages ou de vues en tant qu’application Pages ou MVC formelle Razor .
Les deux applications clientes utilisent le port par défaut défini par le MultipleBlazorApps.Server fichier du Properties/launchSettings.json projet dans sa applicationUrl valeur. La première application cliente est accessible dans un navigateur sur le /FirstApp sous-chemin. La deuxième application cliente est accessible dans un navigateur sur le /SecondApp sous-chemin.

Les exemples présentés dans cet article nécessitent une configuration supplémentaire pour :

Accès aux applications directement sur les exemples de domaines hôtes et firstapp.comsecondapp.com.
Certificats pour les applications clientes afin d’activer la sécurité TLS/HTTPS.
Configuration de l’application serveur en tant qu’application Razor Pages pour les fonctionnalités suivantes :
- Intégration de Razor composants dans des pages ou des vues.
- Composants de pré-endering Razor .

Les configurations précédentes dépassent la portée de cet article. Pour plus d’informations, consultez les ressources suivantes :

Utilisez une Blazor WebAssembly hébergée existante ou créez une solution hébergée Blazor WebAssembly à partir du Blazor WebAssembly modèle de projet en transmettant l’option -ho|--hosted si vous utilisez l’interface CLI .NET ou cochez la case ASP.NET Core Hosted dans Visual Studio lorsque le projet est créé dans l’IDE.

Utilisez un dossier pour la solution nommée MultipleBlazorApps et nommez le projet MultipleBlazorApps.

Créez un dossier dans la solution nommée SecondClient. Dans le nouveau dossier, ajoutez une deuxième Blazor WebAssembly application cliente nommée MultipleBlazorApps.SecondClient. Ajoutez le projet en tant qu’application autonome Blazor WebAssembly . Pour créer une application autonome Blazor WebAssembly , ne passez pas l’option -ho|--hosted si vous utilisez l’interface CLI .NET ou si vous n’utilisez pas la case ASP.NET Core Hosted si vous utilisez Visual Studio.

Apportez les modifications suivantes au MultipleBlazorApps.SecondClient projet :

Copiez le FetchData composant (Pages/FetchData.razor) du Client/Pages dossier vers le SecondClient/Pages dossier. Cette étape est requise, car une application autonome Blazor WebAssembly n’appelle pas le contrôleur d’un Server projet pour les données météorologiques, elle utilise un fichier de données statiques. En copiant le FetchData composant dans le projet ajouté, la deuxième application cliente effectue également un appel d’API web vers l’API serveur pour les données météorologiques.
Supprimez le SecondClient/wwwroot/sample-data dossier, car le weather.json fichier du 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 et SecondClient du MultipleBlazorApps.SecondClient projet.

Dossier physique	Nom du projet	Descriptif
`Client`	`MultipleBlazorApps.Client`	Blazor WebAssembly application cliente
`SecondClient`	`MultipleBlazorApps.SecondClient`	Blazor WebAssembly application cliente
`Server`	`MultipleBlazorApps.Server`	application serveur ASP.NET Core
`Shared`	`MultipleBlazorApps.Shared`	Projet de ressources partagées

Le MultipleBlazorApps.Server projet sert les deux Blazor WebAssembly applications clientes et fournit des données météorologiques aux composants des FetchData applications clientes via un contrôleur MVC. Si vous le souhaitez, le MultipleBlazorApps.Server projet peut également servir de pages ou de vues, en tant qu’application Pages ou MVC traditionnelle Razor . Les étapes permettant d’activer le service de pages ou de vues sont abordées plus loin dans cet article.

Note

La démonstration de cet article utilise les noms de chemins d’accès des ressources web statiques du FirstAppMultipleBlazorApps.Client projet et SecondApp du MultipleBlazorApps.SecondClient projet. Les noms «FirstApp » et «SecondApp » sont simplement à des fins de démonstration. D’autres noms sont acceptables pour distinguer les applications clientes, telles que App1/App2,Client1/Client2 ou 1/2tout 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 router les requêtes et traiter les réponses pour les ressources statiques et ne sont pas visibles dans la barre d’adresses du navigateur.

Note

«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 et 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 <StaticWebAssetBasePath> propriété à une <PropertyGroup> valeur de définir le chemin d’accès de FirstApp base pour les ressources statiques du projet :

<StaticWebAssetBasePath>FirstApp</StaticWebAssetBasePath>

Dans le fichier projet de l’application MultipleBlazorApps.SecondClient (MultipleBlazorApps.SecondClient.csproj) :

Ajoutez une <StaticWebAssetBasePath> propriété à une <PropertyGroup> valeur de SecondApp:
```
<StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
```

Ajoutez une référence de projet pour le MultipleBlazorApps.Shared projet à 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 ajoutée MultipleBlazorApps.SecondClient dans un <ItemGroup>:

<ProjectReference Include="..\SecondClient\MultipleBlazorApps.SecondClient.csproj" />

Dans le fichier de Properties/launchSettings.json l’application serveur, configurez le applicationUrlKestrel profil (MultipleBlazorApps.Server) pour accéder aux applications clientes aux ports 5001 et 5002. Si vous configurez votre environnement local pour utiliser les exemples de domaines, les URL pour applicationUrl lesquelles vous pouvez utiliser firstapp.com et secondapp.com ne pas utiliser les ports.

Note

L’utilisation de ports dans cette démonstration permet d’accéder aux projets clients dans un navigateur local sans avoir à configurer un environnement d’hébergement local afin que les navigateurs web puissent accéder aux applications clientes via les configurations d’hôte et firstapp.comsecondapp.com. Dans les scénarios de production, une configuration classique consiste à utiliser des sous-domaines pour distinguer les applications clientes.

Par exemple:

Les ports sont supprimés de la configuration de cette démonstration.
Les hôtes sont modifiés pour utiliser des sous-domaines, tels que 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 autre hôte est nécessaire si l’application serveur est également une Razor application Pages ou MVC qui fournit des pages ou des vues.

Si vous envisagez de servir des pages ou des vues à partir de l’application serveur, utilisez le paramètre suivant applicationUrl dans le Properties/launchSettings.json fichier, ce qui permet l’accès suivant :

Si vous le souhaitez, les Razor pages ou l’application MVC (MultipleBlazorApps.Server projet) répondent aux demandes au port 5000.
Les réponses aux demandes du premier client (MultipleBlazorApps.Client projet) sont au port 5001.
Les réponses aux demandes du deuxième client (MultipleBlazorApps.SecondClient projet) sont au port 5002.

"applicationUrl": "https://localhost:5000;https://localhost:5001;https://localhost:5002",

Si vous ne prévoyez pas que l’application serveur serve des pages ou des vues et que vous ne servez que les Blazor WebAssembly applications clientes, utilisez le paramètre suivant, ce qui permet 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 de Program.cs l’application serveur, supprimez le code suivant, qui apparaît après l’appel à UseHttpsRedirection:

Si vous envisagez de servir des pages ou des vues de l’application serveur, supprimez les lignes de code suivantes :
```
- app.UseBlazorFrameworkFiles();
```
```
- app.MapFallbackToFile("index.html");
```
Si vous envisagez que l’application serveur serve uniquement les Blazor WebAssembly applications clientes, supprimez le code suivant :
```
- app.UseBlazorFrameworkFiles();

...

- app.UseRouting();

- app.MapRazorPages();
- app.MapControllers();
- app.MapFallbackToFile("index.html");
```
Laissez le middleware de fichier statique en 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.

Note

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 la portée 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, tels que 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 la portée de cet article et dépend des technologies utilisées, l’application répond aux demandes sur les hôtes nommés dans le code suivant.

Où vous avez supprimé la app.UseBlazorFrameworkFiles(); ligne Program.csde , 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");
    });
});
```
Avertissement

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.

Où vous avez supprimé la app.UseBlazorFrameworkFiles(); ligne Program.csde , 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 de l’application cliente (index.html), mettez à jour la valeur de Client/wwwroot/index.html balise <base> pour refléter le sous-chemin. La barre oblique de fin est requise :
```
<base href="/FirstApp/" />
```
Dans le fichier de la deuxième application cliente (index.html), mettez à jour la valeur de SecondClient/wwwroot/index.html balise <base> pour refléter le sous-chemin. La barre oblique de fin est requise :
```
<base href="/SecondApp/" />
```

Pour plus d’informations sur UseStaticFiles, consultez ASP.NET fichiers statiques CoreBlazor.

Pour plus d’informations sur et UseBlazorFrameworkFilespour plus d’informationsMapFallbackToFile, consultez les ressources suivantes :

Note

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 vers /WeatherForecast l’API serveur sont à /FirstApp/WeatherForecast ou /SecondApp/WeatherForecast selon l’application cliente qui effectue la requête. Par conséquent, les itinéraires du contrôleur qui retournent des données météorologiques à partir de l’API serveur nécessitent une modification pour inclure les segments de chemin d’accès.

Dans le contrôleur de prévision météorologique de l’application serveur (Controllers/WeatherForecastController.cs), remplacez l’itinéraire existant ([Route("[controller]")]) par WeatherForecastController les itinéraires suivants, qui prennent en compte les chemins de requête du client :

[Route("FirstApp/[controller]")]
[Route("SecondApp/[controller]")]

Si vous envisagez de servir des pages à partir de l’application serveur, ajoutez une IndexRazor page au Pages dossier 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()
        {
        }
    }
}

Note

La page précédente Index est un exemple minimal uniquement à 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 Razor modèle de projet Pages. Pour plus d’informations, consultez Razor l’architecture et les concepts des pages dans ASP.NET Core.

Si vous envisagez de servir des vues MVC à partir de l’application serveur, ajoutez une Index vue et un Home contrôleur :

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

Note

L’affichage précédent Index est un exemple minimal uniquement à 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 MultipleBlazorApps.Server projet :

Accédez à l’application cliente initiale à l’adresse https://localhost:5001.
Accédez à l’application cliente ajoutée à l’adresse https://localhost:5002.
Si l’application serveur est configurée pour servir des pages ou des vues, accédez à la page ou à l’affichage à l’adresse Indexhttps://localhost:5000.

Accédez à l’application cliente initiale à l’adresse https://localhost:{DEFAULT PORT}/FirstApp.
Accédez à l’application cliente ajoutée à l’adresse https://localhost:{DEFAULT PORT}/SecondApp.
Si l’application serveur est configurée pour servir des pages ou des vues, accédez à la page ou à l’affichage à l’adresse Indexhttps://localhost:{DEFAULT PORT}.

Dans l’exemple d’URL précédent, l’espace {DEFAULT PORT} réservé est le port par défaut défini par le MultipleBlazorApps.Server fichier du Properties/launchSettings.json projet dans sa applicationUrl valeur.

Important

Lorsque vous exécutez l’application avec la dotnet watch commande (ou dotnet run) (cli.NET), vérifiez que l’interpréteur de commandes est ouvert dans le Server dossier de la solution.

Lorsque vous utilisez le bouton Démarrer de Visual Studio pour exécuter l’application, vérifiez que le MultipleBlazorApps.Server projet est défini comme projet de démarrage (mis en surbrillance dans l’Explorateur de solutions).

Ressources statiques

Lorsqu’une ressource se trouve dans le dossier d’une wwwroot application cliente, fournissez le chemin de demande de 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 vehicle dossier de wwwroot:

<img alt="Jeep Wrangler YJ" src="vehicle/jeep-yj.png" />

Razor Prise en charge de la bibliothèque de classes (RCL)

Ajoutez la Razor bibliothèque de classes (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>un nouveau projet.
Utilisez le modèle de Razor projet Bibliothèque de classes pour créer le projet. Les exemples de cette section utilisent le nom ComponentLibrarydu projet, qui est également le nom de l’assembly RCL. Ne cochez pas les pages de support et les affichages .

Pour chaque application cliente hébergéeBlazor WebAssembly, créez une référence de projet pour le projet RCL en cliquant avec le bouton droit sur chaque projet client dans l’Explorateur de solutions et en sélectionnant Ajouter> uneréférence de projet.

Utilisez des composants à partir de la bibliothèque RCL dans les applications clientes avec l’une des approches suivantes :

Placez une @using directive en haut du composant pour l’espace de noms du RCL et ajoutez Razor la syntaxe du composant. L’exemple suivant est destiné à une bibliothèque RCL avec le nom ComponentLibraryde l’assembly :
```
@using ComponentLibrary

...

<Component1 />
```
Fournissez l’espace de noms du RCL ainsi que la Razor syntaxe du composant. Cette approche ne nécessite pas de @using directive en haut du fichier de composant. L’exemple suivant est destiné à une bibliothèque RCL avec le nom ComponentLibraryde l’assembly :
```
<ComponentLibrary.Component1 />
```

Note

Une @using directive peut également être placée dans le fichier de _Import.razor chaque application cliente, ce qui rend l’espace de noms rcL globalement disponible pour les composants de ce projet.

Quand une autre ressource statique se trouve dans le wwwroot dossier d’une bibliothèque 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 {PACKAGE ID} réservé est l’ID de package 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é est le chemin d’accès et le {PATH AND FILE NAME} nom de fichier sous wwwroot.

L’exemple suivant montre le balisage d’une image Jeep (jeep-yj.png) dans le vehicle dossier du dossier du wwwroot RCL. L’exemple suivant est destiné à une bibliothèque RCL avec le nom ComponentLibraryde l’assembly :

<img alt="Jeep Wrangler YJ" src="_content/ComponentLibrary/vehicle/jeep-yj.png" />

Ressources supplémentaires

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2025-11-11

Partage via

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

Paramétrage

Exécuter l’application

Ressources statiques

Razor Prise en charge de la bibliothèque de classes (RCL)

Ressources supplémentaires

Commentaires

Ressources supplémentaires