Héberger ASP.NET Core sur Windows avec IIS

Article
11/06/2024

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.

IIS (Internet Information Services) est un serveur web flexible, sécurisé et gérable pour l’hébergement d’applications web, notamment ASP.NET Core.

Plateformes prises en charge

Les systèmes d’exploitation pris en charge sont les suivants :

Windows 7 ou version ultérieure
Windows Server 2012 R2 ou version ultérieure

Les applications publiées pour les déploiements 32 bits (x86) ou 64 bits (x64) sont prises en charge. Déployez une application 32 bits avec un kit SDK .NET Core (x86) de 32 bits, sauf si l’application :

Nécessite l’espace d’adressage de mémoire virtuelle le plus grand disponible pour une application 64 bits.
Nécessite la taille de pile IIS la plus grande disponible.
A des dépendances natives 64 bits.

Installer le module/bundle d’hébergement ASP.NET Core

Téléchargez le dernier programme d’installation à l’aide du lien suivant :

Programme d’installation du bundle d’hébergement .NET Core actuel (téléchargement direct)

Pour obtenir des instructions plus détaillées sur l’installation du module ASP.NET Core ou sur l’installation de versions distinctes, consultez Installer le bundle d’hébergement .NET Core.

Pour télécharger les versions précédentes de l’offre groupée d’hébergement, consultez ce problème GitHub.

Bien démarrer

Pour bien démarrer l’hébergement d’un site web sur IIS, consultez notre guide de démarrage.

Pour bien démarrer l’hébergement d’un site web sur Azure App Services, consultez notre guide de déploiement sur Azure App Service.

Configuration

Pour obtenir des conseils d’aide relatifs à la configuration, consultez Configuration avancée.

Déploiement de ressources pour les administrateurs IIS

Chevauchement de recyclage

En règle générale, nous recommandons l’utilisation d’un modèle semblable à celui des déploiements bleu-vert pour les déploiements sans temps d’arrêt. Les fonctionnalités telles que le chevauchement de recyclage peuvent être utiles. Toutefois, elles ne garantissent pas que vous pouvez effectuer un déploiement sans temps d’arrêt. Pour plus d’informations, consultez ce problème GitHub.

Certificats clients facultatifs

Pour plus d’informations sur les applications qui doivent protéger un sous-ensemble de l’application avec un certificat, consultez Certificats clients facultatifs.

Ressources supplémentaires

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.

Installer le bundle d’hébergement .NET Core

Systèmes d’exploitation pris en charge

Les systèmes d’exploitation pris en charge sont les suivants :

Windows 7 ou version ultérieure
Windows Server 2012 R2 ou version ultérieure

Le serveur HTTP.sys (anciennement WebListener) ne fonctionne pas dans une configuration de proxy inverse avec IIS. Utilisez le serveur Kestrel.

Pour plus d’informations sur l’hébergement dans Azure, consultez Déployer des applications ASP.NET Core sur Azure App Service.

Pour obtenir des conseils d’aide sur la résolution des problèmes, consultez Résoudre les problèmes et effectuer le débogage des projets ASP.NET Core.

Plateformes prises en charge

Nécessite l’espace d’adressage de mémoire virtuelle le plus grand disponible pour une application 64 bits.
Nécessite la taille de pile IIS la plus grande disponible.
A des dépendances natives 64 bits.

Les applications publiées pour les architectures 32 bits (x86) doivent avoir l’architecture 32 bits activée pour leurs pools d’applications IIS. Pour plus d’informations, consultez la section Créer le site IIS.

Utilisez un kit SDK .NET Core 64 bits (x64) pour publier une application 64 bits. Un runtime 64 bits doit être présent sur le système hôte.

Modèles d'hébergement

Modèle d’hébergement in-process

En utilisant l’hébergement in-process, une application ASP.NET Core s’exécute dans le même processus que son processus de travail IIS. L’hébergement in-process offre de meilleures performances que l’hébergement out-of-process parce que les requêtes n’ont pas de proxy sur l’adaptateur de bouclage, interface réseau qui retourne du trafic réseau sortant à la même machine. IIS s’occupe de la gestion des processus par l’intermédiaire du service d’activation des processus Windows (WAS).

Le module ASP.NET Core :

Effectue l’initialisation de l’application.
- Charge le CoreCLR.
- Appelle Program.Main.
Gère la durée de vie de la requête native IIS.

Le schéma suivant montre la relation entre IIS, le module ASP.NET Core et une application hébergée dans un processus :

Module ASP.NET Core dans le scénario d’hébergement in-process

Une requête arrive du web au pilote HTTP.sys en mode noyau.
Le pilote achemine la requête native vers IIS sur le port configuré du site web, généralement 80 (HTTP) ou 443 (HTTPS).
Le module ASP.NET Core reçoit la requête native et la passe au serveur HTTP IIS (IISHttpServer). Le serveur HTTP IIS est une implémentation du serveur in-process pour IIS qui convertit la requête native en requête managée.

Une fois la requête traitée par le serveur HTTP IIS :

La requête est envoyée au pipeline de middleware (intergiciel) 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.
La réponse de l’application est retransmise à IIS via le serveur HTTP IIS.
IIS envoie la réponse au client qui a initié la demande.

L’hébergement in-process est accepté pour les applications existantes. Les modèles web ASP.NET Core utilisent le modèle d’hébergement in-process.

CreateDefaultBuilder ajoute une instance de IServer en appelant la méthode UseIIS pour démarrer le CoreCLR et héberger l’application dans le processus de travail IIS (w3wp.exe ou iisexpress.exe). Les tests de performances indiquent que l’hébergement d’une application .NET Core in-process offre un débit de requêtes nettement plus élevé que l’hébergement de l’application hors processus et la proxysation des requêtes vers Kestrel.

Les applications publiées comme un fichier exécutable unique ne peuvent pas être chargées par le modèle d’hébergement in-process.

Modèle d’hébergement out-of-process

Dans la mesure où les applications ASP.NET Core s’exécutent au sein d’un processus distinct du processus de travail IIS, le module ASP.NET Core prend en charge la gestion des processus. Le module démarre le processus pour l’application ASP.NET Core quand la première requête arrive, et il redémarre l’application si elle s’arrête ou se bloque. Il s’agit essentiellement du même comportement que celui des applications s’exécutant in-process, et qui sont gérées par le service d’activation des processus Windows (WAS).

Le schéma suivant illustre la relation entre IIS, le module ASP.NET Core et une application hébergée hors processus :

Module ASP.NET Core dans le scénario d’hébergement out-of-process

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. Le port configuré est généralement le port 80 (HTTP) ou le port 443 (HTTPS).
Le module réachemine les requêtes vers Kestrel sur un port aléatoire pour l’application. Le port aléatoire n’est pas 80 ou 443.

Le module ASP.NET Core spécifie le port via une variable d’environnement au démarrage. L’extension UseIISIntegration 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 réacheminement HTTPS. Les requêtes sont réacheminées via HTTP même si elles sont reçues par IIS via HTTPS.

Une fois que Kestrel a récupéré la requête en provenance du module, celle-ci est réacheminée 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 repassée à IIS, qui la réachemine au client HTTP ayant lancé la requête.

Pour obtenir des conseils d’aide sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core (ANCM) pour IIS.

Pour plus d’informations sur l’hébergement, consultez Héberger dans ASP.NET Core.

Configuration de l’application

Activer les composants IISIntegration

Durant la génération d’un hôte dans CreateHostBuilder (Program.cs), appelez CreateDefaultBuilder pour activer l’intégration d’IIS :

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

Pour plus d’informations sur CreateDefaultBuilder, consultez Hôte générique .NET dans ASP.NET Core.

Options IIS

Modèle d’hébergement in-process

Pour configurer les options IIS Server, incluez une configuration de service pour IISServerOptions dans ConfigureServices. L’exemple suivant désactive AutomaticAuthentication :

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});

Option	Default	Paramètre
`AutomaticAuthentication`	`true`	Si `true`, IIS Server définit le `HttpContext.User` authentifié par Authentification Windows. Si `false`, le serveur fournit uniquement une identity pour `HttpContext.User` et répond aux questions explicitement posées par `AuthenticationScheme`. L’authentification Windows doit être activée dans IIS pour que `AutomaticAuthentication` fonctionne. Pour plus d'informations, consultez Authentification Windows.
`AuthenticationDisplayName`	`null`	Définit le nom d’affichage montré aux utilisateurs sur les pages de connexion.
`AllowSynchronousIO`	`false`	Indique si les E/S synchrones sont autorisées pour `HttpContext.Request` et `HttpContext.Response`.
`MaxRequestBodySize`	`30000000`	Récupère ou définit la taille maximale du corps de la demande de `HttpRequest`. Il est à noter que IIS a comme limite `maxAllowedContentLength`, qui doit être traité avant `MaxRequestBodySize` défini dans `IISServerOptions`. Les modifications de `MaxRequestBodySize` n’ont pas d’incidence sur `maxAllowedContentLength`. Pour augmenter `maxAllowedContentLength`, ajoutez une entrée dans `web.config` afin d’affecter à `maxAllowedContentLength` une valeur plus élevée. Pour plus d’informations, voir Configuration.

Modèle d’hébergement out-of-process

Pour configurer les options IIS, incluez une configuration de service pour IISOptions dans ConfigureServices. L’exemple suivant empêche l’application d’être renseignée HttpContext.Connection.ClientCertificate :

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Option	Default	Paramètre
`AutomaticAuthentication`	`true`	Si la valeur est `true`, le middleware d’intégration IIS définit l’élément `HttpContext.User` authentifié par Windows Authentication. Si `false`, le middleware fournit uniquement une identity pour `HttpContext.User` et répond aux questions explicitement posées par `AuthenticationScheme`. L’authentification Windows doit être activée dans IIS pour que `AutomaticAuthentication` fonctionne. Pour plus d'informations, consultez la rubrique Authentification Windows.
`AuthenticationDisplayName`	`null`	Définit le nom d’affichage montré aux utilisateurs sur les pages de connexion.
`ForwardClientCertificate`	`true`	Si la valeur est `true` et que l’en-tête de requête `MS-ASPNETCORE-CLIENTCERT` est présent, `HttpContext.Connection.ClientCertificate` est renseigné.

Scénarios avec un serveur proxy et un équilibreur de charge

Le middleware d’intégration d’IIS et le module ASP.NET Core sont configurés pour réacheminer les éléments suivants :

Schéma (HTTP/HTTPS).
Adresse IP distante d’où provient la requête.

Le middleware d’intégration d’IIS configure le middleware des en-têtes réacheminés.

Une configuration supplémentaire peut être nécessaire pour les applications hébergées derrière des serveurs proxy et des équilibreurs de charge supplémentaires. Pour plus d’informations, consultez l’article Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

Fichier `web.config`

Le fichier web.config configure le module ASP.NET Core. La création, la transformation et la publication du fichier web.config sont gérées par une cible MSBuild (_TransformWebConfig) au moment de la publication du projet. Cette cible est présente dans les cibles du SDK web (Microsoft.NET.Sdk.Web). Le SDK est défini en haut du fichier projet :

<Project Sdk="Microsoft.NET.Sdk.Web">

Si le projet ne contient pas de fichier web.config, celui-ci est créé avec le processPath et les arguments appropriés pour configurer le module ASP.NET Core, puis il est déplacé vers la sortie publiée.

Si le projet contient un fichier web.config, celui-ci est transformé avec le processPath et les arguments appropriés pour configurer le module ASP.NET Core, puis il est déplacé vers la sortie publiée. La transformation ne modifie pas les paramètres de configuration IIS dans le fichier.

Le fichier web.config peut fournir des paramètres de configuration IIS supplémentaires qui contrôlent les modules IIS actifs. Pour plus d’informations sur les modules IIS capables de traiter les requêtes avec des applications ASP.NET Core, consultez la rubrique Modules IIS.

Pour empêcher le kit SDK web de transformer le fichier web.config, utilisez la propriété <IsTransformWebConfigDisabled> dans le fichier projet :

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Quand vous désactivez le kit SDK web pour empêcher la transformation du fichier, processPath et arguments doivent être définis manuellement par le développeur. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

Emplacement du fichier `web.config`

Pour que la configuration du module ASP.NET Core soit réussie, le fichier web.config doit être présent dans le chemin de la racine du contenu (généralement le chemin de base) de l’application déployée. Il s’agit du même emplacement que le chemin physique du site Web fourni à IIS. Le fichier web.config est nécessaire à la racine de l’application pour permettre la publication de plusieurs applications à l’aide de Web Deploy.

Il existe des fichiers sensibles dans le chemin physique de l’application, par exemple {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (commentaires de documentation XML) et {ASSEMBLY}.deps.json, où l’espace réservé {ASSEMBLY} correspond au nom de l’assembly. Quand le fichier web.config est présent et que le site démarre normalement, IIS ne traite pas ces fichiers sensibles s’ils sont demandés. Si le fichier web.config est manquant, s’il est nommé de manière incorrecte ou s’il ne permet pas de configurer le site pour un démarrage normal, IIS peut traiter les fichiers sensibles de manière publique.

Le fichier web.config doit être présent à tout moment dans le déploiement, il doit être correctement nommé et permettre la configuration du site pour un démarrage normal. Ne retirez jamais le fichier web.config d’un déploiement de production.

Transformer web.config

Si vous devez transformer web.config au moment de la publication, consultez Transformer web.config. Vous devrez peut-être transformer web.config au moment de la publication pour définir les variables d’environnement en fonction de la configuration, du profil ou de l’environnement.

Configuration d’IIS

Systèmes d’exploitation Windows Server

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

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).
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.
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.

Naviguez jusqu’à Panneau de configuration>Programmes>Programmes et fonctionnalités>Activer ou désactiver des fonctionnalités Windows (à gauche de l’écran).
Ouvrez le nœud Internet Information Services. Ouvrez le nœud Outils de gestion Web.
Cochez la case Console de gestion IIS.
Cochez la case Services World Wide Web.
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.
Si l’installation d’IIS requiert un redémarrage, redémarrez le système.

Console de gestion IIS et Services World Wide Web sont sélectionnés dans Fonctionnalités de Windows.

Installer le bundle d’hébergement .NET Core

Installez le bundle d’hébergement .NET Core sur le système hôte. Le bundle installe le Runtime .NET Core, la bibliothèque .NET Core et le Module ASP.NET Core. Le module permet aux applications ASP.NET Core de s’exécuter derrière IIS.

Important

Si le bundle d’hébergement est installé avant IIS, l’installation du bundle doit être réparée. Après avoir installé IIS, réexécutez le programme d’installation du bundle d’hébergement.

Si le bundle d’hébergement est installé après l’installation de la version 64 bits (x 64) de .NET Core, les SDK peuvent apparaître manquants (Aucun SDK .NET Core n’a été détecté). Pour résoudre le problème, consultez Résoudre les problèmes et effectuer le débogage des projets ASP.NET Core.

Téléchargement direct (version actuelle)

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)

Versions antérieures du programme d’installation

Pour obtenir une version antérieure du programme d’installation :

Accédez à la page Télécharger .NET Core.
Sélectionnez la version souhaitée de .NET Core.
Dans la colonne Run apps - Runtime, recherchez la ligne de la version du runtime .NET Core souhaitée.
Téléchargez le programme d’installation à l’aide du lien Bundle de téléchargement.

Avertissement

Certains programmes d’installation contiennent des versions qui sont arrivées à leur fin de vie (EOL) et qui ne sont plus prises en charge par Microsoft. Pour plus d’informations, consultez la politique de support.

Installer le bundle d’hébergement

Exécutez le programme d’installation sur le serveur. Les paramètres suivants sont disponibles lorsque vous exécutez le programme d’installation à partir d’un shell de commande administrateur :
- OPT_NO_ANCM=1 : Permet d’ignorer l’installation du module ASP.NET Core.
- OPT_NO_RUNTIME=1 : Permet d’ignorer l’installation du runtime .NET Core. Utilisé quand le serveur héberge uniquement des déploiements autonomes (SCD).
- OPT_NO_SHAREDFX=1 : Permet d’ignorer l’installation du framework partagé ASP.NET (runtime ASP.NET). Utilisé quand le serveur héberge uniquement des déploiements autonomes (SCD).
- OPT_NO_X86=1 : Permet d’ignorer l’installation des runtimes x86. Utilisez ce paramètre lorsque vous savez que vous n’hébergerez pas d’applications 32 bits. Si vous n’excluez pas d’avoir à héberger des applications 32 bits et 64 bits dans le futur, n'utilisez pas ce paramètre et installez les deux runtimes.
- OPT_NO_SHARED_CONFIG_CHECK=1 : Permet de désactiver la vérification de l’utilisation d’une configuration partagée d’IIS quand la configuration partagée (applicationHost.config) se trouve sur la même machine que l’installation d’IIS. Disponible uniquement pour les programmes d’installation du pack d’hébergement ASP.NET Core 2.2 ou version ultérieure. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.
Le redémarrage d’IIS récupère une modification apportée au CHEMIN D’ACCÈS du système, qui est une variable d’environnement, par le programme d’installation. Pour redémarrer le serveur web, arrêtez le service d’activation des processus Windows (WAS), puis redémarrez le service de publication World Wide web (W3SVC). Redémarrez le système, ou exécutez les commandes suivantes dans un interpréteur de commandes avec élévation de privilèges :
```
net stop was /y
net start w3svc
```

ASP.NET Core n’adopte pas le comportement de restauration par progression pour les versions de patch des packages de framework partagé. Une fois que vous avez mis à niveau le framework partagé en installant un nouveau bundle d’hébergement, redémarrez le système, ou exécutez les commandes suivantes dans un interpréteur de commandes avec élévation de privilèges :

net stop was /y
net start w3svc

Remarque

Pour plus d’informations sur la configuration partagée IIS, consultez Module ASP.NET Core avec configuration partagée des services Internet (IIS).

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 l’Outil de déploiement Web, utilisez le Web Platform Installer (WebPI) ou consultez Téléchargements IIS : Web Deploy. La méthode recommandée est d’utiliser WebPI. WebPI offre une installation autonome et une configuration pour les fournisseurs d’hébergement.

Créer le site IIS

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.
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.
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).
Sous le nœud du serveur, sélectionnez Pools d’applications.
Cliquez avec le bouton de droite sur le pool d’applications du site et sélectionnez Paramètres de base dans le menu contextuel.
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.
ASP.NET Core 2.2 ou version ultérieure :
- 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.
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.

Déployer l’application

Déployez l’application dans le dossier Chemin d’accès physique IIS qui a été créé dans la section Créer le site IIS. Web Deploy est le mécanisme recommandé pour le déploiement. Toutefois, il existe plusieurs options pour déplacer l’application du dossier publish du projet vers le dossier de déploiement du système d’hébergement.

Web Deploy avec Visual Studio

Pour découvrir comment créer un profil de publication pour une utilisation avec Web Deploy, consultez la rubrique Profils de publication Visual Studio pour le déploiement d’applications ASP.NET Core. Si le fournisseur d’hébergement fournit un profil de publication ou prend en charge sa création, téléchargez son profil et importez-le à l’aide de la boîte de dialogue Publier de Visual Studio :

Boîte de dialogue Publier

Web Deploy en dehors de Visual Studio

Web Deploy peut également être utilisé en dehors de Visual Studio à partir de la ligne de commande. Pour plus d’informations, consultez Web Deployment Tool (Outil de déploiement Web).

Alternatives à Web Deploy

Utilisez la méthode de votre choix, telle que la copie manuelle, Xcopy, Robocopy ou PowerShell, pour déplacer l’application vers le système d’hébergement.

Pour plus d’informations sur le déploiement d’ASP.NET Core sur IIS, consultez la section Déploiement de ressources pour les administrateurs IIS.

Parcourir le site web

Une fois que l’application est déployée sur le système hôte, envoyez une requête à l’un des points de terminaison publics de l’application.

Dans l’exemple suivant, le site est limité à un nom d’hôte IIS de www.mysite.com sur le Port 80. Une demande est faite à http://www.mysite.com :

Le navigateur Microsoft Edge a chargé la page de démarrage IIS.

Fichiers de déploiement verrouillés

Les fichiers dans le dossier de déploiement sont verrouillés quand l’application est en cours d’exécution. Les fichiers verrouillés ne peuvent pas être remplacés au cours du déploiement. Pour libérer des fichiers verrouillés dans un déploiement, arrêtez le pool d’applications à l’aide d’une des approches suivantes :

Utilisez Web Deploy et référencez Microsoft.NET.Sdk.Web dans le fichier projet. Un fichier app_offline.htm est placé à la racine du répertoire de l’application web. Quand le fichier est présent, le module ASP.NET Core arrête l’application de manière appropriée, et met à disposition le fichier app_offline.htm durant le déploiement. Pour plus d’informations, consultez les Informations de référence sur la configuration du module ASP.NET Core.
Arrêtez manuellement le pool d’applications dans le Gestionnaire IIS sur le serveur.

Utilisez PowerShell pour supprimer app_offline.htm (nécessite PowerShell 5 ou une version ultérieure) :

$pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

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 Key Ring 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 la protection des données

Les clés de la 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 Key Ring de protection des données. Par défaut, les clés de protection des données 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 s’exécute l’application. Un certificat X509 peut être utilisé pour protéger les clés au rest. 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 persistantes 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.

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 (~/). 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.

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 :

É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).
Ajoutez le site racine dans IIS Manager en plaçant la sous-application dans un dossier du site racine.
Cliquez avec le bouton droit sur le dossier de la sous-application dans IIS Manager, puis sélectionnez Convertir en application.
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.

Configuration d’IIS avec web.config

La configuration d’IIS est influencée par la section <system.webServer> de web.config pour les scénarios IIS qui sont fonctionnels pour les applications ASP.NET Core avec le module ASP.NET Core. Par exemple, la configuration IIS est fonctionnelle pour la compression dynamique. Si IIS est configuré au niveau du serveur pour utiliser la compression dynamique, l’élément <urlCompression> dans le fichier web.config de l’application peut le désactiver pour une application ASP.NET Core.

Pour plus d’informations, voir les rubriques suivantes :

Pour définir les variables d’environnement d’applications individuelles s’exécutant dans des pools d’applications isolés (pris en charge pour IIS 10.0 ou version ultérieure), consultez la section Commande AppCmd.exe de la rubrique Variables d’environnement <environmentVariables> dans la documentation de référence d’IIS.

Sections non utilisées par ASP.NET Core

Les sections de configuration des applications ASP.NET dans web.config ne sont pas utilisées par les applications ASP.NET Core pour la configuration :

<system.web>
<appSettings>
<connectionStrings>
<location>

Les applications ASP.NET Core sont configurées à l’aide d’autres fournisseurs de configuration. Pour plus d’informations, consultez Configuration et Paramètres de configuration du runtime .NET Core

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 :

Boîte de dialogue Paramètres avancés du pool applications

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 :

Ouvrez l’Explorateur Windows et accédez au répertoire.
Cliquez avec le bouton droit sur le répertoire et sélectionnez Propriétés.
Sous l’onglet Sécurité, sélectionnez le bouton Modifier, puis le bouton Ajouter.
Sélectionnez le bouton Emplacements, puis vérifiez que le système est sélectionné.
Entrez 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.
Cliquez sur OK.
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. À partir de l’exemple de DefaultAppPool, la commande suivante est utilisée :

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

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é : vous pouvez configurer le modèle d’hébergement in-process de l’application pour qu’il n’expire pas 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 :

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

Sur Windows Server 2008 R2 ou version ultérieure :

Ouvrez l’Assistant Ajout de rôles et de fonctionnalités.
Dans le panneau Sélectionnez les services de rôle, ouvrez le nœud Développement d’applications.
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. Cliquez sur 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 Faux. Définissez Préchargement activé sur True. Cliquez sur OK.

À l’aide de web.config, ajoutez l’élément <applicationInitialization>, et affectez à doAppInitAfterRestart la valeur true pour les é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 :

Sélectionnez Pools d’applications dans le volet Connexions.
Cliquez avec le bouton de droite sur le pool d’applications de l’application dans la liste, puis sélectionnez Paramètres avancés.
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). Cliquez sur OK.
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é

Déploiement de ressources pour les administrateurs IIS

Ressources supplémentaires

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.

Installer le bundle d’hébergement .NET Core

Systèmes d’exploitation pris en charge

Les systèmes d’exploitation pris en charge sont les suivants :

Windows 7 ou version ultérieure
Windows Server 2008 R2 ou version ultérieure

Le serveur HTTP.sys (anciennement WebListener) ne fonctionne pas dans une configuration de proxy inverse avec IIS. Utilisez le serveur Kestrel.

Pour plus d’informations sur l’hébergement dans Azure, consultez Déployer des applications ASP.NET Core sur Azure App Service.

Pour obtenir des conseils d’aide sur la résolution des problèmes, consultez Résoudre les problèmes et effectuer le débogage des projets ASP.NET Core.

Plateformes prises en charge

Nécessite l’espace d’adressage de mémoire virtuelle le plus grand disponible pour une application 64 bits.
Nécessite la taille de pile IIS la plus grande disponible.
A des dépendances natives 64 bits.

Utilisez un kit SDK .NET Core 64 bits (x64) pour publier une application 64 bits. Un runtime 64 bits doit être présent sur le système hôte.

ASP.NET Core est fourni avec le serveur Kestrel, un serveur HTTP multiplateforme par défaut.

Quand vous utilisez IIS ou IIS Express, l’application s’exécute dans un processus distinct du processus de travail IIS (hors processus) avec le serveur Kestrel.

Étant donné que les applications ASP.NET Core s’exécutent dans un processus distinct du processus de travail IIS, le module s’occupe de la gestion du processus. Le module démarre le processus pour l’application ASP.NET Core quand la première requête arrive, et il redémarre l’application si elle s’arrête ou se bloque. Il s’agit essentiellement du même comportement que celui des applications s’exécutant in-process, et qui sont gérées par le service d’activation des processus Windows (WAS).

Le schéma suivant illustre la relation entre IIS, le module ASP.NET Core et une application hébergée hors processus :

Module ASP.NET Core

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.

CreateDefaultBuilder configure le serveur Kestrel en tant que serveur web et active l’intégration d’IIS en configurant le port et le chemin de base du module ASP.NET Core.

Le module ASP.NET Core génère un port dynamique à assigner au processus backend. CreateDefaultBuilder appelle la méthode UseIISIntegration. UseIISIntegration configure Kestrel pour être à l’écoute sur le port dynamique, à l’adresse IP localhost (127.0.0.1). Si le port dynamique est 1234, Kestrel écoute sur 127.0.0.1:1234. Cette configuration remplace les autres configurations URL fournies par :

UseUrls
API Listen de Kestrel
Configuration (ou options --url de ligne de commande)

Avec l’utilisation du module, les appels à l’API Listen de UseUrls ou Kestrel ne sont pas nécessaires. Si UseUrls ou Listen est appelé, Kestrel écoute sur le port spécifié uniquement quand l’application s’exécute sans IIS.

Pour obtenir des conseils d’aide sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core (ANCM) pour IIS.

Pour plus d’informations sur l’hébergement, consultez Héberger dans ASP.NET Core.

Configuration de l’application

Activer les composants IISIntegration

Durant la génération d’un hôte dans CreateWebHostBuilder (Program.cs), appelez CreateDefaultBuilder pour activer l’intégration d’IIS :

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

Pour plus d’informations sur CreateDefaultBuilder, consultez Hôte web ASP.NET Core.

Options IIS

Option	Default	Paramètre
`AutomaticAuthentication`	`true`	Si `true`, IIS Server définit le `HttpContext.User` authentifié par Authentification Windows. Si `false`, le serveur fournit uniquement une identity pour `HttpContext.User` et répond aux questions explicitement posées par `AuthenticationScheme`. L’authentification Windows doit être activée dans IIS pour que `AutomaticAuthentication` fonctionne. Pour plus d'informations, consultez Authentification Windows.
`AuthenticationDisplayName`	`null`	Définit le nom d’affichage montré aux utilisateurs sur les pages de connexion.

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Option	Default	Paramètre
`AutomaticAuthentication`	`true`	Si la valeur est `true`, le middleware d’intégration IIS définit l’élément `HttpContext.User` authentifié par Windows Authentication. Si `false`, le middleware fournit uniquement une identity pour `HttpContext.User` et répond aux questions explicitement posées par `AuthenticationScheme`. L’authentification Windows doit être activée dans IIS pour que `AutomaticAuthentication` fonctionne. Pour plus d'informations, consultez la rubrique Authentification Windows.
`AuthenticationDisplayName`	`null`	Définit le nom d’affichage montré aux utilisateurs sur les pages de connexion.
`ForwardClientCertificate`	`true`	Si la valeur est `true` et que l’en-tête de requête `MS-ASPNETCORE-CLIENTCERT` est présent, `HttpContext.Connection.ClientCertificate` est renseigné.

Scénarios avec un serveur proxy et un équilibreur de charge

Le middleware d’intégration IIS, qui configure le middleware des en-têtes transférés, et le module ASP.NET Core sont configurés pour transférer le schéma (HTTP/HTTPS) et l’adresse IP distante d’où provient la requête. Une configuration supplémentaire peut être nécessaire pour les applications hébergées derrière des serveurs proxy et des équilibreurs de charge supplémentaires. Pour plus d’informations, consultez l’article Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

fichier web.config

Le fichier web.config configure le Module ASP.NET Core. La création, la transformation et la publication du fichier web.config sont gérées par une cible MSBuild (_TransformWebConfig) quand le projet est publié. Cette cible est présente dans les cibles du SDK web (Microsoft.NET.Sdk.Web). Le SDK est défini en haut du fichier projet :

<Project Sdk="Microsoft.NET.Sdk.Web">

Si le projet ne contient pas de fichier web.config, le fichier est créé avec le processPath et les arguments corrects pour configurer le Module ASP.NET Core, puis il est déplacé vers la sortie publiée.

Si un fichier web.config se trouve dans le projet, il est transformé avec le processPath et les arguments corrects pour configurer le Module ASP.NET Core, puis il est déplacé vers la sortie publiée. La transformation ne modifie pas les paramètres de configuration IIS dans le fichier.

Le fichier web.config peut fournir des paramètres de configuration IIS supplémentaires qui contrôlent les modules IIS actifs. Pour plus d’informations sur les modules IIS capables de traiter les requêtes avec des applications ASP.NET Core, consultez la rubrique Modules IIS.

Pour empêcher le kit SDK web de transformer le fichier web.config, utilisez la propriété <IsTransformWebConfigDisabled> dans le fichier projet :

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Lorsque vous désactivez le Kit de développement logiciel (SDK) Web en transformant le fichier, le processPath et les arguments doivent être définis manuellement par le développeur. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

emplacement du fichier web.config

Pour que la configuration du module ASP.NET Core soit réussie, le fichier web.config doit être présent dans le chemin de la racine du contenu (généralement le chemin de base) de l’application déployée. Il s’agit du même emplacement que le chemin physique du site Web fourni à IIS. Le fichier web.config est nécessaire à la racine de l’application pour permettre la publication de plusieurs applications à l’aide de Web Deploy.

Il existe des fichiers sensibles dans le chemin physique de l’application, par exemple <assembly>.runtimeconfig.json, <assembly>.xml (commentaires de documentation XML) et <assembly>.deps.json. Lorsque le fichier web.config est présent et que le site démarre normalement, IIS ne traite pas ces fichiers sensibles s’ils sont demandés. Si le fichier web.config est absent, nommé de manière incorrecte ou s’il est incapable de configurer le site pour un démarrage normal, IIS peut traiter des fichiers sensibles publiquement.

Le fichier web.config doit être présent dans le déploiement en permanence, correctement nommé et capable de configurer le site pour un démarrage normal. Ne retirez jamais le fichier web.config d’un déploiement de production.

Transformer web.config

Si vous devez transformer web.config au moment de la publication (par exemple pour définir des variables d’environnement en fonction de la configuration, du profil ou de l’environnement), consultez Transformer web.config.

Configuration d’IIS

Systèmes d’exploitation Windows Server

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

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).
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.
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.

Naviguez jusqu’à Panneau de configuration>Programmes>Programmes et fonctionnalités>Activer ou désactiver des fonctionnalités Windows (à gauche de l’écran).
Ouvrez le nœud Internet Information Services. Ouvrez le nœud Outils de gestion Web.
Cochez la case Console de gestion IIS.
Cochez la case Services World Wide Web.
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.
Si l’installation d’IIS requiert un redémarrage, redémarrez le système.

Console de gestion IIS et Services World Wide Web sont sélectionnés dans Fonctionnalités de Windows.

Installer le bundle d’hébergement .NET Core

Important

Télécharger

Accédez à la page Télécharger .NET Core.
Sélectionnez la version souhaitée de .NET Core.
Dans la colonne Run apps - Runtime, recherchez la ligne de la version du runtime .NET Core souhaitée.
Téléchargez le programme d’installation à l’aide du lien Bundle de téléchargement.

Avertissement

Installer le bundle d’hébergement

Exécutez le programme d’installation sur le serveur. Les paramètres suivants sont disponibles lorsque vous exécutez le programme d’installation à partir d’un shell de commande administrateur :
- OPT_NO_ANCM=1 : Permet d’ignorer l’installation du module ASP.NET Core.
- OPT_NO_RUNTIME=1 : Permet d’ignorer l’installation du runtime .NET Core. Utilisé quand le serveur héberge uniquement des déploiements autonomes (SCD).
- OPT_NO_SHAREDFX=1 : Permet d’ignorer l’installation du framework partagé ASP.NET (runtime ASP.NET). Utilisé quand le serveur héberge uniquement des déploiements autonomes (SCD).
- OPT_NO_X86=1 : Permet d’ignorer l’installation des runtimes x86. Utilisez ce paramètre lorsque vous savez que vous n’hébergerez pas d’applications 32 bits. Si vous n’excluez pas d’avoir à héberger des applications 32 bits et 64 bits dans le futur, n'utilisez pas ce paramètre et installez les deux runtimes.
- OPT_NO_SHARED_CONFIG_CHECK=1 : Permet de désactiver la vérification de l’utilisation d’une configuration partagée d’IIS quand la configuration partagée (applicationHost.config) se trouve sur la même machine que l’installation d’IIS. Disponible uniquement pour les programmes d’installation du pack d’hébergement ASP.NET Core 2.2 ou version ultérieure. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.
Redémarrez le système, ou exécutez les commandes suivantes dans un interpréteur de commandes :
```
net stop was /y
net start w3svc
```
Le redémarrage d’IIS récupère une modification apportée au CHEMIN D’ACCÈS du système, qui est une variable d’environnement, par le programme d’installation.

Il n’est pas nécessaire d’arrêter manuellement les sites de manière individuelle dans IIS au moment de l’installation du bundle d’hébergement. Les applications hébergées (sites IIS) redémarrent quand IIS redémarre. Les applications redémarrent quand elles reçoivent leur première requête, notamment en provenance du module d’initialisation de l’application.

ASP.NET Core adopte le comportement de restauration par progression pour les versions de patch des packages de framework partagé. Quand les applications hébergées par IIS redémarrent avec IIS, elles se chargent avec les dernières versions de patch de leurs packages référencés au moment où elles reçoivent leur première requête. Si IIS n’a pas redémarré, les applications redémarrent et présentent un comportement de restauration par progression quand leurs processus de travail sont recyclés et qu’elles reçoivent leur première requête.

Remarque

Pour plus d’informations sur la configuration partagée IIS, consultez Module ASP.NET Core avec configuration partagée des services Internet (IIS).

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 l’Outil de déploiement Web, utilisez le Web Platform Installer (WebPI) ou Téléchargements IIS : Web Deploy. La méthode recommandée est d’utiliser WebPI. WebPI offre une installation autonome et une configuration pour les fournisseurs d’hébergement.

Créer le site IIS

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.
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.
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).
Sous le nœud du serveur, sélectionnez Pools d’applications.
Cliquez avec le bouton de droite sur le pool d’applications du site et sélectionnez Paramètres de base dans le menu contextuel.
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.
ASP.NET Core 2.2 ou version ultérieure : 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 la barre latérale Actions du Gestionnaire IIS >Pools d’applications, sélectionnez Définir les valeurs par défaut du pool d’applications ou Paramètres avancés. Recherchez Activer les applications 32 bits et définissez la valeur sur False. Ce paramètre n’affecte pas les applications déployées pour l’hébergement Out-of-process.
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.

Déployer l’application

Déployez l’application dans le dossier Chemin d’accès physique IIS qui a été créé dans la section Créer le site IIS. Web Deploy est le mécanisme recommandé pour le déploiement, mais il existe plusieurs options pour déplacer l’application à partir du dossier publier du projet vers le dossier de déploiement du système d’hébergement.

Web Deploy avec Visual Studio

Boîte de dialogue Publier

Web Deploy en dehors de Visual Studio

Web Deploy peut également être utilisé en dehors de Visual Studio à partir de la ligne de commande. Pour plus d’informations, consultez Web Deployment Tool (Outil de déploiement Web).

Alternatives à Web Deploy

Utilisez la méthode de votre choix, telle que la copie manuelle, Xcopy, Robocopy ou PowerShell, pour déplacer l’application vers le système d’hébergement.

Pour plus d’informations sur le déploiement d’ASP.NET Core sur IIS, consultez la section Déploiement de ressources pour les administrateurs IIS.

Parcourir le site web

Une fois que l’application est déployée sur le système hôte, envoyez une requête à l’un des points de terminaison publics de l’application.

Dans l’exemple suivant, le site est limité à un nom d’hôte IIS de www.mysite.com sur le Port 80. Une demande est faite à http://www.mysite.com :

Le navigateur Microsoft Edge a chargé la page de démarrage IIS.

Fichiers de déploiement verrouillés

Utilisez Web Deploy et référencez Microsoft.NET.Sdk.Web dans le fichier projet. Un fichier app_offline.htm est placé à la racine du répertoire de l’application web. Quand le fichier est présent, le module ASP.NET Core arrête l’application de manière appropriée, et met à disposition le fichier app_offline.htm durant le déploiement. Pour plus d’informations, consultez les Informations de référence sur la configuration du module ASP.NET Core.
Arrêtez manuellement le pool d’applications dans le Gestionnaire IIS sur le serveur.

Utilisez PowerShell pour supprimer app_offline.htm (nécessite PowerShell 5 ou une version ultérieure) :

$pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

Protection des données

Si le Key Ring 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 la protection des données

Les clés de la 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 Key Ring de protection des données. Par défaut, les clés de protection des données 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 s’exécute l’application. Un certificat X509 peut être utilisé pour protéger les clés au rest. 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 persistantes 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.

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.

Une sous-application ne doit pas inclure le module ASP.NET Core en tant que gestionnaire. Si le module est ajouté en guise de gestionnaire dans le fichier web.config d’une sous-application, une Erreur de serveur interne 500.19 faisant référence au fichier config défaillant est reçue lors de la tentative de navigation dans la sous-application.

L’exemple suivant présente un fichier web.config publié pour une sous-application ASP.NET Core :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Si vous hébergez une sous-application non-ASP.NET Core sous une application ASP.NET Core, supprimez explicitement le gestionnaire hérité dans le fichier web.config de la sous-application :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

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

É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).
Ajoutez le site racine dans IIS Manager en plaçant la sous-application dans un dossier du site racine.
Cliquez avec le bouton droit sur le dossier de la sous-application dans IIS Manager, puis sélectionnez Convertir en application.
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.

Configuration d’IIS avec web.config

Pour plus d’informations, voir les rubriques suivantes :

Sections non utilisées par ASP.NET Core

Les sections de configuration des applications ASP.NET 4.x dans web.config ne sont pas utilisées par les applications ASP.NET Core pour la configuration :

<system.web>
<appSettings>
<connectionStrings>
<location>

Les applications ASP.NET Core sont configurées à l’aide d’autres fournisseurs de configuration. Pour plus d’informations, consultez Configuration.

Pools d’applications

Quand vous hébergez plusieurs sites Web sur un même serveur, 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 cette configuration 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

Boîte de dialogue Paramètres avancés du pool applications

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 :

Ouvrez l’Explorateur Windows et accédez au répertoire.
Cliquez avec le bouton droit sur le répertoire et sélectionnez Propriétés.
Sous l’onglet Sécurité, sélectionnez le bouton Modifier, puis le bouton Ajouter.
Sélectionnez le bouton Emplacements, puis vérifiez que le système est sélectionné.
Entrez IIS AppPool\<nom_pool_applications> dans la zone Entrez les noms d’objets à sélectionner. Sélectionnez le bouton Vérifier les noms. Pour le DefaultAppPool, vérifiez les noms à l’aide de IIS AppPool\DefaultAppPool. Lorsque le bouton Vérifier les noms est sélectionné, une valeur de 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\<nom_pool_applications> quand vous vérifiez le nom de l’objet.
Cliquez sur OK.
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 en exemple, la commande suivante est utilisée :

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Pour plus d’informations, consultez la rubrique icacls.

Assistance HTTP/2

HTTP/2 est pris en charge pour les déploiements out-of-process qui répondent aux exigences de base suivantes :

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.
Version cible de .Net Framework : non applicable aux déploiements out-of-process, étant donné que la connexion HTTP/2 est gérée entièrement par IIS.
TLS 1.2 ou connexion ultérieure

Si une connexion HTTP/2 est établie, HttpRequest.Protocol retourne HTTP/1.1.

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.

Partage via

Héberger ASP.NET Core sur Windows avec IIS

Plateformes prises en charge

Installer le module/bundle d’hébergement ASP.NET Core

Bien démarrer

Configuration

Déploiement de ressources pour les administrateurs IIS

Chevauchement de recyclage

Certificats clients facultatifs

Ressources supplémentaires

Systèmes d’exploitation pris en charge

Plateformes prises en charge

Modèles d'hébergement

Modèle d’hébergement in-process

Modèle d’hébergement out-of-process

Configuration de l’application

Activer les composants IISIntegration

Options IIS

Scénarios avec un serveur proxy et un équilibreur de charge

Fichier web.config

Emplacement du fichier web.config

Transformer web.config

Configuration d’IIS

Installer le bundle d’hébergement .NET Core

Téléchargement direct (version actuelle)

Versions antérieures du programme d’installation

Installer le bundle d’hébergement

Installer Web Deploy lors de la publication avec Visual Studio

Créer le site IIS

Déployer l’application

Web Deploy avec Visual Studio

Web Deploy en dehors de Visual Studio

Alternatives à Web Deploy

Parcourir le site web

Fichiers de déploiement verrouillés

Protection des données

Répertoires virtuels

Sous-applications

Configuration d’IIS avec web.config

Sections non utilisées par ASP.NET Core

Pools d’applications

Pool d’applications Identity

Assistance HTTP/2

Requêtes préliminaires CORS

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

Module d’initialisation de l’application

Délai d’inactivité

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

Déploiement de ressources pour les administrateurs IIS

Ressources supplémentaires

Systèmes d’exploitation pris en charge

Plateformes prises en charge

Configuration de l’application

Activer les composants IISIntegration

Options IIS

Scénarios avec un serveur proxy et un équilibreur de charge

fichier web.config

emplacement du fichier web.config

Transformer web.config

Configuration d’IIS

Installer le bundle d’hébergement .NET Core

Télécharger

Installer le bundle d’hébergement

Installer Web Deploy lors de la publication avec Visual Studio

Créer le site IIS

Déployer l’application

Web Deploy avec Visual Studio

Web Deploy en dehors de Visual Studio

Alternatives à Web Deploy

Parcourir le site web

Fichiers de déploiement verrouillés

Protection des données

Répertoires virtuels

Sous-applications

Configuration d’IIS avec web.config

Sections non utilisées par ASP.NET Core

Pools d’applications

Pool d’applications Identity

Assistance HTTP/2

Requêtes préliminaires CORS

Fichier `web.config`

Emplacement du fichier `web.config`