Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps

Von Sayed Ibrahim Hashimi und Rick Anderson

Das vorliegende Dokument konzertiert sich auf die Verwendung von Visual Studio 2019 oder höher zum Erstellen und Verwenden von Veröffentlichungsprofilen. Die Veröffentlichungsprofile, die mit Visual Studio erstellt werden, können mit MSBuild und Visual Studio verwendet werden. Anweisungen zum Veröffentlichen in Azure finden Sie unter Veröffentlichen einer ASP.NET Core-App in Azure mit Visual Studio.

Der Befehl dotnet new mvc erzeugt eine Projektdatei, die das folgende <Project>-Element auf der Stammebene enthält:

<Project Sdk="Microsoft.NET.Sdk.Web">
    <!-- omitted for brevity -->
</Project>

Das Sdk-Attribut des vorhergehenden <Project>-Elements importiert die Eigenschaften und Ziele von MSBuild aus $(MSBuildSDKsPath)\Microsoft.NET.Sdk.Web\Sdk\Sdk.reps bzw. $(MSBuildSDKsPath)\Microsoft.NET.Sdk.Web\Sdk. Der Standardspeicherort für $(MSBuildSDKsPath) (mit Visual Studio 2019 Enterprise) ist der Ordner %programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks.

Microsoft.NET.Sdk.Web (Web-SDK) hängt von anderen SDKs ab, einschließlich Microsoft.NET.Sdk (.NET Core SDK) und Microsoft.NET.Sdk.Razor (Razor SDK). Die MSBuild-Eigenschaften und -Ziele, die jedem abhängigen SDK zugeordnet sind, werden importiert. Veröffentlichungsziele importieren basierend auf der verwendeten Veröffentlichungsmethode die entsprechende Gruppe von Zielen.

Wenn in MSBuild oder Visual Studio ein Projekt geladen wird, werden die folgenden Aktionen auf hoher Ebene ausgeführt:

• Erstellen des Projekts
• Berechnen der zu veröffentlichenden Dateien
• Veröffentlichen der Dateien auf dem Ziel

Berechnen der Projektelemente

Wenn das Projekt geladen ist, werden die MSBuild-Projektelemente (Dateien) berechnet. Der Elementtyp bestimmt, wie die Datei verarbeitet wird. Standardmäßig sind .cs-Dateien in der Compile-Elementliste enthalten. Dateien in der Compile-Elementliste werden kompiliert.

Die Content-Elementliste enthält Dateien, die zusätzlich zu den Buildausgaben veröffentlicht werden. Standardmäßig sind Dateien, die mit den Mustern wwwroot\**, **\*.config und **\*.json übereinstimmen, in der Elementliste Content enthalten. Das wwwroot\** Globmuster stimmt z. B. mit allen Dateien im wwwroot-Ordner und in dessen Unterordnern überein.

Das Web-SDK importiert das Razor SDK. Demzufolge sind Dateien, die mit den Mustern **\*.cshtml und **\*.razor übereinstimmen, in der Elementliste Content enthalten.

Um eine Datei explizit der Veröffentlichungsliste hinzuzufügen, fügen Sie die Datei, wie im Abschnitt Includedateien gezeigt, direkt der .csproj-Datei hinzu.

Wenn Sie auf die Schaltfläche Veröffentlichen in Visual Studio klicken oder aus der Befehlszeile veröffentlichen:

• Die Eigenschaften und Elemente werden berechnet (die Dateien, die für den Build benötigt werden).
• Nur Visual Studio: NuGet-Pakete werden wiederhergestellt. (Die Wiederherstellung muss explizit vom Benutzer auf der CLI durchgeführt werden.)
• Das Projekt wird erstellt.
• Die zu veröffentlichenden Elemente werden berechnet (die Dateien, die für die Veröffentlichung benötigt werden).
• Das Projekt wird veröffentlicht (die berechneten Dateien werden in das Veröffentlichungsziel kopiert).

Wenn ein ASP.NET Core-Projekt auf Microsoft.NET.Sdk.Web in der Projektdatei verweist, wird eine app_offline.htm-Datei im Stammverzeichnis des Verzeichnisses der Web-App abgelegt. Wenn die Datei vorhanden ist, fährt das ASP.NET Core Module die App ordnungsgemäß herunter und verarbeitet die Datei app_offline.htm während der Bereitstellung. Weitere Informationen finden Sie unter Konfigurationsreferenz für das ASP.NET Core-Modul.

