Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Note
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 10 de cet article.
Warning
Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la stratégie de support .NET et .NET Core. Pour la version actuelle, consultez la version .NET 10 de cet article.
De Sayed Ibrahim Hashimi et Rick Anderson
Ce document se concentre sur l’utilisation de Visual Studio 2022 ou version ultérieure 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.
Pour obtenir les informations les plus actuelles et détaillées sur :
- Publication avec Visual Studio, consultez Vue d’ensemble de Visual Studio Publish
- MSBuild, voir MSBuild
- Publication avec MSBuild, consultez Microsoft.NET.Sdk.Publish
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 <Project> de l’élément Sdk 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 pour $(MSBuildSDKsPath) (avec Visual Studio 2022) est le dossier%programfiles%\Microsoft Visual Studio\2022\Preview\MSBuild\Sdks .
Microsoft.NET.Sdk.Web (SDK Web) dépend d’autres SDKs, notamment Microsoft.NET.Sdk (.NET SDK) et Microsoft.NET.Sdk.Razor (Razor SDK). 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érer un 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 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 en ligne de commande fonctionne sur toutes les plateformes prises en charge par .NET 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
Restore complete (0.4s)
Web1 succeeded (9.2s) → bin\Release\net9.0\publish\
Le format de dossier de publication par défaut est bin\Debug\{TARGET FRAMEWORK MONIKER}. Par exemple, bin\Release\net9.0\
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 prises en charge par .NET.
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.
Pour plus d’informations, consultez le fichier README Microsoft.NET.Sdk.Publish.
Publier des profils
Cette section utilise Visual Studio 2022 ou version ultérieure 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. Plusieurs cibles de publication sont disponibles, notamment :
- Azure
- Répertoire de Conteneurs Docker
- Folder
- 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 Properties/PublishProfiles/{PROFILE NAME}.pubxml fichier MSBuild 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.
Lors de la publication vers une cible Azure, le fichier .pubxml :
- Contient l’identificateur d’abonnement Azure.
- Ne doit pas être enregistré dans le système de gestion de code source, car l'identificateur d'abonnement est une information sensible.
Les informations sensibles, par exemple, le mot de passe de publication, sont chiffrées au niveau utilisateur/ordinateur. Le Properties/PublishProfiles/{PROFILE NAME}.pubxml.user fichier contient les informations nécessaires par MSBuild pour récupérer le nom d’utilisateur et le mot de passe.
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.
dotnet publish et dotnet build:
- Peut utiliser des profils de publication de dossier, MSDeploy et Kudu . Étant donné que MSDeploy ne prend pas en charge plusieurs plateformes, les options MSDeploy ne sont prises en charge que sur Windows.
- Prendre 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 commande dotnet publish.
Pour plus d’informations, consultez Microsoft.NET.Sdk.Publish.
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
msbuilddirectement.
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"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project>
<PropertyGroup>
<DeleteExistingFiles>false</DeleteExistingFiles>
<ExcludeApp_Data>false</ExcludeApp_Data>
<LaunchSiteAfterPublish>true</LaunchSiteAfterPublish>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<PublishProvider>FileSystem</PublishProvider>
<PublishUrl>\\r8\Release\AdminWeb</PublishUrl>
<WebPublishMethod>FileSystem</WebPublishMethod>
<_TargetId>Folder</_TargetId>
</PropertyGroup>
</Project>
Dans l’exemple précédent :
- La
<ExcludeApp_Data>propriété est présente pour répondre à 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=FolderProfiledotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfileUtilisation 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
Consultez Microsoft.NET.Sdk.Publish.
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 :
- Générer des artefacts
- 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.cshtmlViews/Home/About2.cshtmlViews/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 , fourni par un fichier cible de publication dans le Kit de développement logiciel (SDK) .NET. Étant donné que le Kit de développement logiciel (SDK) Web dépend du Kit de développement logiciel (SDK) .NET, l’un des éléments 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
.csprojou 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
_CustomFilespour stocker les fichiers qui correspondent au modèle d’utilisation des caractères génériquesIncludede 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>
<GUID Here=""></GUID>
</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 :
<?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. In order to learn more about this please visit https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project>
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<ResourceId>/subscriptions/SomeGuid/resourcegroups/TP_RG/providers/Microsoft.Web/sites/TP22</ResourceId>
<ResourceGroup>TP_RG</ResourceGroup>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>https://tp22.azurewebsites.net</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>true</LaunchSiteAfterPublish>
<ExcludeApp_Data>false</ExcludeApp_Data>
<ProjectGuid>GuidHere</ProjectGuid>
<MSDeployServiceURL>something.scm.azurewebsites.net:443</MSDeployServiceURL>
<DeployIisAppPath>myDeploysIISpath</DeployIisAppPath>
<RemoteSitePhysicalPath />
<SkipExtraFilesOnServer>true</SkipExtraFilesOnServer>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<EnableMSDeployBackup>true</EnableMSDeployBackup>
<EnableMsDeployAppOffline>true</EnableMsDeployAppOffline>
<UserName />
<_SavePWD>false</_SavePWD>
<_DestinationType>AzureWebSite</_DestinationType>
<InstallAspNetCoreSiteExtension>false</InstallAspNetCoreSiteExtension>
</PropertyGroup>
<Target Name="CustomActionsBeforePublish" BeforeTargets="BeforePublish">
<Message Text="Inside BeforePublish" Importance="high" />
</Target>
<Target Name="CustomActionsAfterPublish" AfterTargets="AfterPublish">
<Message Text="Inside AfterPublish" Importance="high" />
</Target>
</Project>
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 | Result |
|---|---|
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
- Fichier README du Kit de développement logiciel (SDK) web
- Dépôt GitHub du kit SDK Web : problèmes de fichier et fonctionnalités de demande pour le déploiement.
- Web Deploy (MSDeploy) simplifie le déploiement des applications web et des sites web sur les serveurs IIS.
- Transformer web.config