Module ASP.NET Core (ANCM) pour IIS
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.
Le module ASP.NET Core (ANCM) est un module IIS natif qui se connecte au pipeline IIS, ce qui permet aux applications ASP.NET Core de fonctionner avec IIS. Exécutez les applications ASP.NET Core avec IIS en procédant d’une des manières suivantes :
- Hébergez une application ASP.NET Core à l’intérieur du processus de travail IIS (
w3wp.exe
), appelé modèle d’hébergement in-process. - Transférez les demandes web à une application ASP.NET Core back-end exécutant le serveur Kestrel, appelée modèle d’hébergement hors processus.
Chaque modèle d’hébergement présente des avantages et des inconvénients. Le modèle d’hébergement in-process est utilisé par défaut, en raison de meilleurs diagnostics et performances.
Pour plus d’informations et pour obtenir de l’aide sur la configuration, consultez les rubriques suivantes :
Installer le module ASP.NET Core (ANCM)
Le module ASP.NET Core (ANCM) est installé avec le runtime .NET Core à partir du bundle d’hébergement .NET Core. Le module ASP.NET Core assure la compatibilité descendante et ascendante avec les versions avec support technique de .NET.
Les changements cassants et les avis de sécurité sont signalés dans le dépôt Annonces. Les annonces peuvent être limitées à une version spécifique en sélectionnant un filtre Étiquette.
Téléchargez le programme d’installation à l’aide du lien suivant :
Programme d’installation du bundle d’hébergement .NET Core actuel (téléchargement direct)
Pour plus d’informations, notamment l’installation d’une version antérieure du module, consultez Bundle d’hébergement.
Pour accéder à un tutoriel sur la publication d’une application ASP.NET Core sur un serveur IIS, consultez Publier une application ASP.NET Core sur IIS.
Le module ASP.NET Core (ANCM) est un module IIS natif qui se connecte dans le pipeline IIS pour effectuer l’une des opérations suivantes :
- Héberger une application ASP.NET Core à l’intérieur du processus de travail IIS (
w3wp.exe
), appelé modèle d’hébergement in-process. - Transférer les demandes web à une application ASP.NET Core back-end exécutant le serveur Kestrel, appelée modèle d’hébergement hors processus.
Versions de Windows prises en charge :
- Windows 7 ou version ultérieure
- Windows Server 2012 R2 ou version ultérieure
Lors de l’hébergement in-process, le module utilise une implémentation du serveur in-process pour IIS, nommée serveur HTTP IIS (IISHttpServer
).
Lors de l’hébergement hors processus, le module fonctionne uniquement avec Kestrel. Le module ne fonctionne pas avec HTTP.sys.
Modèles d'hébergement
Modèle d’hébergement in-process
Les applications ASP.NET Core utilisent par défaut le modèle d’hébergement in-process.
Les caractéristiques suivantes s’appliquent lors de l’hébergement in-process :
Le serveur IIS HTTP (
IISHttpServer
) est utilisé à la place du serveur Kestrel. Pour in-process, CreateDefaultBuilder appelle UseIIS pour :- Enregistrer
IISHttpServer
. - Configurer le port et le chemin de base sur lesquels le serveur doit écouter lors de l’exécution derrière le module ASP.NET Core.
- Configurer l’hôte pour capturer des erreurs de démarrage.
- Enregistrer
L’attribut requestTimeout ne s’applique pas à l’hébergement in-process.
Le partage d’un pool d’applications entre les applications n’est pas pris en charge. Utilisez un pool d’applications par application.
Lorsque vous utilisez Web Deploy ou que vous placez manuellement un fichier
app_offline.htm
dans le déploiement, l’application peut ne pas s’arrêter immédiatement si une connexion est ouverte. Par exemple, une connexion WebSocket peut retarder l’arrêt de l’application.L’architecture (nombre de bits) de l’application et le runtime installé (x64 ou x86) doivent correspondre à l’architecture du pool d’applications.
Les déconnexions du client sont détectées. Le jeton d’annulation
HttpContext.RequestAborted
est annulé lors de la déconnexion du client.Dans ASP.NET Core 2.2.1 ou version antérieure, GetCurrentDirectory retourne le répertoire de travail du processus démarré par IIS, et non le répertoire de l’application (par exemple,
C:\Windows\System32\inetsrv
pourw3wp.exe
).Pour connaître l’exemple de code qui définit le répertoire actuel de l’application, consultez la classe
CurrentDirectoryHelpers
. Appelez la méthodeSetCurrentDirectory
. Les appels suivants à GetCurrentDirectory fournissent le répertoire de l’application.Dans le cas d’un hébergement in-process, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. Si vous transformez les revendications avec une implémentation de IClaimsTransformation, appelez AddAuthentication pour ajouter des services d’authentification :
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IClaimsTransformation, ClaimsTransformer>(); services.AddAuthentication(IISServerDefaults.AuthenticationScheme); } public void Configure(IApplicationBuilder app) { app.UseAuthentication(); }
- Les déploiements de package web (fichier unique) ne sont pas pris en charge.
Modèle d’hébergement out-of-process
Pour configurer une application pour l’hébergement hors processus, définissez la valeur de la propriété <AspNetCoreHostingModel>
sur OutOfProcess
dans le fichier projet (.csproj
) :
<PropertyGroup>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
L’hébergement in-process est défini avec InProcess
, qui est la valeur par défaut.
La valeur de <AspNetCoreHostingModel>
ne respecte pas la casse, inprocess
et outofprocess
sont donc des valeurs valides.
Le serveur Kestrel est utilisé à la place du serveur HTTP IIS (IISHttpServer
).
Pour le cas hors processus, CreateDefaultBuilder
appelle UseIISIntegration pour :
- Configurer le port et le chemin de base sur lesquels le serveur doit écouter lors de l’exécution derrière le module ASP.NET Core.
- Configurer l’hôte pour capturer des erreurs de démarrage.
Modifications du modèle d’hébergement
Si le paramètre hostingModel
est modifié dans le fichier web.config
(comme expliqué dans la section Configuration avec web.config
), le module recycle le processus de travail pour IIS.
Pour IIS Express, le module ne recycle pas le processus de travail, mais déclenche plutôt un arrêt approprié du processus IIS Express en cours. La requête suivante à l’application génère un nouveau processus IIS Express.
Nom du processus
Process.GetCurrentProcess().ProcessName
signale w3wp
/iisexpress
(in-process) ou dotnet
(out-of-process).
De nombreux modules natifs, comme l’authentification Windows, restent actifs. Pour obtenir plus d’informations sur les modules IIS actifs avec le module ASP.NET Core, consultez Modules IIS avec ASP.NET Core.
Le module ASP.NET Core peut également :
- Définir des variables d’environnement pour le processus de travail.
- Journaliser la sortie de stdout dans un stockage de fichiers pour résoudre les problèmes de démarrage.
- Transférer des jetons d’authentification Windows.
Comment installer et utiliser le module ASP.NET Core (ANCM)
Pour obtenir des instructions sur l’installation du module ASP.NET Core, consultez Installer le bundle d’hébergement .NET Core. Le module ASP.NET Core assure la compatibilité descendante et ascendante avec les versions avec support technique de .NET.
Les changements cassants et les avis de sécurité sont signalés dans le dépôt Annonces. Les annonces peuvent être limitées à une version spécifique en sélectionnant un filtre Étiquette.
Configuration 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 de sous-application IIS, consultez Héberger ASP.NET Core sur Windows avec IIS.
Attributs de l’élément aspNetCore
Attribut | Description | Default |
---|---|---|
arguments |
Attribut de chaîne facultatif. Arguments pour l’exécutable spécifié dans processPath. |
|
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 web.config est prioritaire. |
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 ( |
InProcess inprocess |
processesPerApplication |
Attribut entier facultatif. Spécifie le nombre d’instances du processus indiqué dans le paramètre processPath qui peuvent être lancées par application. †Pour l’hébergement in-process, la valeur est limitée à Il est déconseillé de définir |
Valeur par défaut : 1 Min : 1 Max : 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 processPath est autorisé à se bloquer par minute. Si cette limite est dépassée, le module arrête le lancement du processus pour le reste de la minute. Non pris en charge avec hébergement in-process. |
Valeur par défaut : 10 Min : 0 Max : 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 60 dans la valeur de minutes ou de secondes affiche 500 - Erreur interne du serveur. |
Valeur par défaut : 00:02:00 Min : 00:00:00 Max : 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 : 10 Min : 0 Max : 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 rapidFailsPerMinute. 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 rapidFailsPerMinute un certain nombre de fois au cours de la dernière minute. La valeur 0 (zéro) n’est pas considérée comme un délai infini. |
Valeur par défaut : 120 Min : 0 Max : 3600 |
stdoutLogEnabled |
Attribut booléen facultatif. Si la valeur est true, les attributs stdout et stderr du processus spécifié dans processPath sont redirigés vers le fichier spécifié dans stdoutLogFile. |
false |
stdoutLogFile |
Attribut de chaîne facultatif. Spécifie le chemin d’accès relatif ou absolu pour lequel les attributs stdout et stderr du processus spécifié dans processPath sont consignés. Les chemins d’accès relatifs sont relatifs par rapport à la racine du site. Tout chemin d’accès commençant par |
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.
app_offline.htm
Si un fichier portant le nom app_offline.htm
est détecté dans le répertoire racine d’une application, le module ASP.NET Core tente d’arrêter normalement l’application, puis interrompt le traitement des demandes entrantes. Si l’application est toujours active après le nombre de secondes défini dans shutdownTimeLimit
, le module ASP.NET Core met fin au processus en cours d’exécution.
Tant que le fichier app_offline.htm
est présent, le module ASP.NET Core répond aux requêtes en renvoyant le contenu du fichier app_offline.htm
. Lorsque le fichier app_offline.htm
est supprimé, la requête suivante démarre l’application.
Lorsque vous utilisez le modèle d’hébergement out-of-process, l’application peut ne pas s’arrêter immédiatement s’il existe une connexion ouverte. Par exemple, une connexion WebSocket peut retarder l’arrêt de l’application.
Page d’erreur de démarrage
Les hébergements in-process et out-of-process produisent des pages d’erreurs personnalisées quand ils ne parviennent pas à démarrer l’application.
Si le module ASP.NET Core ne trouve pas le gestionnaire de requêtes in-process ou out-of-process, une page de code d’état 500.0 - Échec de chargement du gestionnaire in-process/out-of-process s’affiche.
Pour l’hébergement in-process, si le module ASP.NET Core ne peut pas démarrer l’application, une page de code d’état 500.30 - Échec de démarrage s’affiche.
Pour l’hébergement out-of-process, si le module ASP.NET Core ne peut pas lancer le processus backend ou que ce dernier démarre mais ne parvient pas à écouter sur le port configuré, une page de code d’état 502.5 - Échec du processus s’affiche.
Pour supprimer cette page et revenir à la page IIS de codes d’état 5xx par défaut, utilisez l’attribut disableStartUpErrorPage
. Pour plus d’informations sur la configuration des messages d’erreur personnalisés, consultez Erreurs HTTP <httpErrors>
.
Création et redirection de journal
Le module ASP.NET Core redirige la sortie de console stdout et stderr vers le disque si les attributs stdoutLogEnabled
et stdoutLogFile
de l’élément aspNetCore
sont définis. Tous les dossiers du chemin stdoutLogFile
sont créés par le module au moment de la création du fichier journal. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\<app_pool_name>
pour fournir les autorisations d’écriture).
Aucune rotation n’est appliquée aux journaux, sauf en cas de recyclage/redémarrage du processus. Il incombe à l’hébergeur de limiter l’espace disque utilisé par les journaux.
L’utilisation du journal stdout est recommandée uniquement pour résoudre les problèmes de démarrage d’application lors de l’hébergement sur IIS ou lors de l’utilisation de la prise en charge au moment du développement pour IIS avec Visual Studio, et non lors du débogage local et de l’exécution de l’application avec IIS Express.
N’utilisez pas le journal stdout à des fins de journalisation d’application générale. Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.
Un horodatage et une extension de fichier sont ajoutés automatiquement quand le fichier journal est créé. Le nom du fichier journal est créé en ajoutant l’horodatage, un ID de processus et une extension de fichier (.log
) au dernier segment du chemin d’accès stdoutLogFile
(généralement stdout
), séparés par des traits de soulignement. Si le chemin d’accès stdoutLogFile
se termine par stdout
, un journal pour une application avec un PID de 1934 créé le 5/2/2018 à 19:42:32 affiche le nom de fichier stdout_20180205194132_1934.log
.
Si stdoutLogEnabled
a la valeur false, les erreurs qui se produisent au moment du démarrage de l’application sont capturées et émises dans le journal des événements (30 Ko maximum). Après le démarrage, tous les journaux supplémentaires sont ignorés.
L’exemple d’élément aspNetCore
suivant configure la journalisation stdout au niveau du chemin d’accès relatif .\log\
. Vérifiez que l’identité de l’utilisateur AppPool à l’autorisation d’écrire dans le chemin d’accès fourni.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess">
</aspNetCore>
Lors de la publication d’une application pour le déploiement d’Azure App Service, le SDK web définit la valeur stdoutLogFile
sur \\?\%home%\LogFiles\stdout
. La variable d’environnement %home
est prédéfinie pour les applications hébergées par Azure App Service.
Pour créer des règles de filtre de journalisation, consultez la section Appliquer des règles de filtre de journal dans le code de la documentation de journalisation ASP.NET Core.
Pour plus d’informations sur les formats de chemin d’accès, consultez Formats de chemin d’accès aux fichiers sur les systèmes Windows.
Journaux de diagnostic améliorés
Le module ASP.NET Core est configurable pour proposer des journaux de diagnostic améliorés. Ajoutez l’élément <handlerSettings>
à l’élément <aspNetCore>
dans web.config
. L’affectation de la valeur TRACE
à debugLevel
expose une fidélité plus élevée des informations de diagnostic :
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
<handlerSetting name="debugLevel" value="FILE,TRACE" />
</handlerSettings>
</aspNetCore>
Tous les dossiers dans le chemin d’accès (logs
dans l’exemple précédent) sont créés par le module lorsque le fichier journal est créé. Le pool d’applications doit avoir un accès en écriture à l’emplacement où les journaux sont écrits (utilisez IIS AppPool\{APP POOL NAME}
, où l’espace réservé {APP POOL NAME}
est le nom du pool d’applications, pour fournir les autorisations d’écriture).
Les valeurs du niveau de débogage (debugLevel
) peuvent inclure à la fois le niveau et l’emplacement.
Niveaux (dans l’ordre du moins au plus détaillé) :
- ERROR
- WARNING
- INFO
- TRACE
Emplacements (plusieurs emplacements sont autorisés) :
- CONSOLE
- EVENTLOG
- FILE
Les paramètres de gestionnaire peuvent également être fournis par le biais de variables d’environnement :
ASPNETCORE_MODULE_DEBUG_FILE
: Chemin du fichier journal de débogage. (Valeur par défaut :aspnetcore-debug.log
)ASPNETCORE_MODULE_DEBUG
: Paramètre du niveau de débogage.
Avertissement
Ne laissez pas la journalisation du débogage activée dans le déploiement plus longtemps que nécessaire pour résoudre un problème. La taille du journal n’est pas limitée. Si vous laissez la journalisation du débogage activée, vous risquez d’épuiser l’espace disque disponible et de bloquer le serveur ou le service d’application.
Consultez Configuration avec web.config pour obtenir un exemple d’élément aspNetCore
dans le fichier web.config
.
Modifier la taille de pile
S’applique uniquement lors de l’utilisation du modèle d’hébergement in-process.
Configurez la taille de pile managée à l’aide du paramètre stackSize
en octets dans web.config
. La taille par défaut est de 1 048 576 octets (1 Mo).
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="stackSize" value="2097152" />
</handlerSettings>
</aspNetCore>
La configuration du proxy utilise le protocole HTTP et un jeton d’appariement
S’applique uniquement à l’hébergement out-of-process.
Le proxy créé entre le module ASP.NET Core et Kestrel utilise le protocole HTTP. Il n’existe aucun risque d’écoute clandestine du trafic entre le module et Kestrel à partir d’un emplacement sur le serveur.
Un jeton d’appairage est utilisé pour garantir que les demandes reçues par Kestrel ont été traitées par IIS et ne proviennent pas d’une autre source. Le jeton d’appariement est créé et défini dans une variable d’environnement (ASPNETCORE_TOKEN
) par le module. Le jeton d’appariement est également défini dans un en-tête (MS-ASPNETCORE-TOKEN
) sur toutes les demandes traitées. L'intergiciel IIS vérifie chaque demande qu’il reçoit pour confirmer que la valeur d’en-tête du jeton d'appariement correspond à la valeur de la variable d’environnement. Si les valeurs de jeton ne correspondent pas, la demande est connectée et rejetée. La variable d’environnement du jeton d'appairage et le trafic entre le module et Kestrel ne sont pas accessibles à partir d’un emplacement sur le serveur. Sans connaître la valeur du jeton d'appariement, une personne malveillante ne peut pas soumettre des demandes qui contournent la vérification de l’intergiciel IIS.
Module ASP.NET Core avec une configuration partagée IIS
Le programme d’installation du module ASP.NET Core s’exécute avec les privilèges du compte TrustedInstaller. Comme le compte système local n’a pas l’autorisation de modifier le chemin de partage utilisé par la configuration partagée IIS, le programme d’installation génère une erreur d’accès refusé pendant la tentative de configuration des paramètres du module dans le fichier applicationHost.config
du partage.
Quand une configuration partagée IIS est utilisée sur la même machine que l’installation IIS, il convient d’exécuter le programme d’installation du bundle d’hébergement ASP.NET Core avec le paramètre OPT_NO_SHARED_CONFIG_CHECK
défini sur 1
:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
Quand le chemin de la configuration partagée ne se trouve pas sur la même machine que l’installation IIS, effectuez ces étapes :
- Désactivez la configuration partagée IIS.
- Exécutez le programme d’installation.
- Exportez le fichier
applicationHost.config
mis à jour vers le partage. - Réactivez la configuration partagée IIS.
Version du module et journaux du programme d’installation du bundle d’hébergement
Pour déterminer la version du module ASP.NET Core installé :
- Sur le système d’hébergement, accédez à
%windir%\System32\inetsrv
. - Localisez le fichier
aspnetcore.dll
. - Cliquez avec le bouton droit sur le fichier, puis sélectionnez Propriétés dans le menu contextuel.
- Sélectionnez l'onglet Détails. Le version du fichier et la version du produit représentent la version installée du module.
Les journaux du programme d’installation du bundle d’hébergement du module se trouvent dans C:\Users\%UserName%\AppData\Local\Temp
. Le fichier est nommé dd_DotNetCoreWinSvrHosting__{TIMESTAMP}_000_AspNetCoreModule_x64.log
.
Emplacements des fichiers du module, du schéma et de configuration
Module
IIS (x86/amd64) :
%windir%\System32\inetsrv\aspnetcore.dll
%windir%\SysWOW64\inetsrv\aspnetcore.dll
%ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll
IIS Express (x86/amd64) :
%ProgramFiles%\IIS Express\aspnetcore.dll
%ProgramFiles(x86)%\IIS Express\aspnetcore.dll
%ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll
schéma
IIS
%windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml
%windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml
IIS Express
%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml
%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml
Configuration
IIS
%windir%\System32\inetsrv\config\applicationHost.config
IIS Express
Visual Studio :
{APPLICATION ROOT}\.vs\config\applicationHost.config
iisexpress.exe CLI :
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config
Vous trouverez les fichiers en recherchant aspnetcore
dans le fichier applicationHost.config
.
Le module ASP.NET Core (ANCM) est un module IIS natif qui se connecte dans le pipeline IIS pour effectuer l’une des opérations suivantes :
- Héberger une application ASP.NET Core à l’intérieur du processus de travail IIS (
w3wp.exe
), appelé modèle d’hébergement in-process. - Transférer les demandes web à une application ASP.NET Core back-end exécutant le serveur Kestrel, appelée modèle d’hébergement hors processus.
Versions de Windows prises en charge :
- Windows 7 ou version ultérieure
- Windows Server 2008 R2 ou version ultérieure
Lors de l’hébergement in-process, le module utilise une implémentation du serveur in-process pour IIS, nommée serveur HTTP IIS (IISHttpServer
).
Lors de l’hébergement hors processus, le module fonctionne uniquement avec Kestrel. Le module ne fonctionne pas avec HTTP.sys.
Modèles d'hébergement
Modèle d’hébergement in-process
Pour configurer l’hébergement in-process dans une application, ajoutez la propriété <AspNetCoreHostingModel>
au fichier projet de l’application en lui attribuant la valeur InProcess
(l’hébergement out-of-process est défini sur OutOfProcess
) :
<PropertyGroup>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
Le modèle d’hébergement in-process n’est pas pris en charge pour les applications ASP.NET Core qui ciblent le .NET Framework.
La valeur de <AspNetCoreHostingModel>
ne respecte pas la casse, inprocess
et outofprocess
sont donc des valeurs valides.
Si la propriété <AspNetCoreHostingModel>
n’est pas présente dans le fichier, la valeur par défaut est OutOfProcess
.
Les caractéristiques suivantes s’appliquent lors de l’hébergement in-process :
Le serveur IIS HTTP (
IISHttpServer
) est utilisé à la place du serveur Kestrel. Pour in-process, CreateDefaultBuilder appelle UseIIS pour :- Enregistrer
IISHttpServer
. - Configurer le port et le chemin de base sur lesquels le serveur doit écouter lors de l’exécution derrière le module ASP.NET Core.
- Configurer l’hôte pour capturer des erreurs de démarrage.
- Enregistrer
L’attribut requestTimeout ne s’applique pas à l’hébergement in-process.
Le partage d’un pool d’applications entre les applications n’est pas pris en charge. Utilisez un pool d’applications par application.
Lorsque vous utilisez Web Deploy ou que vous placez manuellement un fichier app_offline.htm dans le déploiement, l’application peut ne pas s’arrêter immédiatement si une connexion est ouverte. Par exemple, une connexion websocket peut retarder l’arrêt de l’application.
L’architecture (nombre de bits) de l’application et le runtime installé (x64 ou x86) doivent correspondre à l’architecture du pool d’applications.
Les déconnexions du client sont détectées. Le jeton d’annulation HttpContext.RequestAborted est annulé quand le client se déconnecte.
Dans ASP.NET Core version 2.2.1 ou antérieure, GetCurrentDirectory retourne le répertoire de travail du processus démarré par IIS, et non le répertoire de l’application (par exemple, C:\Windows\System32\inetsrv pour w3wp.exe).
Pour connaître l’exemple de code qui définit le répertoire actuel de l’application, consultez CurrentDirectoryHelpers, classe. Appelez la méthode
SetCurrentDirectory
. Les appels suivants à GetCurrentDirectory fournissent le répertoire de l’application.Dans le cas d’un hébergement in-process, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. Si vous transformez les revendications avec une implémentation de IClaimsTransformation, appelez AddAuthentication pour ajouter des services d’authentification :
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IClaimsTransformation, ClaimsTransformer>(); services.AddAuthentication(IISServerDefaults.AuthenticationScheme); } public void Configure(IApplicationBuilder app) { app.UseAuthentication(); }
Modèle d’hébergement out-of-process
Pour configurer une application pour un hébergement out-of-process, utilisez l’une des approches suivantes dans le fichier de projet :
- Ne spécifiez pas la propriété
<AspNetCoreHostingModel>
. Si la propriété<AspNetCoreHostingModel>
n’est pas présente dans le fichier, la valeur par défaut estOutOfProcess
. - Définissez la valeur de la propriété
<AspNetCoreHostingModel>
surOutOfProcess
(l’hébergement in-process est défini avecInProcess
) :
<PropertyGroup>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
La valeur ne respecte pas la casse, inprocess
et outofprocess
sont donc des valeurs valides.
Le serveur Kestrel est utilisé à la place du serveur HTTP IIS (IISHttpServer
).
Pour out-of-process, CreateDefaultBuilder appelle UseIISIntegration pour :
- Configurer le port et le chemin de base sur lesquels le serveur doit écouter lors de l’exécution derrière le module ASP.NET Core.
- Configurer l’hôte pour capturer des erreurs de démarrage.
Modifications du modèle d’hébergement
Si le paramètre hostingModel
est modifié dans le fichier web.config (comme expliqué dans la section Configuration avec web.config), le module recycle le processus de travail pour IIS.
Pour IIS Express, le module ne recycle pas le processus de travail, mais déclenche plutôt un arrêt approprié du processus IIS Express en cours. La requête suivante à l’application génère un nouveau processus IIS Express.
Nom du processus
Process.GetCurrentProcess().ProcessName
signale w3wp
/iisexpress
(in-process) ou dotnet
(out-of-process).
De nombreux modules natifs, comme l’authentification Windows, restent actifs. Pour obtenir plus d’informations sur les modules IIS actifs avec le module ASP.NET Core, consultez Modules IIS avec ASP.NET Core.
Le module ASP.NET Core peut également :
- Définir des variables d’environnement pour le processus de travail.
- Journaliser la sortie de stdout dans un stockage de fichiers pour résoudre les problèmes de démarrage.
- Transférer des jetons d’authentification Windows.
Comment installer et utiliser le module ASP.NET Core (ANCM)
Pour obtenir des instructions sur l’installation du module ASP.NET Core, consultez Installer le bundle d’hébergement .NET Core. Le module ASP.NET Core assure la compatibilité descendante et ascendante avec les versions avec support technique de .NET.
Les changements cassants et les avis de sécurité sont signalés dans le dépôt Annonces. Les annonces peuvent être limitées à une version spécifique en sélectionnant un filtre Étiquette.
Configuration 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 <emplacement> ne sont pas hérités par les applications qui se trouvent 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 d’accès enregistre les journaux stdout dans le dossier LogFiles, un emplacement automatiquement créé par le service.
Pour obtenir des informations sur la configuration de sous-application IIS, consultez Héberger ASP.NET Core sur Windows avec IIS.
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 web.config est prioritaire. |
false |
forwardWindowsAuthToken |
Attribut booléen facultatif. Si la valeur est true, le jeton est transmis au processus enfant qui écoute sur %ASPNETCORE_PORT% sous la forme d’un en-tête 'MS-ASPNETCORE-WINAUTHTOKEN' par demande. Il incombe à ce processus d’appeler CloseHandle sur ce jeton par demande. |
true |
hostingModel |
Attribut de chaîne facultatif. Spécifie le modèle d’hébergement comme étant in-process ( |
OutOfProcess outofprocess |
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 : 1 Min : 1 Max : 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 : 10 Min : 0 Max : 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 60 dans la valeur de minutes ou de secondes affiche 500 - Erreur interne du serveur. |
Valeur par défaut : 00:02:00 Min : 00:00:00 Max : 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 : 10 Min : 0 Max : 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 : 120 Min : 0 Max : 3600 |
stdoutLogEnabled |
Attribut booléen facultatif. Si la valeur est true, les attributs stdout et stderr du processus spécifié dans |
false |
stdoutLogFile |
Attribut de chaîne facultatif. Spécifie le chemin relatif ou absolu pour lequel |
aspnetcore-stdout |
Définition 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. 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>
Remarque
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.
app_offline.htm
Si un fichier portant le nom app_offline.htm
est détecté dans le répertoire racine d’une application, le module ASP.NET Core tente d’arrêter normalement l’application, puis interrompt le traitement des demandes entrantes. Si l’application est toujours active après le nombre de secondes défini dans shutdownTimeLimit
, le module ASP.NET Core met fin au processus en cours d’exécution.
Tant que le fichier app_offline.htm
est présent, le module ASP.NET Core répond aux requêtes en renvoyant le contenu du fichier app_offline.htm
. Lorsque le fichier app_offline.htm
est supprimé, la requête suivante démarre l’application.
Lorsque vous utilisez le modèle d’hébergement out-of-process, l’application peut ne pas s’arrêter immédiatement s’il existe une connexion ouverte. Par exemple, une connexion websocket peut retarder l’arrêt de l’application.
Page d’erreur de démarrage
Les hébergements in-process et out-of-process produisent des pages d’erreurs personnalisées quand ils ne parviennent pas à démarrer l’application.
Si le module ASP.NET Core ne trouve pas le gestionnaire de requêtes in-process ou out-of-process, une page de code d’état 500.0 - Échec de chargement du gestionnaire in-process/out-of-process s’affiche.
Pour l’hébergement in-process, si le module ASP.NET Core ne peut pas démarrer l’application, une page de code d’état 500.30 - Échec de démarrage s’affiche.
Pour l’hébergement out-of-process, si le module ASP.NET Core ne peut pas lancer le processus backend ou que ce dernier démarre mais ne parvient pas à écouter sur le port configuré, une page de code d’état 502.5 - Échec du processus s’affiche.
Pour supprimer cette page et revenir à la page IIS de codes d’état 5xx par défaut, utilisez l’attribut disableStartUpErrorPage
. Pour plus d’informations sur la configuration des messages d’erreur personnalisés, consultez Erreurs HTTP <httpErrors>.
Création et redirection de journal
Le module ASP.NET Core redirige la sortie de console stdout et stderr vers le disque si les attributs stdoutLogEnabled
et stdoutLogFile
de l’élément aspNetCore
sont définis. Tous les dossiers du chemin stdoutLogFile
sont créés par le module au moment de la création du fichier journal. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\{APP POOL NAME}
pour fournir les autorisations d’écriture, où l’espace réservé {APP POOL NAME}
est le nom du pool d’applications).
Aucune rotation n’est appliquée aux journaux, sauf en cas de recyclage/redémarrage du processus. Il incombe à l’hébergeur de limiter l’espace disque utilisé par les journaux.
L’utilisation du journal stdout est recommandée uniquement pour résoudre les problèmes de démarrage d’application lors de l’hébergement sur IIS ou lors de l’utilisation de la prise en charge au moment du développement pour IIS avec Visual Studio, et non lors du débogage local et de l’exécution de l’application avec IIS Express.
N’utilisez pas le journal stdout à des fins de journalisation d’application générale. Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.
Un horodatage et une extension de fichier sont ajoutés automatiquement quand le fichier journal est créé. Le nom du fichier journal est créé en ajoutant l’horodatage, un ID de processus et une extension de fichier (.log
) au dernier segment du chemin d’accès stdoutLogFile
(généralement stdout
), séparés par des traits de soulignement. Si le chemin d’accès stdoutLogFile
se termine par stdout
, un journal pour une application avec un PID de 1934 créé le 5/2/2018 à 19:42:32 affiche le nom de fichier stdout_20180205194132_1934.log
.
Si stdoutLogEnabled
a la valeur false, les erreurs qui se produisent au moment du démarrage de l’application sont capturées et émises dans le journal des événements (30 Ko maximum). Après le démarrage, tous les journaux supplémentaires sont ignorés.
L’exemple d’élément aspNetCore
suivant configure la journalisation stdout au niveau du chemin d’accès relatif .\log\
. Vérifiez que l’identité de l’utilisateur du pool d’applications a l’autorisation d’écrire dans le chemin fourni.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess">
</aspNetCore>
Lors de la publication d’une application pour le déploiement d’Azure App Service, le SDK web définit la valeur stdoutLogFile
sur \\?\%home%\LogFiles\stdout
. La variable d’environnement %home
est prédéfinie pour les applications hébergées par Azure App Service.
Pour plus d’informations sur les formats de chemin d’accès, consultez Formats de chemin d’accès aux fichiers sur les systèmes Windows.
Journaux de diagnostic améliorés
Le module ASP.NET Core est configurable pour proposer des journaux de diagnostic améliorés. Ajoutez l’élément <handlerSettings>
à l’élément <aspNetCore>
dans web.config
. L’affectation de la valeur TRACE
à debugLevel
expose une fidélité plus élevée des informations de diagnostic :
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile="\\?\%home%\LogFiles\stdout"
hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
<handlerSetting name="debugLevel" value="FILE,TRACE" />
</handlerSettings>
</aspNetCore>
Les dossiers situés dans le chemin fourni pour la valeur <handlerSetting>
(logs
dans l’exemple précédent) ne sont pas créés automatiquement par le module. Ils doivent préexister dans le déploiement. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\{APP POOL NAME}
pour fournir les autorisations d’écriture, où l’espace réservé {APP POOL NAME}
est le nom du pool d’applications).
Les valeurs du niveau de débogage (debugLevel
) peuvent inclure à la fois le niveau et l’emplacement.
Niveaux (dans l’ordre du moins au plus détaillé) :
- ERROR
- WARNING
- INFO
- TRACE
Emplacements (plusieurs emplacements sont autorisés) :
- CONSOLE
- EVENTLOG
- FILE
Les paramètres de gestionnaire peuvent également être fournis par le biais de variables d’environnement :
ASPNETCORE_MODULE_DEBUG_FILE
: Chemin du fichier journal de débogage. (Valeur par défaut :aspnetcore-debug.log
)ASPNETCORE_MODULE_DEBUG
: Paramètre du niveau de débogage.
Avertissement
Ne laissez pas la journalisation du débogage activée dans le déploiement plus longtemps que nécessaire pour résoudre un problème. La taille du journal n’est pas limitée. Si vous laissez la journalisation du débogage activée, vous risquez d’épuiser l’espace disque disponible et de bloquer le serveur ou le service d’application.
Consultez Configuration avec web.config pour obtenir un exemple d’élément aspNetCore
dans le fichier web.config
.
La configuration du proxy utilise le protocole HTTP et un jeton d’appariement
S’applique uniquement à l’hébergement out-of-process.
Le proxy créé entre le module ASP.NET Core et Kestrel utilise le protocole HTTP. Il n’existe aucun risque d’écoute clandestine du trafic entre le module et Kestrel à partir d’un emplacement sur le serveur.
Un jeton d’appairage est utilisé pour garantir que les demandes reçues par Kestrel ont été traitées par IIS et ne proviennent pas d’une autre source. Le jeton d’appariement est créé et défini dans une variable d’environnement (ASPNETCORE_TOKEN
) par le module. Le jeton d’appariement est également défini dans un en-tête (MS-ASPNETCORE-TOKEN
) sur toutes les demandes traitées. L'intergiciel IIS vérifie chaque demande qu’il reçoit pour confirmer que la valeur d’en-tête du jeton d'appariement correspond à la valeur de la variable d’environnement. Si les valeurs de jeton ne correspondent pas, la demande est connectée et rejetée. La variable d’environnement du jeton d'appairage et le trafic entre le module et Kestrel ne sont pas accessibles à partir d’un emplacement sur le serveur. Sans connaître la valeur du jeton d'appariement, une personne malveillante ne peut pas soumettre des demandes qui contournent la vérification de l’intergiciel IIS.
Module ASP.NET Core avec une configuration partagée IIS
Le programme d’installation du module ASP.NET Core s’exécute avec les privilèges du compte TrustedInstaller
. Comme le compte système local n’a pas l’autorisation de modifier le chemin de partage utilisé par la configuration partagée IIS, le programme d’installation génère une erreur d’accès refusé pendant la tentative de configuration des paramètres du module dans le fichier applicationHost.config
du partage.
Quand une configuration partagée IIS est utilisée sur la même machine que l’installation IIS, il convient d’exécuter le programme d’installation du bundle d’hébergement ASP.NET Core avec le paramètre OPT_NO_SHARED_CONFIG_CHECK
défini sur 1
:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
Quand le chemin de la configuration partagée ne se trouve pas sur la même machine que l’installation IIS, effectuez ces étapes :
- Désactivez la configuration partagée IIS.
- Exécutez le programme d’installation.
- Exportez le fichier
applicationHost.config
mis à jour vers le partage. - Réactivez la configuration partagée IIS.
Version du module et journaux du programme d’installation du bundle d’hébergement
Pour déterminer la version du module ASP.NET Core installé :
- Sur le système d’hébergement, accédez à
%windir%\System32\inetsrv
. - Localisez le fichier
aspnetcore.dll
. - Cliquez avec le bouton droit sur le fichier, puis sélectionnez Propriétés dans le menu contextuel.
- Sélectionnez l'onglet Détails. Le version du fichier et la version du produit représentent la version installée du module.
Les journaux du programme d’installation du bundle d’hébergement du module se trouvent dans C:\\Users\\%UserName%\\AppData\\Local\\Temp
. Le fichier est nommé dd_DotNetCoreWinSvrHosting__\{TIMESTAMP}_000_AspNetCoreModule_x64.log
, où l’espace réservé {TIMESTAMP}
est le timestamp.
Emplacements des fichiers du module, du schéma et de configuration
Module
IIS (x86/amd64) :
%windir%\System32\inetsrv\aspnetcore.dll
%windir%\SysWOW64\inetsrv\aspnetcore.dll
%ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll
IIS Express (x86/amd64) :
%ProgramFiles%\IIS Express\aspnetcore.dll
%ProgramFiles(x86)%\IIS Express\aspnetcore.dll
%ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll
schéma
IIS
%windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml
%windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml
IIS Express
%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml
%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml
Configuration
IIS
%windir%\System32\inetsrv\config\applicationHost.config
IIS Express
Visual Studio :
{APPLICATION ROOT}\.vs\config\applicationHost.config
iisexpress.exe CLI :
%USERPROFILE%\Documents\IISExpress\config\applicationhost.config
Vous trouverez les fichiers en recherchant aspnetcore
dans le fichier applicationHost.config
.
Le module ASP.NET Core (ANCM) est un module IIS natif qui se connecte au pipeline IIS pour transférer les demandes web aux applications ASP.NET Core back-end.
Versions de Windows prises en charge :
- Windows 7 ou version ultérieure
- Windows Server 2008 R2 ou version ultérieure
Le module fonctionne seulement avec Kestrel. Le module n’est pas compatible avec HTTP.sys.
Étant donné que les applications ASP.NET Core s’exécutent dans un processus distinct du processus de travail IIS, le module traite également la gestion des processus. Le module démarre le processus de l’application ASP.NET Core quand la première requête arrive et redémarre l’application si elle plante. Il s’agit essentiellement du même comportement que celui des applications ASP.NET 4.x qui s’exécutent in-process dans IIS et sont gérées par le service WAS (Windows Activation Service).
Le schéma suivant illustre la relation entre IIS, le module ASP.NET Core et une application :
Les requêtes arrivent du web au pilote HTTP.sys en mode noyau. Le pilote route les requêtes vers IIS sur le port configuré du site web, généralement 80 (HTTP) ou 443 (HTTPS). Le module réachemine les requêtes vers Kestrel sur un port aléatoire pour l’application, qui n’est pas le port 80 ou le port 443.
Le module spécifie le port via une variable d’environnement au démarrage, et le middleware d’intégration IIS configure le serveur pour qu’il écoute sur http://localhost:{port}
. Des vérifications supplémentaires sont effectuées, et les requêtes qui ne proviennent pas du module sont rejetées. Le module ne prend pas en charge le transfert HTTPS : les requêtes sont donc transférées via HTTP, même si IIS les reçoit via HTTPS.
Une fois que Kestrel a récupéré la requête en provenance du module, celle-ci est envoyée (push) vers le pipeline de middleware ASP.NET Core. Le pipeline de middlewares traite la requête et la passe en tant qu’instance de HttpContext
à la logique de l’application. Le middleware ajouté par l’intégration d’IIS met à jour le schéma, l’adresse IP distante et la base du chemin pour prendre en compte le réacheminement de la requête vers Kestrel. La réponse de l’application est ensuite repassée à IIS, qui la renvoie au client HTTP à l’origine de la requête.
De nombreux modules natifs, comme l’authentification Windows, restent actifs. Pour obtenir plus d’informations sur les modules IIS actifs avec le module ASP.NET Core, consultez Modules IIS avec ASP.NET Core.
Le module ASP.NET Core peut également :
- Définir des variables d’environnement pour le processus de travail.
- Journaliser la sortie de stdout dans un stockage de fichiers pour résoudre les problèmes de démarrage.
- Transférer des jetons d’authentification Windows.
Comment installer et utiliser le module ASP.NET Core (ANCM)
Pour obtenir des instructions sur l’installation du module ASP.NET Core, consultez Installer le bundle d’hébergement .NET Core.
Configuration 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>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
Le fichier web.config suivant est publié pour un déploiement autonome :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\MyApp.exe"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
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 d’accès enregistre les journaux stdout dans le dossier LogFiles, un emplacement automatiquement créé par le service.
Pour obtenir des informations sur la configuration de sous-application IIS, consultez Héberger ASP.NET Core sur Windows avec IIS.
Attributs de l’élément aspNetCore
Attribut | Description | Default |
---|---|---|
arguments |
Attribut de chaîne facultatif. Arguments pour l’exécutable spécifié dans processPath. |
|
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 web.config est prioritaire. |
false |
forwardWindowsAuthToken |
Attribut booléen facultatif. Si la valeur est true, le jeton est transmis au processus enfant qui écoute sur %ASPNETCORE_PORT% sous la forme d’un en-tête 'MS-ASPNETCORE-WINAUTHTOKEN' par demande. Il incombe à ce processus d’appeler CloseHandle sur ce jeton par demande. |
true |
processesPerApplication |
Attribut entier facultatif. Spécifie le nombre d’instances du processus indiqué dans le paramètre processPath qui peuvent être lancées par application. Il est déconseillé de définir |
Valeur par défaut : 1 Min : 1 Max : 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 processPath est autorisé à se bloquer par minute. Si cette limite est dépassée, le module arrête le lancement du processus pour le reste de la minute. |
Valeur par défaut : 10 Min : 0 Max : 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 |
Valeur par défaut : 00:02:00 Min : 00:00:00 Max : 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 : 10 Min : 0 Max : 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. Le module tente de relancer le processus lorsqu’il reçoit une nouvelle requête, puis continue d’essayer de redémarrer le processus pour les requêtes entrantes suivantes, sauf si l’application ne démarre pas rapidFailsPerMinute un certain nombre de fois au cours de la dernière minute. La valeur 0 (zéro) n’est pas considérée comme un délai infini. |
Valeur par défaut : 120 Min : 0 Max : 3600 |
stdoutLogEnabled |
Attribut booléen facultatif. Si la valeur est true, les attributs stdout et stderr du processus spécifié dans processPath sont redirigés vers le fichier spécifié dans stdoutLogFile. |
false |
stdoutLogFile |
Attribut de chaîne facultatif. Spécifie le chemin d’accès relatif ou absolu pour lequel les attributs stdout et stderr du processus spécifié dans processPath sont consignés. Les chemins d’accès relatifs sont relatifs par rapport à la racine du site. Tout chemin d’accès commençant par |
aspnetcore-stdout |
Définition 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>
.
Avertissement
Les variables d’environnement définies dans cette section sont en conflit avec les variables d’environnement système qui ont le même nom. Si une variable d’environnement est définie à la fois dans le fichier web.config et au niveau du système dans Windows, la valeur provenant du fichier web.config est ajoutée à la valeur de la variable d’environnement système (par exemple, ASPNETCORE_ENVIRONMENT: Development;Development
), ce qui empêche le démarrage de l’application.
L’exemple suivant définit deux variables d'environnement. 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’exception de 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="\\?\%home%\LogFiles\stdout">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
<environmentVariable name="CONFIG_DIR" value="f:\application_config" />
</environmentVariables>
</aspNetCore>
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.
app_offline.htm
Si un fichier portant le nom app_offline.htm
est détecté dans le répertoire racine d’une application, le module ASP.NET Core tente d’arrêter normalement l’application, puis interrompt le traitement des demandes entrantes. Si l’application est toujours active après le nombre de secondes défini dans shutdownTimeLimit
, le module ASP.NET Core met fin au processus en cours d’exécution.
Tant que le fichier app_offline.htm
est présent, le module ASP.NET Core répond aux requêtes en renvoyant le contenu du fichier app_offline.htm
. Lorsque le fichier app_offline.htm
est supprimé, la requête suivante démarre l’application.
Page d’erreur de démarrage
Si le module ASP.NET Core ne peut pas lancer le processus backend ou que ce dernier démarre mais ne parvient pas à écouter sur le port configuré, une page de code d’état 502.5 - Échec du processus s’affiche. Pour supprimer cette page et revenir à la page IIS de code d’état 502 par défaut, utilisez l’attribut disableStartUpErrorPage
. Pour plus d’informations sur la configuration des messages d’erreur personnalisés, consultez Erreurs HTTP <httpErrors>.
Création et redirection de journal
Le module ASP.NET Core redirige la sortie de console stdout et stderr vers le disque si les attributs stdoutLogEnabled
et stdoutLogFile
de l’élément aspNetCore
sont définis. Tous les dossiers du chemin stdoutLogFile
sont créés par le module au moment de la création du fichier journal. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\<app_pool_name>
pour fournir les autorisations d’écriture).
Aucune rotation n’est appliquée aux journaux, sauf en cas de recyclage/redémarrage du processus. Il incombe à l’hébergeur de limiter l’espace disque utilisé par les journaux.
L’utilisation du journal stdout est recommandée uniquement pour résoudre les problèmes de démarrage d’application lors de l’hébergement sur IIS ou lors de l’utilisation de la prise en charge au moment du développement pour IIS avec Visual Studio, et non lors du débogage local et de l’exécution de l’application avec IIS Express.
N’utilisez pas le journal stdout à des fins de journalisation d’application générale. Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.
Un horodatage et une extension de fichier sont ajoutés automatiquement quand le fichier journal est créé. Le nom du fichier journal est créé en ajoutant l’horodatage, un ID de processus et une extension de fichier (.log) au dernier segment du chemin d'accès stdoutLogFile
(généralement stdout), séparés par des traits de soulignement. Si le chemin d'accès stdoutLogFile
se termine par stdout, un journal pour une application avec un PID de 1934 créé le 5/2/2018 à 19:42:32 affiche le nom de fichier stdout_20180205194132_1934.log.
L’exemple d’élément aspNetCore
suivant configure la journalisation stdout au niveau du chemin d’accès relatif .\log\
. Vérifiez que l’identité de l’utilisateur AppPool à l’autorisation d’écrire dans le chemin d’accès fourni.
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout">
</aspNetCore>
Lors de la publication d’une application pour le déploiement d’Azure App Service, le SDK web définit la valeur stdoutLogFile
sur \\?\%home%\LogFiles\stdout
. La variable d’environnement %home
est prédéfinie pour les applications hébergées par Azure App Service.
Pour créer des règles de filtre de journalisation, consultez la section Appliquer des règles de filtre de journal dans le code de la documentation de journalisation ASP.NET Core.
Pour plus d’informations sur les formats de chemin d’accès, consultez Formats de chemin d’accès aux fichiers sur les systèmes Windows.
La configuration du proxy utilise le protocole HTTP et un jeton d’appariement
Le proxy créé entre le module ASP.NET Core et Kestrel utilise le protocole HTTP. Il n’existe aucun risque d’écoute clandestine du trafic entre le module et Kestrel à partir d’un emplacement sur le serveur.
Un jeton d’appairage est utilisé pour garantir que les demandes reçues par Kestrel ont été traitées par IIS et ne proviennent pas d’une autre source. Le jeton d’appariement est créé et défini dans une variable d’environnement (ASPNETCORE_TOKEN
) par le module. Le jeton d’appariement est également défini dans un en-tête (MS-ASPNETCORE-TOKEN
) sur toutes les demandes traitées. L'intergiciel IIS vérifie chaque demande qu’il reçoit pour confirmer que la valeur d’en-tête du jeton d'appariement correspond à la valeur de la variable d’environnement. Si les valeurs de jeton ne correspondent pas, la demande est connectée et rejetée. La variable d’environnement du jeton d'appairage et le trafic entre le module et Kestrel ne sont pas accessibles à partir d’un emplacement sur le serveur. Sans connaître la valeur du jeton d'appariement, une personne malveillante ne peut pas soumettre des demandes qui contournent la vérification de l’intergiciel IIS.
Module ASP.NET Core avec une configuration partagée IIS
Le programme d’installation du module ASP.NET Core s’exécute avec les privilèges du compte TrustedInstaller. Comme le compte système local n’a pas l’autorisation de modifier le chemin de partage utilisé par la configuration partagée IIS, le programme d’installation génère une erreur d’accès refusé pendant la tentative de configuration des paramètres du module dans le fichier applicationHost.config du partage.
Lorsque vous utilisez une configuration partagée IIS, procédez comme suit :
- Désactivez la configuration partagée IIS.
- Exécutez le programme d’installation.
- Exportez le fichier applicationHost.config mis à jour vers le partage.
- Réactivez la configuration partagée IIS.
Version du module et journaux du programme d’installation du bundle d’hébergement
Pour déterminer la version du module ASP.NET Core installé :
- Sur le système hôte, accédez à %windir%\System32\inetsrv.
- Recherchez le fichier aspnetcore.dll.
- Cliquez avec le bouton droit sur le fichier, puis sélectionnez Propriétés dans le menu contextuel.
- Sélectionnez l'onglet Détails. Le version du fichier et la version du produit représentent la version installée du module.
Les journaux du programme d’installation du pack d’hébergement du module se trouvent dans C:\Users\%UserName%\AppData\Local\Temp. Le fichier est nommé dd_DotNetCoreWinSvrHosting__<timestamp>_000_AspNetCoreModule_x64.log.
Emplacements des fichiers du module, du schéma et de configuration
Module
IIS (x86/amd64) :
%windir%\System32\inetsrv\aspnetcore.dll
%windir%\SysWOW64\inetsrv\aspnetcore.dll
IIS Express (x86/amd64) :
%ProgramFiles%\IIS Express\aspnetcore.dll
%ProgramFiles(x86)%\IIS Express\aspnetcore.dll
schéma
IIS
- %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml
IIS Express
- %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml
Configuration
IIS
- %windir%\System32\inetsrv\config\applicationHost.config
IIS Express
Visual Studio : {RACINE DE L’APPLICATION}\.vs\config\applicationHost.config
iisexpress.exe CLI : %PROFILUTILISATEUR%\Documents\IISExpress\config\applicationhost.config
Vous trouverez les fichiers en recherchant aspnetcore dans le fichier applicationHost.config.
Ressources supplémentaires
- Héberger ASP.NET Core sur Windows avec IIS
- Déployer des applications ASP.NET Core sur Azure App Service
- Source de référence du module ASP.NET Core [branche par défaut (main)] : utilisez la liste déroulante Branche pour sélectionner une version spécifique (par exemple,
release/3.1
). - Modules IIS avec ASP.NET Core