Grundlegendes zur Veröffentlichung über die Befehlszeile

Die Veröffentlichung über die Befehlszeile funktioniert auf allen von .NET Core unterstützten Plattformen und setzt Visual Studio nicht voraus. In den folgenden Beispielen wird der Befehl dotnet publish der .NET CLI im Projektverzeichnis ausgeführt (das die Datei .csproj enthält). Wenn der Projektordner nicht das aktuelle Arbeitsverzeichnis ist, übergeben Sie den Projektdateipfad explizit. Zum Beispiel:

dotnet publish C:\Webs\Web1

Führen Sie die folgenden Befehle zum Erstellen und Veröffentlichen eine Web-App aus:

dotnet new mvc
dotnet publish

Der Befehl dotnet publish erzeugt eine Abwandlung der folgenden Ausgabe:

C:\Webs\Web1>dotnet publish
Microsoft (R) Build Engine version {VERSION} for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 36.81 ms for C:\Webs\Web1\Web1.csproj.
  Web1 -> C:\Webs\Web1\bin\Debug\{TARGET FRAMEWORK MONIKER}\Web1.dll
  Web1 -> C:\Webs\Web1\bin\Debug\{TARGET FRAMEWORK MONIKER}\Web1.Views.dll
  Web1 -> C:\Webs\Web1\bin\Debug\{TARGET FRAMEWORK MONIKER}\publish\

Das Standardformat des Veröffentlichungsordners lautet bin\Debug\{TARGET FRAMEWORK MONIKER}\publish\. Beispiel: bin\Debug\netcoreapp2.2\publish\.

Der folgende Befehl gibt einen Release-Build und das Veröffentlichungsverzeichnis an:

dotnet publish -c Release -o C:\MyWebs\test

Der Befehl dotnet publish ruft MSBuild auf, welches das Publish-Ziel aufruft. Alle Parameter, die an dotnet publish übergeben werden, werden an MSBuild übergeben. Die Parameter -c und -o verweisen auf die MSBuild-Eigenschaften Configuration bzw. OutputPath.

MSBuild-Eigenschaften können mithilfe eines der folgenden Formate übergeben werden:

• -p:<NAME>=<VALUE>
• /p:<NAME>=<VALUE>

