Profils de publication Visual Studio (.pubxml) pour le déploiement d’applications ASP.NET Core
Remarque
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 de cet article.
Avertissement
Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.
Important
Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.
Pour la version actuelle, consultez la version .NET 8 de cet article.
De Sayed Ibrahim Hashimi et Rick Anderson
Ce document traite de l’utilisation de Visual Studio 2019 ou supérieur pour créer et utiliser des profils de publication. Les profils de publication créés avec Visual Studio peuvent être utilisés avec MSBuild et Visual Studio. Pour obtenir des instructions de publication sur Azure, consultez Publier une application ASP.NET Core sur Azure à l’aide de Visual Studio.
La commande dotnet new mvc
produit un fichier projet contenant l’élément <Project> suivant de niveau racine :
<Project Sdk="Microsoft.NET.Sdk.Web">
<!-- omitted for brevity -->
</Project>
L’attribut Sdk
de l’élément <Project>
précédent importe les propriétés et cibles de MSBuild à partir de $(MSBuildSDKsPath)\Microsoft.NET.Sdk.Web\Sdk\Sdk.props et $(MSBuildSDKsPath)\Microsoft.NET.Sdk.Web\Sdk\Sdk.targets, respectivement. L’emplacement par défaut de $(MSBuildSDKsPath)
(avec Visual Studio 2019 Enterprise) est le dossier %programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks.
Microsoft.NET.Sdk.Web
(kit SDK Web) dépend d’autres kits SDK, dont Microsoft.NET.Sdk
(kit SDK .NET Core) et Microsoft.NET.Sdk.Razor
(kit SDK Razor). Les propriétés et cibles MSBuild associées à chaque kit de développement logiciel sont importées. Les cibles de publication importent le bon ensemble de cibles en fonction de la méthode de publication utilisée.
Quand MSBuild ou Visual Studio charge un projet, les actions principales suivantes se produisent :
- Génération du projet
- Calcul des fichiers à publier
- Publication des fichiers sur la destination
Calcul des éléments du projet
Quand le projet est chargé, les éléments du projet MSBuild (fichiers) sont calculés. Le type d’élément détermine la façon dont le fichier est traité. Par défaut, les fichiers .cs
sont inclus dans la liste d’éléments Compile
. Les fichiers dans la liste d’éléments Compile
sont compilés.
La liste d’éléments Content
contient des fichiers qui sont publiés en plus des sorties de génération. Par défaut, les fichiers qui correspondent aux modèles wwwroot\**
, **\*.config
et **\*.json
sont inclus dans l’élément Content
. Par exemple, le modèle d’utilisation des caractères génériques wwwroot\**
correspond à tous les fichiers dans le dossier wwwroot et ses sous-dossiers.
Le kit SDK Web importe le kit SDK Razor. Par conséquent, les fichiers correspondant aux modèles **\*.cshtml
et **\*.razor
sont également inclus dans la liste d’éléments Content
.
Le kit SDK Web importe le kit SDK Razor. Par conséquent, les fichiers correspondant au modèle **\*.cshtml
sont également inclus dans la liste d’éléments Content
.
Pour ajouter explicitement un fichier à la liste de publication, ajoutez-le directement au fichier .csproj
comme indiqué dans la section Inclure des fichiers.
Quand vous sélectionnez le bouton Publier dans Visual Studio ou quand vous publiez à partir de la ligne de commande :
- Les éléments/propriétés sont calculés (il s’agit des fichiers nécessaires à la génération).
- Visual Studio uniquement : les packages NuGet sont restaurés. (La restauration doit être explicite par l’utilisateur sur l’interface CLI.)
- Le projet est généré.
- Les éléments de publication sont calculés (il s’agit des fichiers nécessaires à la publication).
- Le projet est publié (les fichiers calculés sont copiés sur la destination de publication).
Quand un projet ASP.NET Core référence Microsoft.NET.Sdk.Web
dans le fichier projet, un fichier app_offline.htm
est placé à la racine du répertoire de l’application Web. Quand le fichier est présent, le module ASP.NET Core arrête l’application de manière appropriée, et met à disposition le fichier app_offline.htm
durant le déploiement. Pour plus d’informations, consultez les Informations de référence sur la configuration du module ASP.NET Core.
Publication de base à partir d’une ligne de commande
La publication à partir d’une ligne de commande fonctionne sur toutes les plateformes .NET Core prises en charge et ne nécessite pas Visual Studio. Dans les exemples suivants, la commande dotnet publish de l’interface CLI .NET est exécutée à partir du répertoire de projet (qui contient le fichier .csproj
). Si le dossier du projet n’est pas le répertoire de travail actuel, passez explicitement le chemin du fichier projet. Par exemple :
dotnet publish C:\Webs\Web1
Exécutez les commandes suivantes pour créer et publier une application web :
dotnet new mvc
dotnet publish
La commande dotnet publish
produit une variante de la sortie suivante :
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\
Le format par défaut du dossier de publication est bin\Debug\{MONIKER DE FRAMEWORK CIBLE}\publish\. Par exemple, bin\Debug\netcoreapp2.2\publish\.
La commande suivante spécifie une build Release
et le répertoire de publication :
dotnet publish -c Release -o C:\MyWebs\test
La commande dotnet publish
appelle MSBuild, qui appelle la cible de Publish
. Les paramètres passés à dotnet publish
sont passés à MSBuild. Les paramètres -c
et -o
correspondent aux propriétés Configuration
et OutputPath
de MSBuild, respectivement.
Les propriétés MSBuild peuvent être passées à l’aide de l’un des formats suivants :
-p:<NAME>=<VALUE>
/p:<NAME>=<VALUE>
Par exemple, la commande suivante publie une build Release
sur un partage réseau. Le partage réseau est spécifié avec des barres obliques (//r8/) et fonctionne sur toutes les plateformes .NET Core prises en charge.
dotnet publish -c Release /p:PublishDir=//r8/release/AdminWeb
Vérifiez que l’application publiée pour le déploiement n’est pas en cours d’exécution. Les fichiers dans le dossier publish sont verrouillés quand l’application est en cours d’exécution. Le déploiement ne peut pas se produire car les fichiers verrouillés ne peuvent pas être copiés.
Profils de publication
Cette section utilise Visual Studio 2019 ou supérieur pour créer un profil de publication. Une fois le profil créé, la publication à partir de Visual Studio ou de la ligne de commande est disponible. Les profils de publication peuvent simplifier le processus de publication, et n’importe quel nombre de profils peut exister.
Créez un profil de publication dans Visual Studio en choisissant l’une des méthodes suivantes :
- Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet, puis sélectionnez Publier.
- Sélectionner Publier {NOM DU PROJET} dans le menu Générer.
L’onglet Publier de la page de fonctionnalités de l’application s’affiche. Si le projet n’a pas de profil de publication, la page Choisir une cible de publication s’affiche. Vous êtes invité à sélectionner une des cibles de publication suivantes :
- Azure App Service
- Azure App Service sur Linux
- Machines virtuelles Azure
- Dossier
- IIS, FTP, Web Deploy (pour n’importe quel serveur web)
- Profil d’importation
Pour déterminer la cible de publication la plus appropriée, consultez Quelles sont les meilleures options de publication pour moi.
Quand la cible de publication Dossier est sélectionné, spécifiez un chemin de dossier pour stocker les ressources publiées. Le chemin du dossier par défaut est bin\{CONFIGURATION DE PROJET}\{MONIKER DE FRAMEWORK CIBLE}\publish\. Par exemple, bin\Release\netcoreapp2.2\publish\. Sélectionnez le bouton Créer un profil pour terminer.
Une fois créé le profil de publication, le contenu de l’onglet Publier change. Le profil créé apparaît dans une liste déroulante. Dans la liste déroulante, sélectionnez Créer un profil pour créer un autre profil.
L’outil de publication de Visual Studio produit un fichier MSBuild Properties/PublishProfiles/{NOM DU PROFIL}.pubxml décrivant le profil de publication. Le fichier .pubxml :
- Contient les paramètres de configuration de publication et est utilisé par le processus de publication.
- Peut être modifié pour personnaliser le processus de génération et de publication.
Dans le cas d’une publication sur une cible Azure, le fichier .pubxml contient l’identificateur de votre abonnement Azure. Avec ce type de cible, nous vous déconseillons d’ajouter ce fichier au contrôle de code source. Dans le cas d’une publication sur une cible non-Azure, nous vous recommandons d’archiver le fichier .pubxml.
Les informations sensibles (telles que le mot de passe de publication) sont chiffrées par utilisateur/machine. Elles sont stockées dans le fichier Properties/PublishProfiles/{NOM DU PROFIL}.pubxml.user. Ce fichier pouvant stocker des informations sensibles, il ne doit pas être archivé dans le contrôle de code source.
Pour obtenir une vue d’ensemble expliquant comment publier une application Web ASP.NET Core, consultez Héberger et déployer ASP.NET Core. Les tâches et cibles MSBuild nécessaires pour publier une application web ASP.NET Core sont en open source dans le dépôt dotnet/websdk.
Les commandes suivantes peuvent utiliser les profils de publication de dossier, MSDeploy et Kudu. Comme MSDeploy ne prend pas en charge plusieurs plateformes, les options MSDeploy suivantes sont prises en charge uniquement sur Windows.
Dossier (fonctionne sur plusieurs plateformes) :
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>
Package MSDeploy :
dotnet publish WebApplication.csproj /p:PublishProfile=<MsDeployPackageProfileName>
dotnet build WebApplication.csproj /p:DeployOnBuild=true /p:PublishProfile=<MsDeployPackageProfileName>
Dans les exemples précédents :
dotnet publish
etdotnet build
prennent en charge les API Kudu pour publier sur Azure à partir de n’importe quelle plateforme. La publication Visual Studio prend en charge les API Kudu, mais avec la prise en charge par WebSDK pour la publication multiplateforme sur Azure.- Ne transmettez pas
DeployOnBuild
à la commandedotnet publish
.
Pour plus d’informations, consultez Microsoft.NET.Sdk.Publish.
Ajoutez un profil de publication au dossier Properties/PublishProfiles avec le contenu suivant :
<Project>
<PropertyGroup>
<PublishProtocol>Kudu</PublishProtocol>
<PublishSiteName>nodewebapp</PublishSiteName>
<UserName>username</UserName>
<Password>password</Password>
</PropertyGroup>
</Project>
Exemple de publication de dossier
Lors de la publication avec un profil nommé FolderProfile, utilisez l’une des commandes suivantes :
dotnet publish /p:Configuration=Release /p:PublishProfile=FolderProfile
dotnet build /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
msbuild /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
La commande dotnet build de l’interface CLI .NET appelle msbuild
pour exécuter les processus de génération et de publication. Les commandes dotnet build
et msbuild
sont équivalentes quand vous passez un profil de dossier. Quand vous appelez msbuild
directement sur Windows, la version MSBuild du .NET Framework est utilisée. L’appel de dotnet build
sur un profil autre qu’un dossier :
- Appelle
msbuild
, qui utilise MSDeploy. - Entraîne un échec (même en cas d’exécution sur Windows). Pour publier avec un profil autre qu’un dossier, appelez
msbuild
directement.
Le profil de publication de dossier suivant a été créé avec Visual Studio et publie sur un partage réseau :
<?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>
Dans l’exemple précédent :
- La propriété
<ExcludeApp_Data>
est présente simplement pour satisfaire une exigence de schéma XML. La propriété<ExcludeApp_Data>
n’a aucun effet sur le processus de publication, même s’il y a un dossier App_Data à la racine du projet. Le dossier App_Data ne reçoit pas de traitement spécial comme c’est le cas dans les projets ASP.NET 4.x. - La propriété
<LastUsedBuildConfiguration>
est définie surRelease
. En cas de publication à partir de Visual Studio, la valeur de<LastUsedBuildConfiguration>
est définie sur la valeur existante au démarrage du processus de publication. La propriété<LastUsedBuildConfiguration>
est spéciale et ne doit pas être remplacée dans un fichier MSBuild importé. Cette propriété peut, toutefois, être remplacée à partir de la ligne de commande avec l’une des approches suivantes.Utilisation de l’interface CLI .NET :
dotnet publish /p:Configuration=Release /p:PublishProfile=FolderProfile
dotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
À l’aide de MSBuild :
msbuild /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
Publier sur un point de terminaison MSDeploy à partir de la ligne de commande
L’exemple suivant utilise une application web ASP.NET Core créée par Visual Studio et nommée AzureWebApp. Un profil de publication Azure Apps est ajouté avec Visual Studio. Pour plus d’informations sur la création d’un profil, consultez la section profils de publication.
Pour déployer l’application à l’aide d’un profil de publication, exécutez la msbuild
commande à partir d’une invite de commandes développeur Visual Studio. L’invite de commandes est disponible dans le dossier Visual Studio du menu Démarrer sur la barre des tâches Windows. Pour en faciliter accès, vous pouvez ajouter à l’invite de commandes au menu Outils dans Visual Studio. Pour plus d’informations, consultez Invite de commandes développeur pour Visual Studio.
MSBuild utilise la syntaxe de commande suivante :
msbuild {PATH}
/p:DeployOnBuild=true
/p:PublishProfile={PROFILE}
/p:Username={USERNAME}
/p:Password={PASSWORD}
{PATH}
: chemin vers le fichier de projet de l’application.{PROFILE}
: nom du profil de publication.{USERNAME}
: nom d’utilisateur MSDeploy.{USERNAME}
figure dans le profil de publication.{PASSWORD}
: mot de passe MSDeploy. Obtenez le{PASSWORD}
à partir du fichier {PROFIL}.PublishSettings. Téléchargez le fichier .PublishSettings à partir d’un des emplacements suivants :- Explorateur de solutions : sélectionnez Afficher>Cloud Explorer. Connectez-vous avec votre abonnement Azure. Ouvrez App Services. Faites un clic droit sur l’application. Sélectionnez Télecharger un profil de publication.
- Portail Azure : sélectionnez Obtenir le profil de publication dans le panneau Vue d’ensemble de l’application Web.
L’exemple suivant utilise un profil de publication nommé AzureWebApp - Web Deploy:
msbuild "AzureWebApp.csproj"
/p:DeployOnBuild=true
/p:PublishProfile="AzureWebApp - Web Deploy"
/p:Username="$AzureWebApp"
/p:Password=".........."
Un profil de publication peut également être utilisé avec la commande dotnet msbuild de l’interface CLI .NET à partir d’un interpréteur de commandes Windows :
dotnet msbuild "AzureWebApp.csproj"
/p:DeployOnBuild=true
/p:PublishProfile="AzureWebApp - Web Deploy"
/p:Username="$AzureWebApp"
/p:Password=".........."
Important
La commande dotnet msbuild
est une commande multiplateforme pouvant compiler des applications ASP.NET Core sur macOS et Linux. Toutefois, MSBuild sur macOS et Linux n’est pas capable de déployer une application sur Azure ou d’autres points de terminaison MSDeploy.
Définir l’environnement
Incluez la propriété <EnvironmentName>
dans le profil de facturation (.pubxml) ou le fichier projet pour définir l’environnement de l’application :
<PropertyGroup>
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
Si vous avez besoin de transformations web.config (par exemple, définir les variables d’environnement basées sur la configuration, le profil ou l’environnement), consultez Transformer web.config.
Exclure des fichiers
Lors de la publication d’applications web ASP.NET Core, les ressources suivantes sont incluses :
- Artefacts de build
- Les dossiers et fichiers correspondant aux modèles d’utilisation des caractères génériques suivants :
**\*.config
(par exemple web.config)**\*.json
(par exemple,appsettings.json
)wwwroot\**
MSBuild prend en charge les modèles d’utilisation des caractères génériques. Par exemple, l’élément <Content>
suivant supprime la copie des fichiers texte (.txt) dans le dossier wwwroot/content et ses sous-dossiers :
<ItemGroup>
<Content Update="wwwroot/content/**/*.txt" CopyToPublishDirectory="Never" />
</ItemGroup>
Vous pouvez ajouter le balisage précédent à un profil de publication ou au fichier .csproj
. En cas d’ajout au fichier .csproj
, la règle est ajoutée à tous les profils de publication dans le projet.
L’élément <MsDeploySkipRules>
suivant exclut tous les fichiers du dossier wwwroot\content :
<ItemGroup>
<MsDeploySkipRules Include="CustomSkipFolder">
<ObjectName>dirPath</ObjectName>
<AbsolutePath>wwwroot\\content</AbsolutePath>
</MsDeploySkipRules>
</ItemGroup>
<MsDeploySkipRules>
ne supprime pas les cibles skip du site de déploiement. Les dossiers et fichiers ciblés par <Content>
sont supprimés du site de déploiement. Par exemple, supposez qu’une application web déployée avait les fichiers suivants :
Views/Home/About1.cshtml
Views/Home/About2.cshtml
Views/Home/About3.cshtml
Si les éléments <MsDeploySkipRules>
suivants sont ajoutés, ces fichiers ne sont pas supprimés sur le site de déploiement.
<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>
Les éléments <MsDeploySkipRules>
précédents empêchent le déploiement des fichiers skipped. Ces fichiers ne sont pas supprimés une fois déployés.
L’élément <Content>
suivant supprime les fichiers ciblés sur le site de déploiement :
<ItemGroup>
<Content Update="Views/Home/About?.cshtml" CopyToPublishDirectory="Never" />
</ItemGroup>
L’utilisation du déploiement à partir de la ligne de commande avec l’élément <Content>
précédent génère une variante de la sortie suivante :
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).
Fichiers Include
Les sections suivantes décrivent différentes approches pour l’inclusion de fichier au moment de la publication. La section Inclusion de fichier générale utilise l’élément DotNetPublishFiles
, qui est fourni par un fichier de cibles de publication dans le kit SDK Web. La section Inclusion de fichier sélective utilise l’élément ResolvedFileToPublish
, qui est fourni par un fichier de cibles de publication dans le kit SDK .NET Core. Comme le SDK Web dépend du SDK .NET Core, l’élément peut être utilisé dans un projet ASP.NET Core.
Inclusion de fichier générale
L’élément <ItemGroup>
de l’exemple suivant illustre la copie d’un dossier situé en dehors du répertoire de projet dans un dossier du site publié. Les fichiers ajoutés à l’élément <ItemGroup>
du balisage suivant sont inclus par défaut.
<ItemGroup>
<_CustomFiles Include="$(MSBuildProjectDirectory)/../images/**/*" />
<DotNetPublishFiles Include="@(_CustomFiles)">
<DestinationRelativePath>wwwroot/images/%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</DotNetPublishFiles>
</ItemGroup>
Le balisage précédent :
- Peut être ajouté au fichier
.csproj
ou au profil de publication. Si vous l’ajoutez au fichier.csproj
, il est inclus dans chaque profil de publication du projet. - Déclare un élément
_CustomFiles
pour stocker les fichiers qui correspondent au modèle d’utilisation des caractères génériquesInclude
de l’attribut. Le dossier d’images référencé dans le modèle se trouve en dehors du répertoire de projet. Une propriété réservée, nommée$(MSBuildProjectDirectory)
, se traduit par le chemin absolu du fichier projet. - Fournit une liste de fichiers à l’élément
DotNetPublishFiles
. Par défaut, l’élément<DestinationRelativePath>
de l’élément est vide. La valeur par défaut est remplacée dans le balisage et utilise des métadonnées d’éléments connus comme%(RecursiveDir)
. Le texte interne représente le dossier wwwroot/images du site publié.
Inclusion de fichier sélective
Dans l’exemple suivant, le balisage en surbrillance illustre ce qui suit :
- La copie d’un fichier situé en dehors du projet dans le dossier wwwroot du site publié. Le nom de fichier ReadMe2.md est conservé.
- L’exclusion du dossier wwwroot\Content.
- L’exclusion de 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>
L’exemple précédent utilise l’élément ResolvedFileToPublish
, dont le comportement par défaut consiste à toujours copier les fichiers fournis dans l’attribut Include
sur le site publié. Remplacez le comportement par défaut en incluant un élément enfant <CopyToPublishDirectory>
avec le texte interne Never
ou PreserveNewest
. Par exemple :
<ResolvedFileToPublish Include="..\ReadMe2.md">
<RelativePath>wwwroot\ReadMe2.md</RelativePath>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</ResolvedFileToPublish>
Pour voir d’autres exemples de déploiement, consultez le fichier Lisez-moi du kit SDK Web.
Exécuter une cible avant ou après la publication
Les cibles intégrées BeforePublish
et AfterPublish
exécutent une cible avant ou après la cible de publication. Ajoutez les éléments suivants au profil de publication pour journaliser les messages de console avant et après la publication :
<Target Name="CustomActionsBeforePublish" BeforeTargets="BeforePublish">
<Message Text="Inside BeforePublish" Importance="high" />
</Target>
<Target Name="CustomActionsAfterPublish" AfterTargets="AfterPublish">
<Message Text="Inside AfterPublish" Importance="high" />
</Target>
Publier sur un serveur à l’aide d’un certificat non approuvé
Ajoutez la propriété <AllowUntrustedCertificate>
avec la valeur True
au profil de publication :
<PropertyGroup>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
</PropertyGroup>
Le service Kudu
Pour afficher les fichiers dans un déploiement d’application web Azure App Service, utilisez le service Kudu. Ajoutez le jeton scm
au nom de l’application web. Par exemple :
URL | Résultats |
---|---|
http://mysite.azurewebsites.net/ |
Application web |
http://mysite.scm.azurewebsites.net/ |
Service Kudu |
Sélectionnez l’élément de menu Console de débogage pour afficher, modifier, supprimer ou ajouter des fichiers.
Ressources supplémentaires
- Web Deploy (MSDeploy) simplifie le déploiement des applications web et des sites web sur les serveurs IIS.
- Dépôt GitHub du kit SDK Web : problèmes de fichier et fonctionnalités de demande pour le déploiement.
- Transformer web.config
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour