Configuration avancée du module ASP.NET Core et d’IIS

Cet article décrit les options de configuration avancées et les scénarios pour le module ASP.NET Core et IIS.

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 le fichier web.config. La taille par défaut est de 1 048 576 octets (1 Mo). L’exemple suivant modifie la taille de la pile en spécifiant 2 Mo (2 097 152 octets) :

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

Interdire la rotation sur la configuration

Le paramètre disallowRotationOnConfigChange est destiné aux scénarios bleu/vert où une modification de la configuration globale ne doit pas entraîner le recyclage de tous les sites. Lorsque cet indicateur est true, seules les modifications pertinentes pour le site lui-même entraînent son recyclage. Par exemple, un site est recyclé si son fichier web.config change ou si quelque chose change qui se rapporte au chemin d’accès du site du point de vue d’IIS. Toutefois, une modification générale d’applicationHost.config n’entraînerait pas le recyclage d’une application. L’exemple suivant définit ce paramètre sur true :

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

Ce paramètre correspond à l’API ApplicationPoolRecycling.DisallowRotationOnConfigChange

Réduire la probabilité d’erreurs 503 pendant le recyclage de l’application

Par défaut, il y a un délai d’une seconde entre le moment où IIS est averti d’un recyclage ou d’un arrêt, et le moment où ANCM indique au serveur managé de lancer l’arrêt. Le délai est configurable via la variable d’environnement ANCM_shutdownDelay ou en définissant le paramètre du gestionnaire shutdownDelay. Les deux valeurs sont en millisecondes. Le délai est principalement destiné à réduire la probabilité d’une course où :

• IIS n’a pas démarré la mise en file d’attente des requêtes pour accéder à la nouvelle application.
• ANCM commence à rejeter les nouvelles requêtes qui entrent dans l’ancienne application.

Ce paramètre ne signifie pas que les requêtes entrantes seront retardées en raison de cette quantité. Le paramètre indique que l’ancienne instance d’application commence à arrêter une fois que le délai arrive à expiration. Les machines plus lentes ou sollicitant davantage le processeur risquent de devoir ajuster cette valeur pour réduire la probabilité d’erreurs 503.

L’exemple suivant définit le délai sur 5 secondes :

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="shutdownDelay" value="5000" />
  </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, un cyberattaquant ne peut pas soumettre de demandes qui contournent la vérification du middleware 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 :

1. Désactivez la configuration partagée IIS.
2. Exécutez le programme d’installation.
3. Exportez le fichier applicationHost.config mis à jour vers le partage de fichiers.
4. Réactivez la configuration partagée IIS.

Protection des données

La pile de protection des données ASP.NET Core est utilisée par plusieurs intergiciels (middlewares) ASP.NET Core, y compris l’intergiciel utilisé dans l’authentification. Même si les API de protection des données ne sont pas appelées par le code de l’utilisateur, la protection des données doit être configurée avec un script de déploiement ou dans un code utilisateur pour créer un magasin de clés de chiffrement persistantes. Si la protection des données n’est pas configurée, les clés sont conservées en mémoire et ignorées au redémarrage de l’application.

Si le porte-clés de protection des données est stocké en mémoire au redémarrage de l’application :

• Tous les jetons d’authentification basés sur cookie sont invalidés.
• Les utilisateurs doivent se reconnecter pour envoyer leur prochaine demande.
• toutes les données protégées par le Key Ring ne peuvent plus être déchiffrées. Ceci peut inclure des jetons CSRF et des cookies TempData ASP.NET Core MVC.

Pour configurer la protection des données sous IIS afin de rendre persistante le Key Ring, adoptez l’une des approches suivantes :

• Créer des clés de registre de protection des données

  Les clés de protection des données utilisées par les applications ASP.NET Core sont stockées dans le registre externe aux applications. Afin de conserver les clés pour une application donnée, créez des clés de registre pour le pool d’applications.

  Pour les installations IIS autonomes hors d’une batterie de serveurs, le script PowerShell Provision-AutoGenKeys.ps1 de protection des données peut être utilisé pour chaque pool d’applications utilisé avec une application ASP.NET Core. Ce script crée une clé de registre dans le registre HKLM, accessible uniquement pour le compte du processus Worker du pool d’applications de l’application. Les clés sont chiffrées au rest à l’aide de DPAPI avec une clé à l’échelle de la machine.

  Dans les scénarios de batterie de serveurs Web, vous pouvez configurer une application afin qu’elle utilise un chemin UNC pour stocker son porte-clés de protection des données. Par défaut, les clés ne sont pas chiffrées. Vérifiez que les autorisations de fichiers pour le partage réseau sont limitées au compte Windows sous lequel l’application s’exécute. Un certificat X509 peut être utilisé pour protéger les clés au repos. Mettez en œuvre un mécanisme permettant aux utilisateurs de charger des certificats. Placez les certificats dans le magasin de certificats approuvés de l’utilisateur et vérifiez qu’ils sont disponibles sur toutes les machines où s’exécute l’application de l’utilisateur. Pour plus d’informations, consultez Configurer la protection des données ASP.NET Core.

• Configurer le pool d’applications IIS pour charger le profil utilisateur

  Ce paramètre se trouve dans la section Modèle de processus sous les Paramètres avancés du pool d’applications. Affectez la valeur True à Charger le profil utilisateur. Lorsqu’elle est définie sur True, les clés sont stockées dans le répertoire du profil utilisateur, protégées à l’aide de DPAPI avec une clé propre au compte d’utilisateur utilisé pour le pool d’applications. Les clés sont conservées dans le dossier %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

  L’attribut setProfileEnvironment du pool d’applications doit également être activé. La valeur par défaut de setProfileEnvironment est true. Dans certains scénarios (par exemple pour le système d’exploitation Windows), setProfileEnvironment est défini sur false. Si les clés ne sont pas stockées dans le répertoire de profil utilisateur comme prévu :

  1. Accédez au dossier %windir%/system32/inetsrv/config.
  2. Ouvrez le fichier applicationHost.config .
  3. Recherchez l’élément <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Confirmez que l’attribut setProfileEnvironment n’est pas présent, ce qui implique que la valeur par défaut est true, ou définissez de manière explicite la valeur de l’attribut sur true.

• Utiliser le système de fichiers comme magasin de Key Ring

  Ajustez le code d’application pour utiliser le système de fichiers comme magasin de porte-clés. Utilisez un certificat X509 pour protéger le Key Ring et vérifiez qu’il s’agit d’un certificat approuvé. S’il s’agit d’un certificat auto-signé, placez-le dans le magasin Racine approuvée.

  Quand vous utilisez IIS dans une batterie de serveurs web :

  • Utilisez un partage de fichiers accessible par tous les ordinateurs.
  • Déployez un certificat X509 sur chaque ordinateur. Configurez la protection des données dans le code.

• Définir une stratégie au niveau de l’ordinateur pour la protection des données

  Le système de protection des données offre une prise en charge limitée de la définition d’une stratégie au niveau de l’ordinateur par défaut pour toutes les applications qui utilisent les API de protection des données. Pour plus d’informations, consultez Vue d’ensemble de la protection des données ASP.NET Core.

Configuration d’IIS

Systèmes d’exploitation Windows Server

Activez le rôle serveur Serveur Web (IIS) et établissez des services de rôle.

1. Utilisez l’Assistant Ajouter des rôles et des fonctionnalités par le biais du menu Gérer ou du lien dans Gestionnaire de serveur. À l’étape Rôles de serveurs, cochez la case Serveur Web (IIS).

   

2. Après l’étape Fonctionnalités, l’étape Services de rôle se charge pour le serveur Web (IIS). Sélectionnez les services de rôle IIS souhaités ou acceptez les services de rôle par défaut fournis.

   

   Authentification Windows (facultatif)
   Pour activer l’authentification Windows, développez les nœuds suivants : Serveur Web >Sécurité. Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez Authentification Windows <windowsAuthentication> et Configurer l’authentification Windows.

   WebSockets (facultatif)
   WebSockets est pris en charge avec ASP.NET Core 1.1 ou version ultérieure. Pour activer les WebSockets, développez les nœuds suivants : Serveur Web>Développement d’applications. Sélectionnez la fonctionnalité Protocole WebSocket. Pour plus d’informations, consultez WebSockets.

3. Validez l’étape de Confirmation pour installer les services et le rôle de serveur web. Un redémarrage du serveur/d’IIS n’est pas nécessaire après l’installation du rôle Serveur Web (IIS).

Systèmes d’exploitation Windows Desktop

Activez la Console de gestion IIS et les Services World Wide Web.

1. Naviguez jusqu’à Panneau de configuration>Programmes>Programmes et fonctionnalités>Activer ou désactiver des fonctionnalités Windows (à gauche de l’écran).

2. Ouvrez le nœud Internet Information Services. Ouvrez le nœud Outils de gestion Web.

3. Cochez la case Console de gestion IIS.

4. Cochez la case Services World Wide Web.

5. Acceptez les fonctionnalités par défaut pour Services World Wide Web ou personnalisez les fonctionnalités d’IIS.

   Authentification Windows (facultatif)
   Pour activer l’authentification Windows, développez les nœuds suivants : Services World Wide Web>Sécurité. Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez Authentification Windows <windowsAuthentication> et Configurer l’authentification Windows.

   WebSockets (facultatif)
   WebSockets est pris en charge avec ASP.NET Core 1.1 ou version ultérieure. Pour activer les WebSockets, développez les nœuds suivants : Services World Wide Web>Fonctionnalités de développement d’applications. Sélectionnez la fonctionnalité Protocole WebSocket. Pour plus d’informations, consultez WebSockets.

6. Si l’installation d’IIS requiert un redémarrage, redémarrez le système.

Répertoires virtuels

Les répertoires virtuels IIS ne sont pas pris en charge avec les applications ASP.NET Core. Une application peut être hébergée en tant que sous-application.

Sous-applications

Une application ASP.NET Core peut être hébergée en tant que sous-application IIS. Le chemin d'accès de la sous-application devient partie intégrante de l’URL de l’application racine.

Les liens de ressources statiques au sein de la sous-application doivent utiliser la notation tilde-barre oblique (~/) dans MVC et les pages Razor. La notation tilde-barre oblique déclenche un Tag Helper afin d’ajouter l’élément pathbase de la sous-application au lien relatif rendu. Pour une sous-application dans /subapp_path, une image liée à src="~/image.png" est restituée sous la forme src="/subapp_path/image.png". Le composant Static File Middleware de l’application racine ne traite la demande de fichiers statiques. La demande est traitée par le composant Static File Middleware de la sous-application.

Remarque

Les composants Razor (.razor) ne doivent pas utiliser la notation tilde-barre oblique. Pour plus d’informations, consultez la documentation sur le chemin de base de l’application Blazor.

Si l’attribut src d’une ressource statique est défini sur un chemin d’accès absolu (par exemple, src="/image.png"), le lien apparaît sans l’élément pathbase de la sous-application. Le composant Static File Middleware de l’application racine tente de traiter la ressource à partir de l’élément webroot de l’application racine, ce qui entraîne une erreur 404 - Introuvable, sauf si la ressource statique est disponible depuis l’application racine.

Pour héberger une application ASP.NET Core en tant que sous-application d’une autre application ASP.NET Core :

1. Établissez un pool d’applications pour la sous-application. Définissez la version CLR .NET sur Aucun code managé car la prise en charge du Common Language Runtime Core (CoreCLR) pour Core .Net est démarrée pour héberger l’application dans le processus Worker et non dans le Desktop CLR (CLR .Net).

2. Ajoutez le site racine dans IIS Manager en plaçant la sous-application dans un dossier du site racine.

3. Cliquez avec le bouton droit sur le dossier de la sous-application dans IIS Manager, puis sélectionnez Convertir en application.

4. Dans la boîte de dialogue Ajouter une application, utilisez le bouton Sélectionner de l’option Pool d’applications pour affecter le pool d’applications que vous avez créé pour la sous-application. Sélectionnez OK.

L’attribution d’un pool d’applications distinct à la sous-application est obligatoire lorsque vous utilisez le modèle d’hébergement in-process.

Pour plus d’informations sur le modèle d’hébergement in-process et la configuration du module ASP.NET Core, consultez Module ASP.NET Core (ANCM) pour IIS.

Pools d’applications

L’isolation des pools d’applications est déterminée par le modèle d’hébergement :

• Hébergement in-process : les applications doivent s’exécuter dans des pools d’applications distincts.
• Hébergement hors processus : nous vous recommandons d’isoler les applications les unes des autres en exécutant chaque application dans son propre pool d’applications.

La boîte de dialogue Ajouter un site web d’IIS applique un seul pool d’applications par application par défaut. Quand un Nom du site est fourni, le texte est automatiquement transféré vers la zone de texte Pool d’applications. Un nouveau pool d’applications est créé avec le nom du site une fois qu’il est ajouté.

Pool d’applications Identity

Un compte d’identity du pool d’applications permet à une application de s’exécuter sous un compte unique sans qu’il soit nécessaire de créer et de gérer des domaines ou des comptes locaux. Sur IIS 8.0 ou version ultérieure, le processus Worker d’administration IIS (WAS) crée un compte virtuel avec le nom du nouveau pool d’applications et exécute les processus Worker du pool d’applications sous ce compte par défaut. Dans la Console de gestion IIS, sous Paramètres avancés du pool d’applications, vérifiez que Identity est défini pour utiliser ApplicationPoolIdentity :

Le processus de gestion IIS crée un identificateur sécurisé avec le nom du pool d’applications dans le système de sécurité Windows. Les ressources peuvent être sécurisées à l’aide de cette identity. Toutefois, cette identity n’est pas un compte d’utilisateur réel et n’apparaît pas dans la console de gestion d’utilisateurs Windows.

Si le processus Worker IIS a besoin d’un accès élevé à l’application, modifiez la liste de contrôle d’accès (ACL) du répertoire contenant l’application :

1. Ouvrez l’Explorateur Windows et accédez au répertoire.

2. Cliquez avec le bouton droit sur le répertoire et sélectionnez Propriétés.

3. Sous l’onglet Sécurité, sélectionnez le bouton Modifier, puis le bouton Ajouter.

4. Sélectionnez le bouton Emplacements, puis vérifiez que le système est sélectionné.

5. Entrez le format IIS AppPool\{APP POOL NAME}, où l’espace réservé {APP POOL NAME} correspond au nom du pool d’applications, dans la zone Entrez les noms d’objets à sélectionner. Sélectionnez le bouton Vérifier les noms. Pour DefaultAppPool, vérifiez les noms en utilisant IIS AppPool\DefaultAppPool. Quand le bouton Vérifier les noms est sélectionné, la valeur DefaultAppPool est indiquée dans la zone des noms d’objets. Il n’est pas possible d’entrer le nom du pool d’applications directement dans la zone des noms d’objets. Utilisez le format IIS AppPool\{APP POOL NAME}, où l’espace réservé {APP POOL NAME} correspond au nom du pool d’applications, quand vous vérifiez le nom de l’objet.

   

6. Cliquez sur OK.

   

7. Les autorisations Lire et exécuter doivent être accordées par défaut. Fournissez des autorisations supplémentaires si nécessaire.

L’accès peut également être octroyé par le biais d’une invite de commandes à l’aide de l’outil ICACLS. À l’aide de DefaultAppPool comme exemple, la commande suivante est utilisée pour accorder des autorisations de lecture et d’exécution sur le dossier MyWebApp, les sous-dossiers et les fichiers :

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

Pour plus d’informations, consultez la rubrique icacls.

Assistance HTTP/2

HTTP/2 est pris en charge avec ASP.NET Core dans les scénarios de déploiement IIS suivants :

• In-process
  • Windows Server 2016/Windows 10 ou version ultérieure ; IIS 10 ou version ultérieure
  • TLS 1.2 ou connexion ultérieure
• Out-of-process
  • Windows Server 2016/Windows 10 ou version ultérieure ; IIS 10 ou version ultérieure
  • Les connexions au serveur de périphérie public utilisent HTTP/2, mais la connexion par proxy inverse au serveur Kestrel utilise HTTP/1.1.
  • TLS 1.2 ou connexion ultérieure

Pour un déploiement in-process, quand une connexion HTTP/2 est établie, HttpRequest.Protocol signale HTTP/2. Pour un déploiement hors processus, quand une connexion HTTP/2 est établie, HttpRequest.Protocol signale HTTP/1.1.

Pour plus d’informations sur les modèles d’hébergement in-process et hors processus, consultez Module ASP.NET Core (ANCM) pour IIS.

HTTP/2 est activé par défaut. Les connexions reviennent à HTTP/1.1 si une connexion HTTP/2 n’est pas établie. Pour plus d’informations sur la configuration de HTTP/2 avec les déploiements IIS, consultez HTTP/2 sur IIS.

Requêtes préliminaires CORS

Cette section s’applique uniquement aux applications ASP.NET Core qui ciblent le .NET Framework.

Pour une application ASP.NET Core qui cible le .NET Framework, les requêtes OPTIONS ne sont pas transmises à l’application par défaut dans IIS. Pour savoir comment configurer les gestionnaires IIS de l’application dans web.config afin de passer les requêtes OPTIONS, consultez Activer les requêtes cross-origin dans l’API web ASP.NET 2 : Fonctionnement de CORS.

Module d’initialisation de l’application et délai d’inactivité

Quand ils sont hébergés dans IIS par le Module ASP.NET Core version 2 :

• Module d’initialisation de l’application : vous pouvez configurer le modèle d’hébergement in-process ou hors processus de l’application pour qu’il démarre automatiquement au redémarrage d’un processus de travail ou au redémarrage du serveur.
• Délai d’inactivité : les applications hébergées in-process peuvent être configurées pour ne pas dépasser le délai d'expiration pendant les périodes d’inactivité.

Module d’initialisation de l’application

S’applique aux applications hébergées in-process et hors processus.

L’Initialisation d’application IIS est une fonctionnalité IIS qui envoie une requête HTTP à l’application lorsque le pool d’applications démarre ou est recyclé. La requête déclenche le démarrage de l’application. Par défaut, IIS émet une requête à l’URL racine de l’application (/) pour initialiser l’application (consultez les ressources supplémentaires pour plus d’informations sur la configuration).

Vérifiez que la fonctionnalité de rôle Initialisation d’application IIS est activée :

Sur Windows 7 ou systèmes de bureau de version ultérieure lorsque vous utilisez IIS localement :

1. Naviguez jusqu’à Panneau de configuration>Programmes>Programmes et fonctionnalités>Activer ou désactiver des fonctionnalités Windows (à gauche de l’écran).
2. Ouvrez Internet Information Services>Services World Wide Web>Fonctionnalités de développement d’applications.
3. Cochez la case Initialisation de l’application.

Sur Windows Server 2008 R2 ou version ultérieure :

1. Ouvrez l’Assistant Ajout de rôles et de fonctionnalités.
2. Dans le panneau Sélectionnez les services de rôle, ouvrez le nœud Développement d’applications.
3. Cochez la case Initialisation de l’application.

Utilisez une des approches suivantes pour activer le Module d’initialisation de l’application pour le site :

• Utilisation du Gestionnaire IIS :

  1. Sélectionnez Pools d’applications dans le volet Connexions.
  2. Cliquez avec le bouton de droite sur le pool d’applications de l’application dans la liste, puis sélectionnez Paramètres avancés.
  3. La valeur par défaut Mode de démarrage est OnDemand. Définissez le Mode de démarrage sur AlwaysRunning. Sélectionnez OK.
  4. Ouvrez le nœud Sites dans le panneau Connexions.
  5. Cliquez avec le bouton de droite sur l’application et sélectionnez Gérer le site web>Paramètres avancés.
  6. Le paramètre par défaut Préchargement activé est False. Définissez Préchargement activé sur True. Sélectionnez OK.

• À l’aide de web.config, ajoutez l’élément <applicationInitialization> avec doAppInitAfterRestart défini sur true aux éléments <system.webServer> dans le fichier web.config de l’application :

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Délai d’inactivité

S’applique aux applications hébergées in-process.

Pour empêcher la mise en veille après une période d’inactivité de l’application, définissez le délai d’inactivité du pool d’applications à l’aide du Gestionnaire IIS :

1. Sélectionnez Pools d’applications dans le volet Connexions.
2. Cliquez avec le bouton de droite sur le pool d’applications de l’application dans la liste, puis sélectionnez Paramètres avancés.
3. La valeur par défaut Délai d’inactivité (minutes) est 20 minutes. Définissez le Délai d’inactivité (minutes) sur 0 (zéro). Sélectionnez OK.
4. Recyclez le processus Worker.

Pour empêcher les applications hébergées hors processus d’expirer, utilisez une des approches suivantes :

• Effectuez un test ping de l’application à partir d’un service externe afin de garantir son fonctionnement.
• Si l’application héberge uniquement les services d’arrière-plan, évitez l’hébergement IIS et utilisez un Service Windows pour héberger l’application ASP.NET Core.

Module d’initialisation de l’application et ressources supplémentaires du délai d’inactivité

• Initialisation de l’application IIS 8.0
• Initialisation d’application <applicationInitialization>.
• Paramètres de modèle de processus pour un pool d’applications <processModel>.

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.

Installer Web Deploy lors de la publication avec Visual Studio

Quand vous déployez des applications sur un serveur avec Web Deploy, installez la dernière version de Web Deploy sur le serveur. Pour installer Web Deploy, consultez Téléchargements IIS : Web Deploy.

Créer le site IIS

1. Sur le système d’hébergement, créez un dossier pour contenir les fichiers et dossiers publiés de l’application. À l’étape suivante, le chemin du dossier est fourni à IIS en tant que chemin d’accès physique à l’application. Pour plus d’informations sur le dossier de déploiement et le layout des fichiers d’une application, consultez Structure de répertoires ASP.NET Core.

2. Dans le Gestionnaire IIS, ouvrez le nœud du serveur dans le panneau Connexions. Cliquez avec le bouton de droite sur le dossier Sites. Sélectionnez Ajouter un site Web dans le menu contextuel.

3. Spécifiez le Nom du site et définissez le Chemin physique sur le dossier de déploiement de l’application. Spécifiez la configuration Liaison et créez le site Web en sélectionnant OK :

   

   Avertissement

   Les liaisons génériques de niveau supérieur (http://*:80/ et http://+:80) ne doivent pas être utilisées. Les liaisons génériques de niveau supérieur peuvent exposer votre application à des failles de sécurité. Cela s’applique aux caractères génériques forts et faibles. Utilisez des noms d’hôte explicites plutôt que des caractères génériques. Une liaison générique de sous-domaine (par exemple, *.mysub.com) ne présente pas ce risque de sécurité si vous contrôlez le domaine parent en entier (par opposition à *.com, qui est vulnérable). Pour plus d’informations, consultez RFC 9110 : Sémantique HTTP (Section 7.2 : Hôte et :authority).

4. Sous le nœud du serveur, sélectionnez Pools d’applications.

5. Cliquez avec le bouton de droite sur le pool d’applications du site et sélectionnez Paramètres de base dans le menu contextuel.

6. Dans la fenêtre Modifier le pool d’applications, définissez la version .NET CLR sur Aucun code managé :

   

   ASP.NET Core s’exécute dans un processus séparé et gère l’exécution. ASP.NET Core ne repose pas sur le chargement du Desktop CLR (.NET CLR). Le CoreCLR (Core Common Language Runtime) pour .NET Core démarre pour héberger l’application dans le processus de travail. La configuration de la version CLR .NET sur Aucun code managé est facultative, mais recommandée.

   • Pour un déploiement autonome 32 bits (x86) publié avec un kit SDK 32 bits qui utilise le modèle d’hébergement in-process, activez le pool d’applications pour 32 bits. Dans le Gestionnaire IIS, accédez à Pools d’applications dans la barre latérale Connexions. Sélectionnez le pool d’applications de l’application. Dans la barre latérale Actions, sélectionnez Paramètres avancés. Affectez à Activer les applications 32 bits la valeur True.

   • Pour un déploiement autonome 64 bits (x64) qui utilise le modèle d’hébergement in-process, désactivez le pool d’applications pour les processus 32 bits (x86). Dans le Gestionnaire IIS, accédez à Pools d’applications dans la barre latérale Connexions. Sélectionnez le pool d’applications de l’application. Dans la barre latérale Actions, sélectionnez Paramètres avancés. Affectez à Activer les applications 32 bits la valeur False.

7. Vérifiez que l’identity de modèle de processus dispose des autorisations appropriées.

   Si l’identity par défaut du pool d’applications (Modèle de processus>Identity) change, et passe d’ApplicationPoolIdentity à une autre identity, vérifiez que la nouvelle identity dispose des autorisations nécessaires pour accéder au dossier, à la base de données et aux autres ressources nécessaires de l’application. Par exemple, le pool d’applications nécessite l’accès en lecture et en écriture aux dossiers dans lesquels l’application lit et écrit des fichiers.

Configuration de l’authentification Windows (facultatif)
Pour plus d'informations, consultez la rubrique Configurer l’authentification Windows.

Cliché instantané

La prise de clichés instantanés des assemblys d’application dans le module ASP.NET Core (ANCM) pour IIS peut offrir une meilleure expérience utilisateur que l’arrêt de l’application en déployant un fichier App Offline.

Lorsqu’une application ASP.NET Core est en cours d’exécution sur Windows, les fichiers binaires sont verrouillés pour ne pas être modifiés ni remplacés. La prise d’un cliché instantané permet de mettre à jour les assemblys d’application pendant l’exécution de l’application en effectuant une copie des assemblys.

La prise d’un cliché instantané n’est pas destinée à activer le déploiement sans temps d’arrêt. Il est donc prévu qu’IIS recycle toujours l’application, et certaines demandes peuvent obtenir une réponse 503 Service indisponible. Nous recommandons l’utilisation d’un modèle semblable à celui des déploiements bleu-vert ou des emplacements de déploiement Azure pour obtenir des déploiements sans temps d’arrêt. La prise d’un cliché instantané permet de réduire les temps d’arrêt sur les déploiements, mais ne peut pas les éliminer complètement.

La prise d’un cliché instantané est activé en personnalisant les paramètres du gestionnaire ANCM dans web.config :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>