Der folgende Befehl veröffentlicht z. B. einen Release-Build in einer Netzwerkfreigabe. Die Netzwerkfreigabe wird durch führende Schrägstriche ( //r8/ ) angegeben und funktioniert auf allen Plattformen, die von .NET Core unterstützt werden.

dotnet publish -c Release /p:PublishDir=//r8/release/AdminWeb

Versichern Sie sich, dass die veröffentlichte App für die Bereitstellung nicht ausgeführt wird. Die Dateien im Ordner publish sind gesperrt, wenn die App ausgeführt wird. Die Bereitstellung kann nicht erfolgen, da die gesperrten Dateien nicht kopiert werden können.

Veröffentlichungsprofile

In diesem Abschnitt wird Visual Studio 2019 oder höher verwendet, um ein Veröffentlichungsprofil zu erstellen. Nachdem das Profil erstellt ist, ist Veröffentlichung aus Visual Studio oder über die Befehlszeile möglich. Veröffentlichungsprofile können den Veröffentlichungsprozess vereinfachen, und eine beliebige Anzahl von Profilen kann vorhanden sein.

Erstellen Sie ein Veröffentlichungsprofil in Visual Studio durch Auswahl eines der folgenden Pfade:

• Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie Veröffentlichen aus.
• Wählen Sie {PROJEKTNAME} veröffentlichen im Menü Build aus.

Die Registerkarte Veröffentlichen der Seite für App-Funktionen wird angezeigt. Wenn das Projekt kein Veröffentlichungsprofil enthält, wird die Seite Veröffentlichungsziel auswählen angezeigt. Sie können aus den folgenden Veröffentlichungszielen wählen:

• Azure App Service
• Azure App Service für Linux
• Azure Virtual Machines
• Ordner
• IIS, FTP, Web Deploy (für einen beliebigen Webserver)
• Profil importieren

Unter Übersicht über die Bereitstellung in Visual Studio erfahren Sie, wie Sie das ideale Veröffentlichungsziel bestimmen.

Wenn Ordner als Veröffentlichungsziel ausgewählt ist, geben Sie einen Ordnerpfad ein, um die veröffentlichten Objekte zu speichern. Der Standardordnerpfad lautet bin\{PROJECT CONFIGURATION}\{TARGET FRAMEWORK MONIKER}\publish\. Beispiel: bin\Release\netcoreapp2.2\publish\. Klicken Sie auf die Schaltfläche Profil erstellen, um den Vorgang abzuschließen.

Sobald ein Veröffentlichungsprofil erstellt wurde, ändert sich der Inhalt der Registerkarte Veröffentlichen. Das neu erstellte Profil wird in einer Dropdownliste angezeigt. Klicken Sie unter der Dropdownliste auf Neues Profil erstellen, um ein weiteres neues Profil zu erstellen.

Das Visual Studio-Veröffentlichungstool erstellt die MSBuild-Datei Properties/PublishProfiles/{PROFILNAME}.pubxml, in der das Veröffentlichungsprofil beschrieben wird. Die PUBXML-Datei:

• enthält Veröffentlichungskonfigurationseinstellungen und wird vom Veröffentlichungsprozess verwendet.
• kann geändert werden, um den Build- und Veröffentlichungsprozess anzupassen.

Beim Veröffentlichen in einem Azure-Ziel enthält die PUBXML-Datei Ihre Azure-Abonnement-ID. Bei diesem Zieltyp wird vom Hinzufügen der Datei zur Quellkontrolle abgeraten. Beim Veröffentlichen auf einem Nicht-Azure-Ziel kann die PUBXML-Datei eingecheckt werden.

Vertrauliche Informationen (z.B. das Kennwort für die Veröffentlichung) werden pro Benutzer/Computer verschlüsselt. Sie werden in der Datei Properties/PublishProfiles/{PROFILNAME}.pubxml.user gespeichert. Da diese Datei vertrauliche Informationen enthalten kann, sollte sie nicht in die Quellverwaltung eingecheckt werden.

Einen Überblick über das Veröffentlichen einer ASP.NET Core-Web-App finden Sie unter Hosten und Bereitstellen von ASP.NET Core. Die MSBuild-Tasks und -Ziele, die zum Veröffentlichen einer ASP.NET Core-Web-App erforderlich sind, sind als Open-Source-Code im Repository dotnet/websdk verfügbar.

Die folgenden Befehle können Ordner, MSDeploy und Kudu-Veröffentlichungsprofile verwenden. Da MSDeploy nicht plattformübergreifend unterstützt wird, werden die folgenden MSDeploy-Optionen nur unter Windows unterstützt:

Ordner (funktioniert plattformübergreifend):

dotnet publish WebApplication.csproj /p:PublishProfile=<FolderProfileName>

dotnet build WebApplication.csproj /p:DeployOnBuild=true /p:PublishProfile=<FolderProfileName>

MSDeploy:

dotnet publish WebApplication.csproj /p:PublishProfile=<MsDeployProfileName> /p:Password=<DeploymentPassword>

dotnet build WebApplication.csproj /p:DeployOnBuild=true /p:PublishProfile=<MsDeployProfileName> /p:Password=<DeploymentPassword>

MSDeploy-Paket:

dotnet publish WebApplication.csproj /p:PublishProfile=<MsDeployPackageProfileName>

dotnet build WebApplication.csproj /p:DeployOnBuild=true /p:PublishProfile=<MsDeployPackageProfileName>

In den vorherigen Beispielen:

• dotnet publish und dotnet build unterstützen Kudu-APIs zur Veröffentlichung in Azure von jeder Plattform aus. Die Visual Studio-Veröffentlichung unterstützt die Kudu-APIs, wird für die plattformübergreifende Veröffentlichung in Azure aber vom WebSDK unterstützt.
• Übergeben Sie DeployOnBuild nicht an den dotnet publish-Befehl.

Weitere Informationen finden Sie unter Microsoft.NET.Sdk.Publish.

Fügen Sie dem Projektordner Properties/PublishProfiles ein Veröffentlichungsprofil mit folgendem Inhalt hinzu:

<Project>
  <PropertyGroup>
    <PublishProtocol>Kudu</PublishProtocol>
    <PublishSiteName>nodewebapp</PublishSiteName>
    <UserName>username</UserName>
    <Password>password</Password>
  </PropertyGroup>
</Project>

Beispiel für Ordnerveröffentlichung

Verwenden Sie einen der folgenden Befehle, wenn Sie mit einem Profil namens FolderProfile veröffentlichen:

dotnet publish /p:Configuration=Release /p:PublishProfile=FolderProfile

dotnet build /p:DeployOnBuild=true /p:PublishProfile=FolderProfile

msbuild /p:DeployOnBuild=true /p:PublishProfile=FolderProfile

Der .NET CLI-Befehl dotnet build ruft msbuild auf, um den Build- und Veröffentlichungsprozess auszuführen. Die Befehle dotnet build und msbuild sind bei der Übergabe eines Ordnerprofils gleichwertig. Wenn Sie msbuild direkt in Windows aufrufen, wird die .NET Framework-Version von MSBuild verwendet. Wenn Sie dotnet build in einem Profil ohne Ordner aufrufen:

• wird das msbuild-Objekt aufgerufen, das MSDeploy verwendet.
• führt dies zu einem Fehler (auch unter Windows). Rufen Sie msbuild direkt auf, um eine Veröffentlichung mit einem Profil ohne Ordner durchzuführen.

Der folgende Ordner „Veröffentlichungsprofil“ wurde mit Visual Studio erstellt und veröffentlicht in eine Netzwerkfreigabe.

<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project.
You can customize the behavior of this process by editing this 
MSBuild file.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <PublishProvider>FileSystem</PublishProvider>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <PublishFramework>netcoreapp1.1</PublishFramework>
    <ProjectGuid>c30c453c-312e-40c4-aec9-394a145dee0b</ProjectGuid>
    <publishUrl>\\r8\Release\AdminWeb</publishUrl>
    <DeleteExistingFiles>False</DeleteExistingFiles>
  </PropertyGroup>
</Project>

Im vorherigen Beispiel:

• Die Eigenschaft <ExcludeApp_Data> ist nur vorhanden, um die XML-Schemaanforderung zu erfüllen. Die Eigenschaft <ExcludeApp_Data> wirkt sich nicht auf den Veröffentlichungsprozess aus, auch wenn es den Ordner App_Data am Projektstamm gibt. Der Ordner App_Data wird genauso wie in ASP.NET 4.x-Projekten behandelt.
• Die <LastUsedBuildConfiguration>-Eigenschaft ist auf Release festgelegt. Bei der Veröffentlichung von Visual Studio wird der <LastUsedBuildConfiguration>-Wert mithilfe des Werts festgelegt, der beim Starten des Veröffentlichungsprozesses vorliegt. <LastUsedBuildConfiguration> ist ein Sonderfall und sollte nicht in einer importierten MSBuild-Datei überschrieben werden. Diese Eigenschaft kann aber über die Befehlszeile mit einer der folgenden Vorgehensweisen überschrieben werden.

  • Verwenden der .NET-CLI:

    dotnet publish /p:Configuration=Release /p:PublishProfile=FolderProfile
    

    dotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
    

  • Verwenden von MSBuild:

    msbuild /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
    

Veröffentlichen auf einen MSDeploy-Endpunkt von der Befehlszeile

Im folgenden Beispiel wird von Visual Studio eine ASP.NET Core-Web-App namens AzureWebApp erstellt. Ein Azure Apps-Veröffentlichungsprofil wird mit Visual Studio hinzugefügt. Weitere Informationen zum Erstellen eines Profils finden Sie unter im Abschnitt Veröffentlichungsprofile.

Um eine App mit einem Veröffentlichungsprofil bereitzustellen, führen Sie den Befehl msbuild an einer Developer-Eingabeaufforderung von Visual Studio aus. Die Eingabeaufforderung finden Sie im Ordner Visual Studio im Start-Menü auf der Windows-Taskleiste. Für einfacheren Zugriff können Sie die Eingabeaufforderung zum Menü Tools in Visual Studio hinzufügen. Weitere Informationen finden Sie unter Developer-Eingabeaufforderung für Visual Studio.

MSBuild hat die folgende Befehlssyntax:

msbuild {PATH} 
    /p:DeployOnBuild=true 
    /p:PublishProfile={PROFILE} 
    /p:Username={USERNAME} 
    /p:Password={PASSWORD}

• {PATH}: Der Pfad zur Projektdatei der App.
• {PROFILE}: Der Name des Veröffentlichungsprofils.
• {USERNAME}: Der MSDeploy-Benutzername. {USERNAME} befindet sich im Veröffentlichungsprofil.
• {PASSWORD}: Das MSDeploy-Kennwort. {PASSWORD} befindet sich in der Datei {PROFILE}.PublishSettings. Laden Sie die Datei .PublishSettings von einem der folgenden Speicherorte herunter:
  • Projektmappen-Explorer: Wählen Sie Ansicht>Cloud-Explorer aus. Stellen Sie eine Verbindung mit Ihrem Azure-Abonnement her. Öffnen Sie App Services. Klicken Sie mit der rechten Maustaste auf die App. Wählen Sie Veröffentlichungsprofil herunterladen aus.
  • Azure-Portal: Wählen Sie Veröffentlichungsprofil abrufen im Bereich Übersicht der Web-App aus.

Im folgenden Beispiel wird ein Veröffentlichungsprofil namens AzureWebApp – Web Deploy verwendet:

msbuild "AzureWebApp.csproj" 
    /p:DeployOnBuild=true 
    /p:PublishProfile="AzureWebApp - Web Deploy" 
    /p:Username="$AzureWebApp" 
    /p:Password=".........."

Ein Veröffentlichungsprofil kann auch mit dem .NET CLI-Befehl dotnet msbuild über eine Windows-Befehlsshell verwendet werden:

dotnet msbuild "AzureWebApp.csproj"
    /p:DeployOnBuild=true 
    /p:PublishProfile="AzureWebApp - Web Deploy" 
    /p:Username="$AzureWebApp" 
    /p:Password=".........."

Wichtig

Der Befehl dotnet msbuild ist plattformübergreifend verfügbar und kann ASP.NET Core-Apps unter macOS und Linux kompilieren. Allerdings kann MSBuild unter macOS und Linux keine Apps in Azure oder an einem anderen MSDeploy-Endpunkt bereitstellen.

Festlegen der Umgebung

Beziehen Sie die <EnvironmentName>-Eigenschaft in das Veröffentlichungsprofil (PUBXML) oder die Projektdatei ein, um die Umgebung der App festzulegen:

<PropertyGroup>
  <EnvironmentName>Development</EnvironmentName>
</PropertyGroup>

Wenn Sie web.config-Transformationen benötigen (z. B. Umgebungsvariablen basierend auf der Konfiguration, dem Profil oder der Umgebung), finden Sie weitere Informationen unter Transformieren von „web.config“.

Dateien ausschließen

Wenn Sie ASP.NET Core-Web-Apps veröffentlichen, sind die folgenden Ressourcen enthalten:

• Build-Artefakte
• Ordner und Dateien, die den folgenden Globmustern entsprechen:
  • **\*.config (Beispiel: web.config)
  • **\*.json (z. B. appsettings.json)
  • wwwroot\**

MSBuild unterstützt Globmuster. Das folgende <Content>-Element unterdrückt beispielsweise das Kopieren von Textdateien (TXT) aus dem Ordner wwwroot/content und allen seinen Unterordnern:

<ItemGroup>
  <Content Update="wwwroot/content/**/*.txt" CopyToPublishDirectory="Never" />
</ItemGroup>

Das vorstehende Markup kann einem Veröffentlichungsprofil oder der .csproj-Datei hinzugefügt werden. Wenn es zu der .csproj-Datei hinzugefügt wird, wird die Regel zu allen Veröffentlichungsprofilen im Projekt hinzugefügt.

Das folgende <MsDeploySkipRules>-Element schließt alle Dateien aus dem Ordner wwwroot\content aus:

<ItemGroup>
  <MsDeploySkipRules Include="CustomSkipFolder">
    <ObjectName>dirPath</ObjectName>
    <AbsolutePath>wwwroot\\content</AbsolutePath>
  </MsDeploySkipRules>
</ItemGroup>

<MsDeploySkipRules> löscht die Skip-Ziele von der Bereitstellungsseite nicht. <Content>-Zieldateien und -ordner werden von der Bereitstellungsseite gelöscht. Nehmen wir beispielsweise an, dass eine bereitgestellte Web-App folgende Dateien enthält:

• Views/Home/About1.cshtml
• Views/Home/About2.cshtml
• Views/Home/About3.cshtml

Wenn folgende <MsDeploySkipRules>-Elemente hinzugefügt werden, würden diese Dateien nicht von der Bereitstellungsseite gelöscht werden.

<ItemGroup>
  <MsDeploySkipRules Include="CustomSkipFile">
    <ObjectName>filePath</ObjectName>
    <AbsolutePath>Views\\Home\\About1.cshtml</AbsolutePath>
  </MsDeploySkipRules>

  <MsDeploySkipRules Include="CustomSkipFile">
    <ObjectName>filePath</ObjectName>
    <AbsolutePath>Views\\Home\\About2.cshtml</AbsolutePath>
  </MsDeploySkipRules>

  <MsDeploySkipRules Include="CustomSkipFile">
    <ObjectName>filePath</ObjectName>
    <AbsolutePath>Views\\Home\\About3.cshtml</AbsolutePath>
  </MsDeploySkipRules>
</ItemGroup>

Die vorangehenden <MsDeploySkipRules>-Elemente verhindern, dass übersprungene Dateien bereitgestellt werden. Diese Dateien werden nach ihrer Bereitstellung nicht gelöscht.

Das folgende <Content>-Element löscht die Zieldateien auf der Bereitstellungsseite:

<ItemGroup>
  <Content Update="Views/Home/About?.cshtml" CopyToPublishDirectory="Never" />
</ItemGroup>

Die Bereitstellung über die Befehlszeile mit dem vorangehenden <Content>-Element gibt eine Abwandlung der folgenden Ausgabe aus:

MSDeployPublish:
  Starting Web deployment task from source: manifest(C:\Webs\Web1\obj\Release\{TARGET FRAMEWORK MONIKER}\PubTmp\Web1.SourceManifest.
  xml) to Destination: auto().
  Deleting file (Web11112\Views\Home\About1.cshtml).
  Deleting file (Web11112\Views\Home\About2.cshtml).
  Deleting file (Web11112\Views\Home\About3.cshtml).
  Updating file (Web11112\web.config).
  Updating file (Web11112\Web1.deps.json).
  Updating file (Web11112\Web1.dll).
  Updating file (Web11112\Web1.pdb).
  Updating file (Web11112\Web1.runtimeconfig.json).
  Successfully executed Web deployment task.
  Publish Succeeded.
Done Building Project "C:\Webs\Web1\Web1.csproj" (default targets).

Includedateien

Die folgenden Abschnitte beschreiben verschiedene Ansätze für das Einbeziehen von Dateien beim Veröffentlichen. Im Abschnitt Allgemeines Einbeziehen von Dateien wird das Element DotNetPublishFiles verwendet, das von einer Veröffentlichungszieledatei im Web-SDK bereitgestellt wird. Im Abschnitt Selektives Einbeziehen von Dateien wird das Element ResolvedFileToPublish verwendet, das von einer Veröffentlichungszieledatei im .NET Core SDK bereitgestellt wird. Weil das Web-SDK vom .NET Core SDK abhängig ist, können beide Elemente in einem ASP.NET Core-Projekt verwendet werden.

Allgemeines Einbeziehen von Dateien

Das Element <ItemGroup> im folgenden Beispiel veranschaulicht das Kopieren eines Ordners, der sich außerhalb des Projektverzeichnisses befindet, in einen Ordner der veröffentlichten Website. Alle Dateien, die dem <ItemGroup>-Element im folgenden Markup-Ausschnitt hinzugefügt werden, werden standardmäßig einbezogen.

<ItemGroup>
  <_CustomFiles Include="$(MSBuildProjectDirectory)/../images/**/*" />
  <DotNetPublishFiles Include="@(_CustomFiles)">
    <DestinationRelativePath>wwwroot/images/%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
  </DotNetPublishFiles>
</ItemGroup>

Das obenstehende Markup:

• Kann der .csproj-Datei oder dem Veröffentlichungsprofil hinzugefügt werden. Wenn es der .csproj-Datei hinzugefügt wird, wird es in jedes Veröffentlichungsprofil im Projekt eingeschlossen.
• Deklariert ein _CustomFiles-Element, um Dateien zu speichern, die mit dem Globmuster des Include-Attributs übereinstimmen. Der Ordner images, auf den im Muster verwiesen wird, befindet sich außerhalb des Projektverzeichnisses. Die reservierte Eigenschaft$(MSBuildProjectDirectory) löst den absoluten Pfad der Projektdatei auf.
• Stellt eine Liste der zu verarbeitenden DotNetPublishFiles-Elemente bereit. Das <DestinationRelativePath>-Element des Elements ist standardmäßig leer. Der Standardwert wird im Markup überschrieben und verwendet bekannte Elementmetadaten wie z. B. %(RecursiveDir). Der innere Text stellt den Ordner wwwroot/images der veröffentlichten Website dar.

Selektives Einbeziehen von Dateien

Der markierte Markup-Code im folgenden Beispiel veranschaulicht Folgendes:

• Das Kopieren einer Datei, die sich außerhalb eines Projekts befindet, in den wwwroot-Ordner der veröffentlichten Website. Der Dateiname ReadMe2.md wird beibehalten.
• Ausschließen des Ordners wwwroot\Content.
• Ausschließen von Views\Home\About2.cshtml.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" 
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <PublishProvider>FileSystem</PublishProvider>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <PublishFramework />
    <ProjectGuid>afa9f185-7ce0-4935-9da1-ab676229d68a</ProjectGuid>
    <publishUrl>bin\Release\PublishOutput</publishUrl>
    <DeleteExistingFiles>False</DeleteExistingFiles>
  </PropertyGroup>
  <ItemGroup>
    <ResolvedFileToPublish Include="..\ReadMe2.md">
      <RelativePath>wwwroot\ReadMe2.md</RelativePath>
    </ResolvedFileToPublish>

    <Content Update="wwwroot\Content\**\*" CopyToPublishDirectory="Never" />
    <Content Update="Views\Home\About2.cshtml" CopyToPublishDirectory="Never" />
  </ItemGroup>
</Project>

Im vorherigen Beispiel wird das Element ResolvedFileToPublish verwendet, dessen Standardverhalten darin besteht, die im Include-Attribut bereitgestellten Dateien in die veröffentlichte Website zu kopieren. Sie können das Standardverhalten überschreiben, indem Sie ein untergeordnetes <CopyToPublishDirectory>-Element mit dem inneren Text Never oder PreserveNewest einbeziehen. Zum Beispiel:

<ResolvedFileToPublish Include="..\ReadMe2.md">
  <RelativePath>wwwroot\ReadMe2.md</RelativePath>
  <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</ResolvedFileToPublish>

Weitere Bereitstellungsbeispiele finden Sie in der README-Datei des Web SDK.

Führen Sie ein Ziel vor oder nach der Veröffentlichung aus.

Die integrierten Ziele BeforePublish und AfterPublish führen ein Ziel vor oder nach dem Veröffentlichungsziel aus. Fügen Sie die folgenden Elemente dem Veröffentlichungsprofil hinzu, um Konsolenmeldungen vor und nach der Veröffentlichung zu protokollieren:

<Target Name="CustomActionsBeforePublish" BeforeTargets="BeforePublish">
    <Message Text="Inside BeforePublish" Importance="high" />
  </Target>
  <Target Name="CustomActionsAfterPublish" AfterTargets="AfterPublish">
    <Message Text="Inside AfterPublish" Importance="high" />
</Target>

Veröffentlichen auf einem Server unter Verwendung eines nicht vertrauenswürdigen Zertifikats

Fügen Sie die Eigenschaft <AllowUntrustedCertificate> mit dem Wert True auf dem Veröffentlichungsprofil hinzu:

<PropertyGroup>
  <AllowUntrustedCertificate>True</AllowUntrustedCertificate>
</PropertyGroup>

Der Kudu-Dienst

Verwenden Sie zum Anzeigen der Dateien in einer Web-App-Bereitstellung von Azure App Service den Kudu-Dienst. Fügen Sie das Token scm an den Namen Ihrer Web-App an. Zum Beispiel:

URL	Ergebnis
http://mysite.azurewebsites.net/	Webanwendung
http://mysite.scm.azurewebsites.net/	Der Kudu-Dienst

Wählen Sie das Menüelement Debugging-Konsole, aus, um Dateien anzuzeigen, zu bearbeiten, zu löschen oder hinzuzufügen.

Zusätzliche Ressourcen

• Web Deploy (MSDeploy) vereinfacht die Bereitstellung von Web-Apps und Websites auf IIS-Servern.
• GitHub-Repository für Web SDK: Probleme melden und Features für die Bereitstellung anfordern.
• Transformieren von web.config