Hosten und Bereitstellen von ASP.NET Core Blazor
Hinweis
Dies ist nicht die neueste Version dieses Artikels. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.
Warnung
Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Supportrichtlinie für .NET und .NET Core. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.
Wichtig
Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.
Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.
In diesem Artikel wird erläutert, wie Sie Blazor-Apps hosten und bereitstellen.
Veröffentlichen der App
Apps werden für die Bereitstellung in Releasekonfigurationen veröffentlicht.
Hinweis
Veröffentlichen Sie eine gehostete Blazor WebAssembly-Projektmappe aus dem Server-Projekt.
- Wählen Sie den Befehl {APPLICATION} veröffentlichen aus dem Menü Build aus. (Der Platzhalter
{APPLICATION}
ist der Name der App.) - Wählen Sie das Veröffentlichungsziel aus. Um lokal zu veröffentlichen, wählen Sie Ordner aus.
- Übernehmen Sie den Standardspeicherort im Feld Ordner auswählen, oder geben Sie einen anderen Speicherort an. Wählen Sie die Schaltfläche
Publish
aus.
Das Veröffentlichen einer App löst eine Wiederherstellung der Abhängigkeiten des Projekts aus und erstellt das Projekt, bevor die Objekte für die Bereitstellung erstellt werden. Im Rahmen des Buildprozesses werden nicht verwendete Methoden und Assemblys entfernt, um die Downloadgröße und Ladezeiten von Apps zu reduzieren.
Veröffentlichungsspeicherorte:
- Blazor-Web-App: Standardmäßig wird die App im Ordner
/bin/Release/{TARGET FRAMEWORK}/publish
veröffentlicht. Stellen Sie die Inhalte des Ordnerspublish
auf dem Host bereit. - Blazor WebAssembly: Standardmäßig wird die App im Ordner
bin\Release\net8.0\browser-wasm\publish\
veröffentlicht. Zum Bereitstellen der App als statische Website kopieren Sie den Inhalt des Ordnerswwwroot
auf den Host der statischen Website.
- Blazor Server: Standardmäßig wird die App im Ordner
/bin/Release/{TARGET FRAMEWORK}/publish
veröffentlicht. Stellen Sie die Inhalte des Ordnerspublish
auf dem Host bereit. - Blazor WebAssembly
- Eigenständig: Die App wird je nach Version des SDK, das zum Veröffentlichen der App verwendet wird, standardmäßig im Ordner
/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
oderbin\Release\{TARGET FRAMEWORK}\browser-wasm\publish
veröffentlicht. Zum Bereitstellen der App als statische Website kopieren Sie den Inhalt des Ordnerswwwroot
auf den Host der statischen Website. - Gehostet: Die Blazor WebAssembly-Client-App wird im Ordner
/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
der Server-App zusammen mit allen anderen statischen Webressourcen der Client-App veröffentlicht. Stellen Sie die Inhalte des Ordnerspublish
auf dem Host bereit.
- Eigenständig: Die App wird je nach Version des SDK, das zum Veröffentlichen der App verwendet wird, standardmäßig im Ordner
Der Abschnitt {TARGET FRAMEWORK}
in den vorherigen Pfaden steht für das Zielframework (z. B. net8.0
).
IIS
Informationen zum Hosten einer Blazor-App in IIS finden Sie in den folgenden Ressourcen:
- IIS-Hosting
- Hosten und Bereitstellen von serverseitigen ASP.NET Core Blazor-Apps: Server-Apps, die in IIS ausgeführt werden, einschließlich IIS mit virtuellen Azure-Computern (Virtual Machines, VMs) unter dem Windows-Betriebssystem und mit Azure App Service.
- Hosten und Bereitstellen von ASP.NET Core Blazor WebAssembly: Enthält zusätzliche Anleitungen für Blazor WebAssembly-Apps, die in IIS gehostet werden. Dies schließt das Hosten statischer Websites, benutzerdefinierte Dateien vom Typ
web.config
, URL-Umschreibung, untergeordnete Apps, Komprimierung und das Hosten statischer Dateien von Azure Storage ein. - IIS-Hosting untergeordneter Anwendungen
- Befolgen Sie die Anleitungen im Abschnitt Basispfad einer App für die Blazor-App, bevor Sie die App veröffentlichen. In den Beispielen wird der App-Basispfad
/CoolApp
verwendet und gezeigt, wie Sie den Basispfad aus App-Einstellungen oder anderen Konfigurationsanbietern abrufen. - Folgen Sie der Anleitung zum Konfigurieren untergeordneter Anwendungen unter Erweiterte Konfiguration. Der Ordnerpfad der untergeordneten App unter der Stammwebsite wird zum virtuellen Pfad der untergeordneten App. Bei einem App-Basispfad wie
/CoolApp
wird die Blazor-App in einem Ordner mit dem NamenCoolApp
unter der Stammwebsite platziert, und die untergeordnete App verwendet einen virtuellen Pfad (/CoolApp
).
- Befolgen Sie die Anleitungen im Abschnitt Basispfad einer App für die Blazor-App, bevor Sie die App veröffentlichen. In den Beispielen wird der App-Basispfad
Das Freigeben eines App-Pools zwischen ASP.NET Core-Apps wird nicht unterstützt, auch nicht für Blazor-Apps. Verwenden Sie beim Hosten mit IIS einen App-Pool pro App, und vermeiden Sie die Verwendung der virtuellen IIS-Verzeichnisse zum Hosten mehrerer Apps.
Eine oder mehrere Blazor WebAssembly-Apps, die von einer ASP.NET Core-App gehostet werden, eine sog. gehostete Blazor WebAssembly-Lösung, werden für einen App-Pool unterstützt. Wir empfehlen jedoch nicht, einen einzelnen App-Pool mehreren gehosteten Blazor WebAssembly-Lösungen oder Szenarien mit dem Hosting untergeordneter Anwendungen zuzuweisen, und unterstützen dies auch nicht.
Weitere Informationen zu Lösungen finden Sie unter Tools für ASP.NET Core Blazor.
Basispfad einer App
Der Basispfad einer App beschreibt den URL-Stammpfad der App. Erfolgreiches Routing in Blazor-Apps erfordert eine Frameworkkonfiguration für alle Stamm-URL-Pfade, die sich nicht im Standard-App-Basispfad /
befinden.
Betrachten Sie die folgende ASP.NET Core-App und die untergeordnete Blazor-App:
- Die ASP.NET Core-App heißt
MyApp
:- Die App befindet sich physisch unter
d:/MyApp
. - Anforderungen werden über
https://www.contoso.com/{MYAPP RESOURCE}
empfangen.
- Die App befindet sich physisch unter
- Eine Blazor-App mit dem Namen
CoolApp
ist die untergeordnete App vonMyApp
:- Die untergeordnete App befindet sich physisch unter
d:/MyApp/CoolApp
. - Anforderungen werden über
https://www.contoso.com/CoolApp/{COOLAPP RESOURCE}
empfangen.
- Die untergeordnete App befindet sich physisch unter
Wenn keine zusätzlichen Konfiguration für CoolApp
festgelegt wird, weiß die untergeordnete App in diesem Szenario nicht, wo sie sich auf dem Server befindet. Beispielsweise kann die App keine richtigen relativen URLs zu ihren Ressourcen erstellen, ohne zu wissen, dass sie sich unter dem relativen URL-Pfad /CoolApp/
befindet. Das gilt auch in verschiedenen Hosting- und Reverseproxyszenarios, wenn eine App nicht unter einem URL-Stammpfad gehostet wird.
Hintergrund
Das Ziel eines Ankertags (href
) kann mit einem von zwei Endpunkten erstellt werden:
Absolute Speicherorte, die ein Schema (ohne Angabe wird standardmäßig das Schema der Seite verwendet), einen Host, einen Port und einen Pfad enthalten, oder nur ein Schrägstrich (
/
) gefolgt vom Pfad.Beispiel:
https://example.com/a/b/c
oder/a/b/c
Relative Speicherorte, die nur einen Pfad enthalten und nicht mit einem Schrägstrich (
/
) beginnen. Diese werden relativ zur aktuellen Dokument-URL oder relativ zum Wert des<base>
-Tags aufgelöst (sofern angegeben).Beispiel:
a/b/c
Das Vorhandensein eines nachgestellten Schrägstrichs (/
) in einem konfigurierten App-Basispfad ist wichtig, um den Basispfad für URLs der App zu berechnen. Beispielsweise hat https://example.com/a
den Basispfad https://example.com/
, während https://example.com/a/
mit einem nachgestellten Schrägstrich den Basispfad https://example.com/a
hat.
Es gibt drei Linkquellen, die sich auf Blazor in ASP.NET Core-Apps beziehen:
- URLs in Razor-Komponenten (
.razor
) sind in der Regel relativ. - URLs in Skripts, z. B. Blazor-Skripts (
blazor.*.js
), sind relativ zum Dokument.
- URLs, die manuell in die Datei
_Host.cshtml
(Blazor Server) geschrieben wurden (sollte beim Rendern in verschiedenen Dokumenten immer absolut sein). - URLs in Razor-Komponenten (
.razor
) sind in der Regel relativ. - URLs in Skripts, z. B. Blazor-Skripts (
blazor.*.js
), sind relativ zum Dokument.
Wenn Sie eine Blazor-App aus verschiedenen Dokumenten rendern (z. B. /Admin/B/C/
und /Admin/D/E/
), müssen Sie den App-Basispfad berücksichtigen. Andernfalls unterscheidet sich der Basispfad, wenn die App in den einzelnen Dokumenten gerendert wird, und die Ressourcen werden von den falschen URLs abgerufen.
Es gibt zwei Ansätze für die korrekte Auflösung relativer Links:
- Dynamisches Zuordnen der Ressourcen, wobei das Dokument, auf dessen Grundlage sie gerendert wurden, als Stamm verwendet wird
- Festlegen eines konsistenten Basispfads für das Dokument und Zuordnen der Ressourcen unter diesem Basispfad
Die erste Option ist komplizierter und nicht der gängigste Ansatz, da die Navigation für jedes Dokument unterschiedlich ist. Betrachten Sie das folgende Beispiel zum Rendern der Seite /Something/Else
:
- Beim Rendern unter
/Admin/B/C/
wird die Seite mit dem Pfad/Admin/B/C/Something/Else
gerendert. - Beim Rendern unter
/Admin/D/E/
wird die Seite unter dem gleichen Pfad (also/Admin/B/C/Something/Else
) gerendert.
Beim ersten Ansatz liefert das Routing IDynamicEndpointMetadata und MatcherPolicy. Die Kombination aus beidem kann die Basis für die Implementierung einer vollständig dynamischen Lösung sein, die zur Laufzeit bestimmt, wie Anforderungen weitergeleitet werden.
Die zweite Option ist die übliche Vorgehensweise. Hierbei legt die App den Basispfad im Dokument fest und ordnet die Serverendpunkte Pfaden unter der Basis zu. Dieser Ansatz wird in den folgenden Anleitungen verwendet.
Serverseitige Blazor-App
Ordnen Sie den SignalR-Hub einer serverseitigen Blazor-App zu, indem Sie den Pfad zu MapBlazorHub in der Program
-Datei übergeben:
app.MapBlazorHub("base/path");
Der Vorteil der Verwendung von MapBlazorHub ist, dass Sie Muster wie "{tenant}"
und nicht nur konkrete Pfade zuordnen können.
Sie können den SignalR-Hub auch zuordnen, wenn sich die App in einem virtuellen Ordner mit einer verzweigten Middleware-Pipeline befindet. Im folgenden Beispiel werden Anforderungen an/base/path/
vom SignalR-Hub von Blazor behandelt:
app.Map("/base/path/", subapp => {
subapp.UsePathBase("/base/path/");
subapp.UseRouting();
subapp.UseEndpoints(endpoints => endpoints.MapBlazorHub());
});
Konfigurieren Sie das Tag <base>
gemäß der Anleitung im Abschnitt Konfigurieren des Basispfads der App.
Gehostete Blazor WebAssembly-App
Wenn die App eine gehostete Blazor WebAssembly-App ist:
- Gehen Sie im Server-Projekt (
Program.cs
) wie folgt vor:- Passen Sie den Pfad von UseBlazorFrameworkFiles an (z. B.
app.UseBlazorFrameworkFiles("/base/path");
). - Konfigurieren Sie Aufrufe von UseStaticFiles (z. B.
app.UseStaticFiles("/base/path");
).
- Passen Sie den Pfad von UseBlazorFrameworkFiles an (z. B.
- Gehen Sie im Client-Projekt wie folgt vor:
- Konfigurieren Sie
<StaticWebAssetBasePath>
in der Projektdatei so, dass die Konfiguration dem Pfad für die Bereitstellung statischer Webressourcen entspricht (z. B.<StaticWebAssetBasePath>base/path</StaticWebAssetBasePath>
). - Konfigurieren Sie das Tag
<base>
gemäß der Anleitung im Abschnitt Konfigurieren des Basispfads der App.
- Konfigurieren Sie
Ein Beispiel für das Hosten mehrerer Blazor WebAssembly-Apps in einer gehosteten Blazor WebAssembly-Lösung finden Sie unter Mehrere gehostete ASP.NET Core Blazor WebAssembly Apps. Dort werden Ansätze für das Domänen-/Porthosting und das Unterpfadhosting mehrerer Blazor WebAssembly-Client-Apps erläutert.
Eigenständige Blazor WebAssembly-App
In einer eigenständigen Blazor WebAssembly-App wird nur das Tag <base>
gemäß der Anleitung im Abschnitt Konfigurieren des Basispfads der App konfiguriert.
Konfigurieren des Basispfads der App
Legen Sie den Basispfad der App (auch relativer Stammpfad genannt) fest, um die Konfiguration für den Basispfad https://www.contoso.com/CoolApp/
der Blazor-App bereitzustellen.
Durch Konfigurieren des Basispfads der App kann eine Komponente, die sich nicht im Stammverzeichnis befindet, URLs relativ zum Stammpfad der App erstellen. Komponenten auf verschiedenen Verzeichnisstrukturebenen können Links zu anderen Ressourcen an Speicherorten in der gesamten App erstellen. Ferner wird der Basispfad der App verwendet, um ausgewählte Hyperlinks abzufangen, bei denen sich das href
-Ziel des Links innerhalb des URI-Raums für den Basispfad der App befindet. Die Router-Komponente verarbeitet die interne Navigation.
Bei vielen Hostingszenarios ist der relative URL-Pfad des Servers zur App das Stammverzeichnis der App. In diesen Standardfällen lautet der relative URL-Basispfad der App /
und wird als <base href="/" />
im <head>
-Inhalt konfiguriert.
Bei vielen Hostingszenarios ist der relative URL-Pfad des Servers zur App das Stammverzeichnis der App. In diesen Standardfällen lautet der relative URL-Basispfad der App im <head>
-Inhalt folgendermaßen:
- Blazor Server:
~/
konfiguriert als<base href="~/" />
- Blazor WebAssembly:
/
konfiguriert als<base href="/" />
Hinweis
In einigen Hostingszenarien, z. B. bei GitHub Pages und untergeordneten IIS-Apps, muss der Basispfad der App auf den relativen URL-Pfad des Servers der App festgelegt werden.
Verwenden Sie in einer serverseitigen Blazor-App einen der folgenden Ansätze:
Option 1: Verwenden Sie das Tag
<base>
, um den Basispfad der App (Speicherort von<head>
-Inhalten) festzulegen:<base href="/CoolApp/">
Der nachstehende Schrägstrich ist erforderlich.
Option 2: Rufen Sie UsePathBase zuerst in der Anforderungsverarbeitungspipeline der App (
Program.cs
) auf, und zwar unmittelbar nach der Erstellung von WebApplicationBuilder (builder.Build()
), um den Basispfad für ggf. folgende Middleware zu konfigurieren, die mit dem Anforderungspfad interagiert:app.UsePathBase("/CoolApp");
Das Aufrufen von UsePathBase wird empfohlen, wenn Sie die Blazor Server-App auch lokal ausführen möchten. Geben Sie die Start-URL beispielsweise in
Properties/launchSettings.json
an:"launchUrl": "https://localhost:{PORT}/CoolApp",
Der Platzhalter
{PORT}
im vorherigen Beispiel ist der Port, der dem sicheren Port im KonfigurationspfadapplicationUrl
entspricht. Das folgende Beispiel zeigt das vollständige Startprofil für eine App an Port 7279:"BlazorSample": { "commandName": "Project", "dotnetRunMessages": true, "launchBrowser": true, "applicationUrl": "https://localhost:7279;http://localhost:5279", "launchUrl": "https://localhost:7279/CoolApp", "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" }
Weitere Informationen zur Datei
launchSettings.json
finden Sie im Artikel Verwenden von mehreren Umgebungen in ASP.NET Core. Weitere Informationen zu Blazor-App-Basispfaden und zum Hosting finden Sie unter<base href="/" />
or base-tag alternative for Blazor MVC integration (dotnet/aspnetcore #43191).
Eigenständige Blazor WebAssembly-App (
wwwroot/index.html
):<base href="/CoolApp/">
Der nachstehende Schrägstrich ist erforderlich.
Gehostete Blazor WebAssembly-App (Client-Projekt,
wwwroot/index.html
):<base href="/CoolApp/">
Der nachstehende Schrägstrich ist erforderlich.
Rufen Sie im Server-Projekt UsePathBase zuerst in der Anforderungsverarbeitungspipeline der App (
Program.cs
) auf, und zwar unmittelbar nach der Erstellung von WebApplicationBuilder (builder.Build()
), um den Basispfad für ggf. folgende Middleware zu konfigurieren, die mit dem Anforderungspfad interagiert:app.UsePathBase("/CoolApp");
Hinweis
Wenn Sie WebApplication verwenden (siehe Migrieren von ASP.NET Core 5.0 zu 6.0), muss app.UseRouting
nach UsePathBase aufgerufen werden, damit die Routingmiddleware den geänderten Pfad berücksichtigen kann, bevor Routen abgeglichen werden. Andernfalls werden Routen abgeglichen, bevor der Pfad durch UsePathBase neu geschrieben wird. Weitere Informationen hierzu finden Sie in den Artikeln Festlegen der Reihenfolge für Middleware und Routing.
Stellen Sie den Links in der App keinen Schrägstrich voran. Vermeiden Sie entweder die Verwendung eines Pfadsegmenttrennzeichens, oder verwenden Sie eine relative Pfadnotation mit einem Punkt und einem Schrägstrich (./
):
<a href="/account">
Falsch: <a href="account">
Richtig: <a href="./account">
Richtig:
Vergewissern Sie sich in Blazor WebAssembly-Web-API-Anforderungen mit dem HttpClient
-Dienst, dass JSON-Hilfsprogramme (HttpClientJsonExtensions) den URLs keinen Schrägstrich (/
) vorangestellt haben:
var rsp = await client.GetFromJsonAsync("/api/Account");
Falsch: var rsp = await client.GetFromJsonAsync("api/Account");
Richtig:
Stellen Sie relativen Navigation Manager-Links keinen Schrägstrich voran. Vermeiden Sie entweder die Verwendung eines Pfadsegmenttrennzeichens, oder verwenden Sie einen Punkt und einen Schrägstrich (./
) für eine relative Pfadnotation (Navigation
ist ein eingefügtes NavigationManager-Element):
Navigation.NavigateTo("/other");
Falsch: Navigation.NavigateTo("other");
Richtig: Navigation.NavigateTo("./other");
Richtig:
In der Regel ist beim Azure- oder IIS-Hosting keine zusätzliche Konfiguration erforderlich. Beim Hosting ohne IIS oder beim Reverseproxyhosting kann eine zusätzliche Konfiguration der Middleware für statische Dateien erforderlich sein, um Folgendes zu erreichen:
- Korrektes Bereitstellen statischer Dateien (z. B.
app.UseStaticFiles("/CoolApp");
) - Zum Bereitstellen des Blazor-Skripts (
_framework/blazor.*.js
). Weitere Informationen finden Sie unter Blazor in ASP.NET Core: statische Dateien.
Bei einer Blazor WebAssembly-App mit einem relativen URL-Pfad, der nicht zum Stammverzeichnis führt (z. B. <base href="/CoolApp/">
), werden die Ressourcen der App nicht gefunden, wenn die App lokal ausgeführt wird. Um dieses Problem bei der lokalen Entwicklung und bei Tests zu beheben, können Sie ein Pfadbasis-Argument bereitstellen, das dem href
-Wert des <base>
-Tags zur Laufzeit entspricht. Fügen Sie keinen nachgestellten Schrägstrich ein. Führen Sie den Befehl dotnet watch
(oder dotnet run
) aus dem Verzeichnis der App mit der Option --pathbase
aus, um das Basispfadargument beim lokalen Ausführen der App zu übergeben:
dotnet watch --pathbase=/{RELATIVE URL PATH (no trailing slash)}
Für eine Blazor WebAssembly-App mit einem relativen URL-Pfad von /CoolApp/
(<base href="/CoolApp/">
) lautet der Befehl wie folgt:
dotnet watch --pathbase=/CoolApp
Wenn Sie das Startprofil der App so konfigurieren möchten, dass pathbase
automatisch und nicht manuell mit dotnet watch
(oder dotnet run
) angegeben wird, legen Sie die commandLineArgs
-Eigenschaft in Properties/launchSettings.json
fest. Im Folgenden wird auch die Start-URL konfiguriert (launchUrl
):
"commandLineArgs": "--pathbase=/{RELATIVE URL PATH (no trailing slash)}",
"launchUrl": "{RELATIVE URL PATH (no trailing slash)}",
Verwenden Sie CoolApp
als Beispiel:
"commandLineArgs": "--pathbase=/CoolApp",
"launchUrl": "CoolApp",
Verwenden Sie entweder dotnet watch
(oder dotnet run
) mit der Option --pathbase
oder eine Startprofilkonfiguration, die den Basispfad festlegt. Die Blazor WebAssembly-App reagiert lokal unter http://localhost:port/CoolApp
.
Weitere Informationen zur Datei launchSettings.json
finden Sie im Artikel Verwenden von mehreren Umgebungen in ASP.NET Core. Weitere Informationen zu Blazor-App-Basispfaden und zum Hosting finden Sie unter <base href="/" />
or base-tag alternative for Blazor MVC integration (dotnet/aspnetcore #43191).
Abrufen des App-Basispfads aus der Konfiguration
Im folgenden Leitfaden wird erläutert, wie Sie den Pfad für das <base>
-Tag aus einer App-Einstellungsdatei für verschiedene Umgebungen abrufen.
Fügen Sie der App die App-Einstellungsdatei hinzu. Das folgende Beispiel gilt für die Staging
-Umgebung (appsettings.Staging.json
):
{
"AppBasePath": "staging/"
}
Laden Sie in einer serverseitigen Blazor-App den Basispfad aus der Konfiguration in <head>
Inhalt:
@inject IConfiguration Config
...
<head>
...
<base href="/@(Config.GetValue<string>("AppBasePath"))" />
...
</head>
Alternativ kann eine serverseitige App den Wert aus der Konfiguration für UsePathBase abrufen. Platzieren Sie den folgenden Code zuerst in der Anforderungsverarbeitungspipeline (Program.cs
) der App unmittelbar nach dem Erstellen von WebApplicationBuilder (builder.Build()
). Im folgenden Beispiel wird der Konfigurationsschlüssel AppBasePath
verwendet:
app.UsePathBase($"/{app.Configuration.GetValue<string>("AppBasePath")}");
In einer clientseitigen Blazor WebAssembly-App:
Entfernen Sie das
<base>
-Tag auswwwroot/index.html
:- <base href="..." />
Geben Sie den App-Basispfad über eine
HeadContent
Komponente in derApp
Komponente an (App.razor
):@inject IConfiguration Config ... <HeadContent> <base href="/@(Config.GetValue<string>("AppBasePath"))" /> </HeadContent>
Wenn kein Konfigurationswert geladen werden soll, z. B. in Nicht-Staging-Umgebungen, wird die vorangehende href
in den Stammpfad /
aufgelöst.
Die Beispiele in diesem Abschnitt konzentrieren sich auf die Bereitstellung des App-Basispfads aus den App-Einstellungen, aber der Ansatz zum Lesen des Pfads aus IConfiguration ist für jeden Konfigurationsanbieter gültig. Weitere Informationen finden Sie in den folgenden Ressourcen:
Blazor ServerMapFallbackToPage
-Konfiguration
Dieser Abschnitt gilt nur für Blazor Server-Apps. MapFallbackToPage wird in Blazor-Web-Apps und Blazor WebAssembly-Apps nicht unterstützt.
Falls eine App einen separaten Bereich mit benutzerdefinierten Ressourcen und Razor-Komponenten erfordert:
Erstellen Sie im Ordner
Pages
der App einen Ordner für die Ressourcen. Der Administratorbereich einer App wird beispielsweise in einem Ordner namensAdmin
(Pages/Admin
) erstellt.Erstellen Sie eine Stammseite (
_Host.cshtml
) für den Bereich. Erstellen Sie beispielsweise einePages/Admin/_Host.cshtml
-Datei aus der Hauptstammseite der App (Pages/_Host.cshtml
). Geben Sie auf der_Host
-Seite für Administrator*innen keine@page
-Anweisung an.Fügen Sie dem Ordner des Bereichs ein Layout hinzu (z. B.
Pages/Admin/_Layout.razor
). Legen Sie das<base>
-Taghref
im Layout für den separaten Bereich so fest, dass es mit dem Ordner des Bereichs übereinstimmt (z. B.<base href="/Admin/" />
). Fügen Sie zu Demonstrationszwecken~/
zu den statischen Ressourcen auf der Seite hinzu. Beispiel:~/css/bootstrap/bootstrap.min.css
~/css/site.css
~/BlazorSample.styles.css
(der Namespace der Beispiel-App lautetBlazorSample
)~/_framework/blazor.server.js
(Blazor-Skript)
Wenn der Bereich über einen eigenen Ordner für statische Ressourcen verfügen soll, fügen Sie einen Ordner hinzu, und geben Sie dessen Speicherort in der Middleware für statische Dateien in
Program.cs
(z. B.app.UseStaticFiles("/Admin/wwwroot")
) an.Razor-Komponenten werden dem Ordner des Bereichs hinzugefügt. Fügen Sie dem Bereichsordner mindestens eine
Index
-Komponente mit der richtigen@page
-Anweisung für den Bereich hinzu. Fügen Sie beispielsweise einePages/Admin/Index.razor
-Datei hinzu, die auf derPages/Index.razor
-Standarddatei der App basiert. Geben Sie den Bereich Admin als Routenvorlage am Anfang der Datei an (@page "/admin"
). Fügen Sie bei Bedarf zusätzliche Komponenten hinzu. Geben Sie beispielsweisePages/Admin/Component1.razor
mit einer@page
-Anweisung und der Routenvorlage@page "/admin/component1
an.Rufen Sie in
Program.cs
die Methode MapFallbackToPage für den Anforderungspfad des Bereichs unmittelbar vor dem Pfad der Fallbackstammseite auf die_Host
-Seite auf:... app.UseRouting(); app.MapBlazorHub(); app.MapFallbackToPage("~/Admin/{*clientroutes:nonfile}", "/Admin/_Host"); app.MapFallbackToPage("/_Host"); app.Run();
Hosten mehrerer Blazor WebAssembly-Apps
Weitere Informationen zum Hosten mehrerer Blazor WebAssembly-Apps in einer gehosteten Blazor-Lösung finden Sie unter Mehrere gehostete Blazor WebAssembly-Apps unter ASP.NET Core.
Bereitstellung
Anleitungen für die Bereitstellung finden Sie in folgenden Themen: