Fichier web.config
Remarque
Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 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 9 de cet article.
Le fichier web.config est un fichier lu par IIS et le module ASP.NET Core pour configurer une application hébergée avec IIS.
Emplacement du fichier web.config
Pour que la configuration du module ASP.NET Core soit réussie, le fichier web.config doit être présent dans le chemin de la racine du contenu (généralement le chemin de base) de l’application déployée. Il s’agit du même emplacement que le chemin physique du site Web fourni à IIS. Le fichier web.config est nécessaire à la racine de l’application pour permettre la publication de plusieurs applications à l’aide de Web Deploy.
Il existe des fichiers sensibles dans le chemin physique de l’application, par exemple {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (commentaires de documentation XML) et {ASSEMBLY}.deps.json, où l’espace réservé {ASSEMBLY} correspond au nom de l’assembly. Quand le fichier web.config est présent et que le site démarre normalement, IIS ne traite pas ces fichiers sensibles s’ils sont demandés. Si le fichier web.config est manquant, s’il est nommé de manière incorrecte ou s’il ne permet pas de configurer le site pour un démarrage normal, IIS peut traiter les fichiers sensibles de manière publique.
Le fichier web.config doit être présent à tout moment dans le déploiement, il doit être correctement nommé et permettre la configuration du site pour un démarrage normal. Ne retirez jamais le fichier web.config d’un déploiement de production.
Si le projet ne contient pas de fichier web.config, celui-ci est créé avec le processPath et les arguments appropriés pour configurer le module ASP.NET Core, puis il est déplacé vers la sortie publiée.
Si le projet contient un fichier web.config, celui-ci est transformé avec le processPath et les arguments appropriés pour configurer le module ASP.NET Core, puis il est déplacé vers la sortie publiée. La transformation ne modifie pas les paramètres de configuration IIS dans le fichier.
Le fichier web.config peut fournir des paramètres de configuration IIS supplémentaires qui contrôlent les modules IIS actifs. Pour plus d’informations sur les modules IIS capables de traiter les requêtes avec des applications ASP.NET Core, consultez la rubrique Modules IIS.
La création, la transformation et la publication du fichier web.config sont gérées par une cible MSBuild (_TransformWebConfig) au moment de la publication du projet. Cette cible est présente dans les cibles du SDK web (Microsoft.NET.Sdk.Web). Le SDK est défini en haut du fichier projet :
<Project Sdk="Microsoft.NET.Sdk.Web">
Pour empêcher le kit SDK web de transformer le fichier web.config, utilisez la propriété <IsTransformWebConfigDisabled> dans le fichier projet :
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Quand vous désactivez le kit SDK web pour empêcher la transformation du fichier, processPath et arguments doivent être définis manuellement par le développeur. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.
Configuration du module ASP.NET Core avec web.config
Le module ASP.NET Core est configuré avec la section aspNetCore du nœud system.webServer dans le fichier web.config du site.
Le fichier web.config suivant est publié pour un déploiement dépendant du framework et configure le module ASP.NET Core pour gérer les demandes du site :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
Le fichier web.config suivant est publié pour un déploiement autonome :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\MyApp.exe"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
La propriété InheritInChildApplications est définie sur false pour indiquer que les paramètres spécifiés dans l’élément <location> ne sont pas hérités par les applications qui résident dans un sous-répertoire de l’application.
Lorsqu’une application est déployée sur Azure App Service, le chemin d’accès stdoutLogFile est défini sur \\?\%home%\LogFiles\stdout. Le chemin enregistre les journaux stdout dans le dossier LogFiles, un emplacement automatiquement créé par le service.
Pour obtenir des informations sur la configuration d’une sous-application IIS, consultez Configuration avancée.
Attributs de l’élément aspNetCore
| Attribut | Description | Default |
|---|---|---|
arguments |
Attribut de chaîne facultatif. Arguments pour l’exécutable spécifié dans |
|
disableStartUpErrorPage |
Attribut booléen facultatif. Si la valeur est true, la page 502.5 – Échec du processus est supprimée, et la page de code d’état 502 configurée dans le fichier |
false |
forwardWindowsAuthToken |
Attribut booléen facultatif. Si la valeur est true, le jeton est transféré au processus enfant qui écoute sur |
true |
hostingModel |
Attribut de chaîne facultatif. Spécifie le modèle d’hébergement comme étant in-process ( |
OutOfProcess/outofprocess lorsqu’il n’est pas présent |
processesPerApplication |
Attribut entier facultatif. Spécifie le nombre d’instances du processus indiqué dans le paramètre †Pour l’hébergement in-process, la valeur est limitée à Il est déconseillé de définir |
Valeur par défaut : 1Min : 1Max : 100† |
processPath |
Attribut de chaîne requis. Chemin d’accès au fichier exécutable lançant un processus d’écoute des requêtes HTTP. Les chemins d’accès relatifs sont pris en charge. Si le chemin d’accès commence par |
|
rapidFailsPerMinute |
Attribut entier facultatif. Indique le nombre de fois où le processus spécifié dans Non pris en charge avec hébergement in-process. |
Valeur par défaut : 10Min : 0Max : 100 |
requestTimeout |
Attribut timespan facultatif. Spécifie la durée pendant laquelle le module ASP.NET Core attend une réponse de la part du processus à l’écoute sur %ASPNETCORE_PORT%. Dans les versions du module ASP.NET Core fournies avec ASP.NET Core 2.1 ou version ultérieure, la valeur Ne s’applique pas à l’hébergement in-process. Pour l’hébergement in-process, le module attend que l’application traite la requête. Les valeurs valides pour les segments de minutes et secondes de la chaîne sont dans la plage de 0 à 59. L’utilisation de |
Valeur par défaut : 00:02:00Min : 00:00:00Max : 360:00:00 |
shutdownTimeLimit |
Attribut entier facultatif. Durée en secondes pendant laquelle le module attend que l’exécutable s’arrête normalement quand le fichier |
Valeur par défaut : 10Min : 0Max : 600 |
startupTimeLimit |
Attribut entier facultatif. Durée en secondes pendant laquelle le module attend que le fichier exécutable démarre un processus à l’écoute sur le port. Si cette limite de temps est dépassée, le module met fin au processus. Lors d’un hébergement in-process : le processus n’est pas redémarré et n’utilise pas le paramètre Lors d’un hébergement hors processus : le module tente de relancer le processus lorsqu’il reçoit une nouvelle demande, puis continue d’essayer de redémarrer le processus pour les demandes entrantes suivantes, sauf si l’application ne démarre pas La valeur 0 (zéro) n’est pas considérée comme un délai infini. |
Valeur par défaut : 120Min : 0Max : 3600 |
stdoutLogEnabled |
Attribut booléen facultatif. Si la valeur est true, |
false |
stdoutLogFile |
Attribut de chaîne facultatif. Spécifie le chemin relatif ou absolu pour lequel |
aspnetcore-stdout |
Définir des variables d’environnement
Des variables d’environnement peuvent être spécifiées pour le processus dans l’attribut processPath. Spécifiez une variable d’environnement à l’aide de l’élément enfant <environmentVariable> d’un élément de collection <environmentVariables>. Les variables d’environnement définies dans cette section prévalent sur les variables d’environnement système.
L’exemple suivant définit deux variables d’environnement dans web.config. ASPNETCORE_ENVIRONMENT définit l’environnement de l’application sur Development. Un développeur peut définir temporairement cette valeur dans le fichier web.config afin de forcer le chargement de la Page d’exceptions du développeur lors du débogage d’une exception d’application. CONFIG_DIR est un exemple de variable d’environnement définie par l’utilisateur, dans laquelle le développeur a écrit du code qui lit la valeur de démarrage afin de former un chemin d’accès pour le chargement du fichier de configuration de l’application.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
<environmentVariable name="CONFIG_DIR" value="f:\application_config" />
</environmentVariables>
</aspNetCore>
Notes
Une alternative à la définition directe de l’environnement dans web.config consiste à inclure la propriété <EnvironmentName> dans le profil de publication (.pubxml) ou le fichier projet. Cette approche définit l’environnement dans web.config lorsque le projet est publié :
<PropertyGroup>
<EnvironmentName>Development</EnvironmentName>
</PropertyGroup>
Avertissement
Affectez uniquement Development à la variable d’environnement ASPNETCORE_ENVIRONMENT sur les serveurs de test et de préproduction non accessibles aux réseaux non approuvés, par exemple Internet.
Configuration d’IIS avec web.config
La configuration d’IIS est influencée par la section <system.webServer> de web.config pour les scénarios IIS qui sont fonctionnels pour les applications ASP.NET Core avec le module ASP.NET Core. Par exemple, la configuration IIS est fonctionnelle pour la compression dynamique. Si IIS est configuré au niveau du serveur pour utiliser la compression dynamique, l’élément <urlCompression> dans le fichier web.config de l’application peut le désactiver pour une application ASP.NET Core.
Pour plus d'informations, voir les rubriques suivantes :
- Informations de référence sur la configuration pour
<system.webServer> - Module ASP.NET Core (ANCM) pour IIS
- Modules IIS avec ASP.NET Core
Pour définir les variables d’environnement d’applications individuelles s’exécutant dans des pools d’applications isolés (pris en charge pour IIS 10.0 ou version ultérieure), consultez la section Commande AppCmd.exe de la rubrique Variables d’environnement <environmentVariables> dans la documentation de référence d’IIS.
Sections de configuration de web.config
Les sections de configuration des applications ASP.NET 4.x dans web.config ne sont pas utilisées par les applications ASP.NET Core pour la configuration :
<system.web><appSettings><connectionStrings><location>
Les applications ASP.NET Core sont configurées à l’aide d’autres fournisseurs de configuration. Pour plus d’informations, consultez Configuration.
Transformer web.config
Si vous devez transformer web.config au moment de la publication, consultez Transformer web.config. Vous devrez peut-être transformer web.config au moment de la publication pour définir les variables d’environnement en fonction de la configuration, du profil ou de l’environnement.
