Hosten und Bereitstellen von ASP.NET Core
Hinweis
Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Warnung
Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-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.
Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.
Um eine ASP.NET Core-App in einer Hostingumgebung bereitzustellen, müssen Sie allgemein folgende Schritte durchführen:
- Stellen Sie die veröffentlichte App in einem Ordner auf dem Hostserver bereit.
- Richten Sie einen Prozess-Manager ein, der die App startet, wenn Anforderungen eingehen und die App nach einem Absturz oder Serverneustart neu startet.
- Richten Sie zur Konfiguration eines Reverseproxys einen Reverseproxy ein, der Anforderungen an die App weiterleitet.
Anleitungen zum Hosten und Bereitstellen von Blazor, die die Anleitungen in diesem Knoten ergänzen oder ersetzen, finden Sie unter Hosten und Bereitstellen von ASP.NET Core-Blazor.
Veröffentlichen in einem Ordner
Der Befehl dotnet publish kompiliert App-Code und kopiert die Dateien, die zum Ausführen der App erforderlich sind, in den Ordner publish. Bei der Bereitstellung von Visual Studio erfolgt der dotnet publish
-Schritt automatisch, bevor die Dateien in das Bereitstellungsziel kopiert werden.
Lokales Ausführen der veröffentlichten App
Um die veröffentlichte App lokal auszuführen, führen Sie dotnet <ApplicationName>.dll
aus dem Ordner publish aus.
Dateien mit Veröffentlichungseinstellungen
*.json
-Dateien werden standardmäßig veröffentlicht. Um andere Einstellungsdateien zu veröffentlichen, geben Sie sie in einem <ItemGroup><Content Include= ... />
-Element in der Projektdatei an. Im folgenden Beispiel werden XML-Dateien veröffentlicht:
<ItemGroup>
<Content Include="**\*.xml" Exclude="bin\**\*;obj\**\*"
CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
Ordnerinhalte
Der Ordner publish enthält mindestens eine App-Assemblydatei, Abhängigkeiten und optional die .NET-Runtime.
Eine .NET Core-App kann als eigenständige Bereitstellung oder als Framework-abhängige Bereitstellung veröffentlicht werden. Wenn die App eigenständig ist, sind die Assemblydateien, die die .NET-Runtime enthalten, im Ordner publish enthalten. Wenn die App frameworkabhängig ist, sind die Dateien für die .NET-Runtime nicht enthalten, da die App über einen Verweis auf eine auf dem Server installierte .NET-Version verfügt. Das Standardmodell für die Bereitstellung ist Framework-abhängig. Weitere Informationen finden Sie unter .NET Core application deployment (.NET Core-Anwendungsbereitstellung).
Zusätzlich zu den EXE- und DLL-Dateien enthält der Ordner publish für eine ASP.NET Core-App üblicherweise noch Konfigurationsdateien, statische Objekte und MVC-Ansichten. Weitere Informationen finden Sie unter ASP.NET Core-Verzeichnisstruktur.
Einrichten eines Prozessmanagers
Bei einer ASP.NET Core-App handelt es sich um eine Konsolen-App, die gestartet werden muss, wenn ein Server startet und nach Abstürzen neu startet. Sie benötigen einen Prozess-Manager, um die Starts und Neustarts zu automatisieren. Die gängigsten Prozess-Manager für ASP.NET Core sind Folgende:
- Linux
- Windows
Einrichten eines Reverseproxys
Wenn die App den Kestrel-Server verwendet, können Nginx oder IIS als Reverseproxyserver verwendet werden. Ein Reverseproxyserver empfängt HTTP-Anforderungen aus dem Internet und leitet diese an Kestrel weiter.
Jede der beiden Konfigurationen (ob mit oder ohne Reverseproxyserver) stellt eine unterstützte Hostingkonfiguration dar. Weitere Informationen finden Sie unter Verwenden von Kestrel mit einem Reverseproxy.
Jede der beiden Konfigurationen (ob mit oder ohne Reverseproxyserver) stellt eine unterstützte Hostingkonfiguration dar. Weitere Informationen finden Sie unter Verwenden von Kestrel mit einem Reverseproxy.
Proxyserver und Lastenausgleichsszenarien
Möglicherweise ist zusätzliche Konfiguration für Apps erforderlich, die hinter Proxyservern und Lastenausgleichsmodulen (Load Balancer) gehostet werden. Ohne zusätzliche Konfiguration hat eine App möglicherweise keinen Zugriff auf das Schema (HTTP/HTTPS) und die Remote-IP-Adresse, von der eine Anforderung stammte. Weitere Informationen hierzu feinden Sie unter Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich.
Verwenden von Visual Studio und MSBuild zum Automatisieren der Bereitstellungen
Die Bereitstellung erfordert neben dem Kopieren der Ausgabe von dotnet publish auf einen Server oft zusätzliche Aufgaben. Beispielsweise können zusätzliche Dateien aus dem Ordner publish erforderlich oder ausgeschlossen sein. Visual Studio verwendet MSBuild für die Webbereitstellung, und MSBuild kann für die Ausführung vieler weiterer Tasks während der Bereitstellung angepasst werden. Weitere Informationen finden Sie unter Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps und im BuchUsing MSBuild and Team Foundation Build.
Mithilfe des Webfeatures Veröffentlichen können Apps direkt über Visual Studio in Azure App Service bereitgestellt werden. Azure DevOps Services unterstützt Continuous Deployment in Azure App Service. Weitere Informationen finden Sie unter DevOps für ASP.NET Core-Entwickler.
Veröffentlichen in Azure
Anweisungen zum Veröffentlichen einer App in Azure mit Visual Studio finden Sie unter Veröffentlichen einer ASP.NET Core-App in Azure mit Visual Studio. Ein weiteres Beispiel wird unter Erstellen von ASP.NET Core-Web-Apps in Azure bereitgestellt.
Veröffentlichen mit MSDeploy unter Windows
Anleitungen zum Veröffentlichen einer App mit einem Visual Studio-Veröffentlichungsprofil, z. B. über eine Windows-Eingabeaufforderung mit dem Befehl dotnet msbuild, finden Sie unter Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps.
Internetinformationsdienste (IIS)
Informationen zu Bereitstellungen zu Internetinformationsdiensten (IIS) mit von der Datei web.config bereitgestellter Konfiguration, finden Sie in den Artikeln unter Hosten von ASP.NET Core unter Windows mit IIS.
Hosten in einer Webfarm
Weitere Informationen zur Konfiguration des Hostings von ASP.NET Core-Apps in einer Webfarmumgebung (z. B. Bereitstellung mehrerer App-Instanzen zur besseren Skalierbarkeit) finden Sie unter Hosten von ASP.NET Core in einer Webfarm.
Hosten auf Docker
Weitere Informationen finden Sie unter Hosten von ASP.NET Core in Docker-Containern.
Ausführen von Integritätsprüfungen
Verwenden Sie Middleware für die Integritätsprüfung, um Integritätsprüfungen für eine App und deren Abhängigkeiten auszuführen. Weitere Informationen finden Sie unter Integritätsprüfungen in ASP.NET Core.
Zusätzliche Ressourcen
Um eine ASP.NET Core-App in einer Hostingumgebung bereitzustellen, müssen Sie allgemein folgende Schritte durchführen:
- Stellen Sie die veröffentlichte App in einem Ordner auf dem Hostserver bereit.
- Richten Sie einen Prozess-Manager ein, der die App startet, wenn Anforderungen eingehen und die App nach einem Absturz oder Serverneustart neu startet.
- Richten Sie zur Konfiguration eines Reverseproxys einen Reverseproxy ein, der Anforderungen an die App weiterleitet.
Veröffentlichen in einem Ordner
Der Befehl dotnet publish kompiliert App-Code und kopiert die Dateien, die zum Ausführen der App erforderlich sind, in den Ordner publish. Bei der Bereitstellung von Visual Studio erfolgt der dotnet publish
-Schritt automatisch, bevor die Dateien in das Bereitstellungsziel kopiert werden.
Ordnerinhalte
Der Ordner publish enthält mindestens eine App-Assemblydatei, Abhängigkeiten und optional die .NET-Runtime.
Eine .NET Core-App kann als eigenständige Bereitstellung oder als Framework-abhängige Bereitstellung veröffentlicht werden. Wenn die App eigenständig ist, sind die Assemblydateien, die die .NET-Runtime enthalten, im Ordner publish enthalten. Wenn die App frameworkabhängig ist, sind die Dateien für die .NET-Runtime nicht enthalten, da die App über einen Verweis auf eine auf dem Server installierte .NET-Version verfügt. Das Standardmodell für die Bereitstellung ist Framework-abhängig. Weitere Informationen finden Sie unter .NET Core application deployment (.NET Core-Anwendungsbereitstellung).
Zusätzlich zu den EXE- und DLL-Dateien enthält der Ordner publish für eine ASP.NET Core-App üblicherweise noch Konfigurationsdateien, statische Objekte und MVC-Ansichten. Weitere Informationen finden Sie unter ASP.NET Core-Verzeichnisstruktur.
Einrichten eines Prozessmanagers
Bei einer ASP.NET Core-App handelt es sich um eine Konsolen-App, die gestartet werden muss, wenn ein Server startet und nach Abstürzen neu startet. Sie benötigen einen Prozess-Manager, um die Starts und Neustarts zu automatisieren. Die gängigsten Prozess-Manager für ASP.NET Core sind Folgende:
- Linux
- Windows
Einrichten eines Reverseproxys
Wenn die App den Kestrel-Server verwendet, können Nginx oder IIS als Reverseproxyserver verwendet werden. Ein Reverseproxyserver empfängt HTTP-Anforderungen aus dem Internet und leitet diese an Kestrel weiter.
Jede der beiden Konfigurationen (ob mit oder ohne Reverseproxyserver) stellt eine unterstützte Hostingkonfiguration dar. Weitere Informationen finden Sie unter Verwenden von Kestrel mit einem Reverseproxy.
Proxyserver und Lastenausgleichsszenarien
Möglicherweise ist zusätzliche Konfiguration für Apps erforderlich, die hinter Proxyservern und Lastenausgleichsmodulen (Load Balancer) gehostet werden. Ohne zusätzliche Konfiguration hat eine App möglicherweise keinen Zugriff auf das Schema (HTTP/HTTPS) und die Remote-IP-Adresse, von der eine Anforderung stammte. Weitere Informationen hierzu feinden Sie unter Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich.
Verwenden von Visual Studio und MSBuild zum Automatisieren der Bereitstellungen
Die Bereitstellung erfordert neben dem Kopieren der Ausgabe von dotnet publish auf einen Server oft zusätzliche Aufgaben. Beispielsweise können zusätzliche Dateien aus dem Ordner publish erforderlich oder ausgeschlossen sein. Visual Studio verwendet MSBuild für die Webbereitstellung, und MSBuild kann für die Ausführung vieler weiterer Tasks während der Bereitstellung angepasst werden. Weitere Informationen finden Sie unter Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps und im BuchUsing MSBuild and Team Foundation Build.
Mithilfe des Webfeatures Veröffentlichen können Apps direkt über Visual Studio in Azure App Service bereitgestellt werden. Azure DevOps Services unterstützt Continuous Deployment in Azure App Service. Weitere Informationen finden Sie unter DevOps für ASP.NET Core-Entwickler.
Veröffentlichen in Azure
Anweisungen zum Veröffentlichen einer App in Azure mit Visual Studio finden Sie unter Veröffentlichen einer ASP.NET Core-App in Azure mit Visual Studio. Ein weiteres Beispiel wird unter Erstellen von ASP.NET Core-Web-Apps in Azure bereitgestellt.
Veröffentlichen mit MSDeploy unter Windows
Anleitungen zum Veröffentlichen einer App mit einem Visual Studio-Veröffentlichungsprofil, z. B. über eine Windows-Eingabeaufforderung mit dem Befehl dotnet msbuild, finden Sie unter Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps.
Internetinformationsdienste (IIS)
Informationen zu Bereitstellungen zu Internetinformationsdiensten (IIS) mit von der Datei web.config bereitgestellter Konfiguration, finden Sie in den Artikeln unter Hosten von ASP.NET Core unter Windows mit IIS.
Hosten in einer Webfarm
Weitere Informationen zur Konfiguration des Hostings von ASP.NET Core-Apps in einer Webfarmumgebung (z. B. Bereitstellung mehrerer App-Instanzen zur besseren Skalierbarkeit) finden Sie unter Hosten von ASP.NET Core in einer Webfarm.
Hosten auf Docker
Weitere Informationen finden Sie unter Hosten von ASP.NET Core in Docker-Containern.