Héberger ASP.NET Core sur Windows avec IIS

Internet Information Services (IIS) est un serveur Web flexible, sécurisé et facile à gérer pour héberger des applications Web, y compris des 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 bundle module/hébergement ASP.NET Core

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

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

Pour plus d’informations sur l’installation du module ASP.NET Core ou sur l’installation de différentes versions, consultez installer le bundle d’hébergement .net Core.

Bien démarrer

Pour découvrir comment héberger un site Web sur IIS, consultez notre Guide de priseen main.

Pour découvrir comment héberger un site Web sur Azure App services, consultez notre Guide de déploiement sur Azure App service.

Déploiement de ressources pour les administrateurs IIS

Recyclage avec chevauchement

En général, nous vous recommandons d’utiliser un modèle comme les déploiements bleus-verts pour les déploiements sans temps d’arrêt. Des fonctionnalités telles que l’aide au recyclage avec chevauchement, mais ne garantissent pas que vous pouvez effectuer un déploiement sans temps mort. Pour plus d’informations, consultez ce problème GitHub.

Ressources supplémentaires

Pour une expérience de tutoriel sur la publication d'une app ASP.NET Core sur un serveur IIS, voir 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 Kestrel serveur.

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 de dépannage, consultez Résoudre les problèmes et déboguer des projets ASP.NET Core.

Plateformes prises en charge

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.

Les applications publiées pour 32 bits (x86) doivent avoir 32 bits activés 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).

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

  1. Une requête arrive du web au pilote HTTP.sys en mode noyau.
  2. Le pilote achemine la requête native vers IIS sur le port configuré du site web, généralement 80 (HTTP) ou 443 (HTTPS).
  3. Le module ASP.NET Core reçoit la demande native et la transmet 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 que le serveur HTTP IIS a traité la requête :

  1. La demande est envoyée au pipeline de l’intergiciel (middleware) ASP.NET Core.
  2. Le pipeline de middlewares traite la requête et la passe en tant qu’instance de HttpContext à la logique de l’application.
  3. La réponse de l’application est retransmise à IIS via le serveur HTTP IIS.
  4. IIS envoie la réponse au client qui a initié la demande.

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

CreateDefaultBuilder Ajoute une IServer instance en appelant la UseIIS méthode pour démarrer CoreCLR et héberger l’application à l’intérieur du processus de travail IIS ( w3wp.exe ou iisexpress.exe ). Les tests de performances indiquent que l’hébergement d’une application .NET Core en cours de traitement offre des débits de demandes nettement plus élevés que l’hébergement des demandes out-of-process et de proxy de l’application à 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

Étant donné que ASP.NET Core applications s’exécutent dans un processus distinct du processus de travail IIS, le module ASP.NET Core gère 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

  1. Les requêtes arrivent du web au pilote HTTP.sys en mode noyau.
  2. Le pilote achemine les requêtes vers IIS sur le port configuré du site Web. Le port configuré est généralement 80 (HTTP) ou 443 (HTTPs).
  3. Le module transfère les demandes à 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' UseIISIntegration extension configure le serveur pour l’écoute 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 demandes sont transférées via HTTP, même si elles sont reçues par IIS sur HTTPs.

Une fois Kestrel la demande extraite du module, la demande est transmise dans le pipeline de l’intergiciel (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. L’intergiciel (middleware) ajouté par l’intégration IIS met à jour le schéma, l’adresse IP distante et pathbase pour tenir compte du transfert de la demande à Kestrel . La réponse de l’application est retransmise à IIS, qui la retransmet au client HTTP qui a initié la demande.

Pour obtenir de l’aide sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core.

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

Configuration de l’application

Activer les composants IISIntegration

Lors de 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 le 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 identité 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 des 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 le web.config pour définir maxAllowedContentLength sur une valeur supérieure. 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, l’intergiciel (middleware) fournit uniquement une identité 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

L' intergiciel (middleware) d’intégration IIS et le module ASP.net Core sont configurés pour transférer les éléments suivants :

  • Schéma (HTTP/HTTPs).
  • Adresse IP distante à l’origine de la demande.

L' intergiciel (middleware) d’intégration IIS configure l’intergiciel (middleware) des en-têtes transféré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 web.config fichier configure le module ASP.net Core. La création, la transformation et la publication du web.config fichier sont gérées par une cible MSBuild ( _TransformWebConfig ) lors 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 un web.config fichier n’est pas présent dans le projet, le fichier est créé avec les et corrects processPath arguments pour configurer le module ASP.net Core, puis déplacé vers la sortie publiée.

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

Le web.config fichier 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 de développement logiciel (SDK) Web de transformer le web.config fichier, utilisez la <IsTransformWebConfigDisabled> propriété dans le fichier projet :

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

Lorsque vous désactivez le kit de développement logiciel (SDK) Web pour transformer le fichier, processPath et arguments doit être défini manuellement par le développeur. Pour plus d’informations, consultez Module ASP.NET Core.

web.config emplacement du fichier

Pour configurer correctement le Module ASP.net Core , le web.config fichier doit être présent au chemin d’accès racine du contenu (en général, le chemin d’accès de base de l’application) de l’application déployée. Il s’agit du même emplacement que le chemin physique du site Web fourni à IIS. Le web.config fichier est requis à la racine de l’application pour permettre la publication de plusieurs applications à l’aide de Web Deploy.

Des fichiers sensibles existent sur le chemin d’accès 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} est le nom de l’assembly. Lorsque le web.config fichier est présent et que le site démarre normalement, IIS ne traite pas ces fichiers sensibles s’ils sont demandés. Si le web.config fichier est manquant, nommé de façon incorrecte ou ne peut pas configurer le site pour un démarrage normal, IIS peut traiter les fichiers sensibles publiquement.

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

Transformer web.config

Si vous devez effectuer une transformation web.config lors de la publication, consultez Transformer web.config . Vous devrez peut-être effectuer une transformation web.config sur la publication pour définir des variables d’environnement en fonction de la configuration, du profil ou de l’environnement.

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

    Le rôle Serveur Web IIS est sélectionné à l’étape Sélectionner des rôles de serveurs.

  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.

    Les services de rôle par défaut sont sélectionnés à l’étape Sélectionner des services de rôle.

    Authentification Windows (facultatif)
    Pour activer l’authentification Windows, développez les nœuds suivants : sécurité du serveur Web > . Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows 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 : développement d’applications de serveur Web > . 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 : World Wide webing services > Security. Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows et configurer l’authentification Windows.

    WebSockets (facultatif)
    WebSockets est pris en charge avec ASP.NET Core 1.1 ou version ultérieure. Pour activer WebSockets, développez les nœuds suivants : fonctionnalités de développement d’applications World Wide Web services > . 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.

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. L’offre groupée 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 déboguer 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 :

  1. Accédez à la page Télécharger .net Core .
  2. Sélectionnez la version .NET Core de votre choix.
  3. Dans la colonne Run apps - Runtime, recherchez la ligne de la version du runtime .NET Core souhaitée.
  4. Téléchargez le programme d’installation à l’aide du lien d' hébergement .

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

  1. 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: Ignorez l’installation du module ASP.NET Core.
    • OPT_NO_RUNTIME=1: Ignorez l’installation du Runtime .NET Core. Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_SHAREDFX=1: Ignorez l’installation du Framework partagé ASP.NET (runtime ASP.NET). Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_X86=1: Ignorez 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: Désactive la vérification de l’utilisation d’une configuration partagée IIS lorsque la configuration partagée ( applicationHost.config ) se trouve sur le même ordinateur 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.
  2. 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 mises à jour correctives des packages d’infrastructure partagés. Après la mise à niveau de l’infrastructure partagée 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

Notes

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 Web Deploy, utilisez Web Platform Installer (WebPI) ou obtenez un programme d’installation directement à partir du Centre de téléchargement Microsoft. 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

  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 la disposition d’un fichier d’une application, consultez Structure de répertoires ASP.NET Core.

  2. Dans le gestionnaire des services Internet, 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. Fournissez la configuration de liaison et créez le site Web en sélectionnant OK:

    Spécifiez le nom du site, le chemin physique et le nom d’hôte à l’étape Ajouter un site Web.

    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). Consultez la rfc7230 section-5.4 pour plus d’informations.

  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é :

    Définissez Aucun code managé pour la version CLR .NET.

    ASP.NET Core s’exécute dans un processus séparé et gère l’exécution. ASP.NET Core ne s’appuie pas sur le chargement du CLR de bureau (.NET CLR). Le Common Language Runtime (CoreCLR) principal pour .NET Core est amorcé 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.

  7. ASP.NET Core 2.2 ou version ultérieure :

    • Pour un Déploiement autonome 32 bits (x86) publié avec un kit de développement logiciel (SDK) 32 bits qui utilise le modèle d’hébergement in-process, activez le Pool d’applications pour 32 bits. Dans le gestionnaire des services Internet, accédez à pools d’applications dans la barre latérale connexions . Sélectionnez le pool d’applications de l’application. Dans l’encadré actions , sélectionnez Paramètres avancés. Définissez activer les Applications 32 bits sur 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 des services Internet, accédez à pools d’applications dans la barre latérale connexions . Sélectionnez le pool d’applications de l’application. Dans l’encadré actions , sélectionnez Paramètres avancés. Définissez activer les Applications 32 bits sur False .

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

    Si l’identité par défaut du pool d’applications (modèle de processus > Identity ) est Identity remplacée par une autre identité, vérifiez que la nouvelle identité dispose des autorisations nécessaires pour accéder au dossier de l’application, à la base de données et à d’autres ressources requises. 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 plusieurs options existent pour déplacer l’application du dossier du projet publish vers le dossier de déploiement du système hôte.

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 lié à 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 app_offline.htm fichier est placé à la racine du répertoire de l’application Web. Quand le fichier est présent, le module ASP.NET Core arrête correctement l’application et sert le app_offline.htm fichier pendant 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.

  • Utiliser PowerShell pour supprimer app_offline.htm (nécessite PowerShell 5 ou 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 cookie jetons d’authentification de base 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. Cela peut inclure des jetons CSRF et des ASP.NET Core les de la MVC cookie .

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 repos à 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 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 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 :

  • 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 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 :

  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 sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core .

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 des variables d’environnement pour des 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 commandeAppCmd.exe de la rubrique variables <environmentVariables> d’environnement dans la documentation de référence IIS.

Sections de configuration de web.config

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

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

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

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 être exécutées 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’identité 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 pour le pool d’applications, assurez-vous que le Identity est configuré pour utiliser ApplicationPool Identity:

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 identité. Toutefois, cette identité 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 IIS AppPool\{APP POOL NAME} , où l’espace réservé {APP POOL NAME} est le nom du pool d’applications, dans la zone Entrez les noms des objets à sélectionner . Sélectionnez le bouton Vérifier les noms. Pour l’option DefaultAppPool , vérifiez les noms à l’aide de IIS AppPool\DefaultAppPool . Lorsque le bouton vérifier les noms est sélectionné, la valeur DefaultAppPool est indiquée dans la zone 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 IIS AppPool\{APP POOL NAME} format, où l’espace réservé {APP POOL NAME} est le nom du pool d’applications, lors de la vérification du nom de l’objet.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : ajoutez le nom du pool d’applications « DefaultAppPool » à « IIS AppPool" dans la zone des noms d’objets avant de sélectionner « Vérifier les noms ».

  6. Sélectionnez OK.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : après avoir sélectionné « Vérifier les noms », le nom d’objet « DefaultAppPool » est indiqué dans la zone des noms d’objets.

  7. Les autorisations Lire & 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 :

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 le protocole HTTP/2, mais la connexion du proxy inverse au Kestrel serveur utilise http/1.1.
    • TLS 1.2 ou connexion ultérieure

Pour un déploiement in-process lors de l’établissement d’une connexion HTTP/2, HttpRequest.Protocol signale HTTP/2 . Pour un déploiement hors processus lors de l’établissement d’une connexion HTTP/2, HttpRequest.Protocol signale HTTP/1.1 .

Pour plus d’informations sur les modèles d’hébergement in-process et out-of-process, consultez Module ASP.NET Core.

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 pour passer des demandes d’options, consultez activer les demandes Cross-origin dans 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

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. Activez la case à cocher pour l’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. Activez la case à cocher pour l’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 Faux. Définissez Préchargement activé sur True. Sélectionnez OK.
  • À l’aide de web.config , ajoutez l' <applicationInitialization> élément avec doAppInitAfterRestart true la valeur aux <system.webServer> éléments 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 :

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 une expérience de tutoriel sur la publication d'une app ASP.NET Core sur un serveur IIS, voir 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 Kestrel serveur.

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 de dépannage, consultez Résoudre les problèmes et déboguer des projets ASP.NET Core.

Plateformes prises en charge

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.

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 des performances améliorées par rapport à l’hébergement out-of-process, car :

  • Les requêtes ne sont pas transmises par proxy sur la carte de bouclage. Une carte de bouclage est une interface réseau qui renvoie le trafic réseau sortant vers le même ordinateur.

IIS s’occupe de la gestion des processus par l’intermédiaire du service d’activation des processus Windows (WAS).

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 modèle d’hébergement in-process n’est pas pris en charge pour les applications ASP.NET Core qui ciblent le .NET Framework.

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 demande native et la transmet 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 que IIS HTTP Server a traité la requête, celle-ci est envoyée (push) dans le pipeline de middleware (intergiciel) d’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 au choix pour les applications existantes, mais les modèles dotnet new sont définis par défaut sur le modèle d’hébergement in-process pour tous les scénarios IIS et IIS Express.

CreateDefaultBuilder appelle une instance IServer en appelant la méthode UseIIS pour démarrer CoreCLR et héberger l’application dans le processus Worker IIS (w3wp.exe ou iisexpress.exe). Les tests de performances indiquent que l’hébergement d’une application .NET Core en cours de traitement offre des débits de demandes nettement plus élevés que l’hébergement des demandes d’applications hors processus et de proxy vers le Kestrel serveur.

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

Étant donné que ASP.NET Core applications s’exécutent dans un processus distinct du processus de travail IIS, le module ASP.NET Core gère 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, généralement 80 (HTTP) ou 443 (HTTPS). Le module transfère les demandes à Kestrel sur un port aléatoire pour l’application, qui n’est pas le port 80 ou 443.

Le module spécifie le port via une variable d’environnement au démarrage, et 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 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 demande du module, la demande est envoyée dans le pipeline de l’intergiciel (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. L’intergiciel (middleware) ajouté par l’intégration IIS met à jour le schéma, l’adresse IP distante et pathbase pour tenir compte du transfert de la demande à Kestrel . La réponse de l’application est ensuite repassée à IIS, qui la renvoie au client HTTP à l’origine de la requête.

Pour obtenir de l’aide sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core.

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

Configuration de l’application

Activer les composants IISIntegration

Lors de 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 le CreateDefaultBuilder, consultez Hôte web 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 identité 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.

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, l’intergiciel (middleware) fournit uniquement une identité 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 de développement logiciel (SDK) Web de transformer le fichier web.config , utilisez la <IsTransformWebConfigDisabled> propriété 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.

emplacement du fichier web.config

Pour configurer correctement le Module ASP.net Core , le fichier web.config doit être présent au chemin d’accès racine du contenu (en général, le chemin d’accès de base de l’application) 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.

Des fichiers sensibles existent sur le chemin d’accès physique de l’application, par exemple <assembly>.runtimeconfig.jssur, <assembly> . xml (commentaires de documentation XML) et <assembly>.deps.jssur. 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 à tout moment, correctement nommé et capable de configurer le site pour un démarrage normal. Ne supprimez jamais le fichier web.config d’un déploiement de production.

Transformer web.config

Si vous devez transformer web.config lors de la publication (par exemple, définir les variables d’environnement basées sur la configuration, le profil ou l’environnement), consultez Transformer web.config.

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

    Le rôle Serveur Web IIS est sélectionné à l’étape Sélectionner des rôles de serveurs.

  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.

    Les services de rôle par défaut sont sélectionnés à l’étape Sélectionner des services de rôle.

    Authentification Windows (facultatif)
    Pour activer l’authentification Windows, développez les nœuds suivants : sécurité du serveur Web > . Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows 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 : développement d’applications de serveur Web > . 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 : World Wide webing services > Security. Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows et configurer l’authentification Windows.

    WebSockets (facultatif)
    WebSockets est pris en charge avec ASP.NET Core 1.1 ou version ultérieure. Pour activer WebSockets, développez les nœuds suivants : fonctionnalités de développement d’applications World Wide Web services > . 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.

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. L’offre groupée 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 déboguer des projets ASP.NET Core.

Télécharger

  1. Accédez à la page Télécharger .net Core .
  2. Sélectionnez la version .NET Core de votre choix.
  3. Dans la colonne Run apps - Runtime, recherchez la ligne de la version du runtime .NET Core souhaitée.
  4. Téléchargez le programme d’installation à l’aide du lien d' hébergement .

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

  1. 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: Ignorez l’installation du module ASP.NET Core.
    • OPT_NO_RUNTIME=1: Ignorez l’installation du Runtime .NET Core. Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_SHAREDFX=1: Ignorez l’installation du Framework partagé ASP.NET (runtime ASP.NET). Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_X86=1: Ignorez 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: Désactive la vérification de l’utilisation d’une configuration partagée IIS lorsque la configuration partagée (applicationHost.config) se trouve sur le même ordinateur 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.
  2. Redémarrez le système ou exécutez les commandes suivantes dans une interface de commande :

    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 des sites individuels dans IIS lors de l’installation du bundle d’hébergement. Les applications hébergées (sites IIS) redémarrent lors du redémarrage d’IIS. Les applications redémarrent lorsqu’elles reçoivent leur première requête, y compris à partir du module d’initialisationde l’application.

ASP.NET Core adopte le comportement de restauration par progression pour les mises à jour correctives des packages d’infrastructure partagés. Lorsque les applications hébergées par IIS redémarrent avec IIS, elles sont chargées avec les dernières versions de correctif de leurs packages référencés lorsqu’elles reçoivent leur première demande. Si IIS n’est pas redémarré, les applications redémarrent et présentent le comportement de restauration par progression lorsque leurs processus de travail sont recyclés et qu’ils reçoivent leur première demande.

Notes

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 Web Deploy, utilisez Web Platform Installer (WebPI) ou obtenez un programme d’installation directement à partir du Centre de téléchargement Microsoft. 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

  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 la disposition d’un fichier d’une application, consultez Structure de répertoires ASP.NET Core.

  2. Dans le gestionnaire des services Internet, 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. Fournissez la configuration de liaison et créez le site Web en sélectionnant OK:

    Spécifiez le nom du site, le chemin physique et le nom d’hôte à l’étape Ajouter un site Web.

    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). Consultez la rfc7230 section-5.4 pour plus d’informations.

  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é :

    Définissez Aucun code managé pour la version CLR .NET.

    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 de Desktop CLR (CLR .NET)—la prise en charge du Common Language Runtime Core (CoreCLR) pour .NET Core est démarrée pour héberger l’application dans le processus Worker. La configuration de la version CLR .NET sur Aucun code managé est facultative, mais recommandée.

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

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

    Si l’identité par défaut du pool d’applications (modèle de processus > Identity ) est Identity remplacée par une autre identité, vérifiez que la nouvelle identité dispose des autorisations nécessaires pour accéder au dossier de l’application, à la base de données et à d’autres ressources requises. 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

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 lié à 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 ferme l’application normalement et sert le fichier app_offline.htm pendant 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 des app_offline.htm (nécessite PowerShell 5 ou 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 cookie jetons d’authentification de base 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. Cela peut inclure des jetons CSRF et des ASP.NET Core les de la MVC cookie .

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 repos à 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 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 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 :

  • 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 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 :

  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 sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core .

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 des variables d’environnement pour des 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 commandeAppCmd.exe de la rubrique variables <environmentVariables> d’environnement dans la documentation de référence IIS.

Sections de configuration de web.config

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

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

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

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 être exécutées 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’identité 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 pour le pool d’applications, assurez-vous que le Identity est configuré pour utiliser ApplicationPool Identity:

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 identité. Toutefois, cette identité 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 IIS AppPool\<app_pool_name> dans la zone Entrer les noms des 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\<app_pool_name> lors de la vérification du nom de l’objet.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : ajoutez le nom du pool d’applications « DefaultAppPool » à « IIS AppPool" dans la zone des noms d’objets avant de sélectionner « Vérifier les noms ».

  6. Sélectionnez OK.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : après avoir sélectionné « Vérifier les noms », le nom d’objet « DefaultAppPool » est indiqué dans la zone des noms d’objets.

  7. Les autorisations Lire & 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 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 le protocole HTTP/2, mais la connexion du proxy inverse au Kestrel serveur utilise http/1.1.
    • TLS 1.2 ou connexion ultérieure

Pour un déploiement in-process lorsqu’une connexion HTTP/2 est établie, HttpRequest.Protocol retourne HTTP/2. Pour un déploiement in-process lorsqu’une connexion HTTP/2 est établie, HttpRequest.Protocol retourne HTTP/1.1.

Pour plus d’informations sur les modèles d’hébergement in-process et out-of-process, consultez Module ASP.NET Core.

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 pour passer des demandes d’options, consultez activer les demandes Cross-Origin dans 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

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. Activez la case à cocher pour l’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. Activez la case à cocher pour l’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 Faux. 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 :

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 une expérience de tutoriel sur la publication d'une app ASP.NET Core sur un serveur IIS, voir 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 Kestrel serveur.

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 de dépannage, consultez Résoudre les problèmes et déboguer des projets ASP.NET Core.

Plateformes prises en charge

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.

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 Kestrel Server, un serveur http multiplateforme par défaut.

Lors de l’utilisation d' IIS ou de IIS Express, l’application s’exécute dans un processus distinct du processus de travail IIS (hors processus) avec le Kestrel serveur.

É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 transfère les demandes à Kestrel sur un port aléatoire pour l’application, qui n’est pas le port 80 ou 443.

Le module spécifie le port via une variable d’environnement au démarrage, et l' intergiciel (middleware) d’intégration IIS configure le serveur pour l’écoute 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 demande du module, la demande est envoyée dans le pipeline de l’intergiciel (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. L’intergiciel (middleware) ajouté par l’intégration IIS met à jour le schéma, l’adresse IP distante et pathbase pour tenir compte du transfert de la demande à 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 Kestrel serveur en tant que serveur Web et active l’intégration d’IIS en configurant le chemin d’accès de base et le port pour le 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 écouter sur le port dynamique à l’adresse IP localhost ( 127.0.0.1 ). Si le port dynamique est 1234, Kestrel écoute à 127.0.0.1:1234 . Cette configuration remplace les autres configurations URL fournies par :

Les appels à l' UseUrls Kestrel API ou Listen ne sont pas requis lors de l’utilisation du module. Si UseUrls ou Listen est appelé, Kestrel écoute sur le port spécifié uniquement lors de l’exécution de l’application sans IIS.

Pour obtenir de l’aide sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core.

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

Configuration de l’application

Activer les composants IISIntegration

Lors de 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 le 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 identité 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.

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, l’intergiciel (middleware) fournit uniquement une identité 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 de développement logiciel (SDK) Web de transformer le fichier web.config , utilisez la <IsTransformWebConfigDisabled> propriété 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.

emplacement du fichier web.config

Pour configurer correctement le Module ASP.net Core , le fichier web.config doit être présent au chemin d’accès racine du contenu (en général, le chemin d’accès de base de l’application) 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.

Des fichiers sensibles existent sur le chemin d’accès physique de l’application, par exemple <assembly>.runtimeconfig.jssur, <assembly> . xml (commentaires de documentation XML) et <assembly>.deps.jssur. 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 à tout moment, correctement nommé et capable de configurer le site pour un démarrage normal. Ne supprimez jamais le fichier web.config d’un déploiement de production.

Transformer web.config

Si vous devez transformer web.config lors de la publication (par exemple, définir les variables d’environnement basées sur la configuration, le profil ou l’environnement), consultez Transformer web.config.

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

    Le rôle Serveur Web IIS est sélectionné à l’étape Sélectionner des rôles de serveurs.

  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.

    Les services de rôle par défaut sont sélectionnés à l’étape Sélectionner des services de rôle.

    Authentification Windows (facultatif)
    Pour activer l’authentification Windows, développez les nœuds suivants : sécurité du serveur Web > . Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows 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 : développement d’applications de serveur Web > . 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 : World Wide webing services > Security. Sélectionnez la fonctionnalité Authentification Windows. Pour plus d’informations, consultez authentification <windowsAuthentication> Windows et configurer l’authentification Windows.

    WebSockets (facultatif)
    WebSockets est pris en charge avec ASP.NET Core 1.1 ou version ultérieure. Pour activer WebSockets, développez les nœuds suivants : fonctionnalités de développement d’applications World Wide Web services > . 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.

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. L’offre groupée 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 déboguer des projets ASP.NET Core.

Télécharger

  1. Accédez à la page Télécharger .net Core .
  2. Sélectionnez la version .NET Core de votre choix.
  3. Dans la colonne Run apps - Runtime, recherchez la ligne de la version du runtime .NET Core souhaitée.
  4. Téléchargez le programme d’installation à l’aide du lien d' hébergement .

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

  1. 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: Ignorez l’installation du module ASP.NET Core.
    • OPT_NO_RUNTIME=1: Ignorez l’installation du Runtime .NET Core. Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_SHAREDFX=1: Ignorez l’installation du Framework partagé ASP.NET (runtime ASP.NET). Utilisé lorsque le serveur héberge uniquement des déploiements autonomes (SCD).
    • OPT_NO_X86=1: Ignorez 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: Désactive la vérification de l’utilisation d’une configuration partagée IIS lorsque la configuration partagée (applicationHost.config) se trouve sur le même ordinateur 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.
  2. Redémarrez le système ou exécutez les commandes suivantes dans une interface de commande :

    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 des sites individuels dans IIS lors de l’installation du bundle d’hébergement. Les applications hébergées (sites IIS) redémarrent lors du redémarrage d’IIS. Les applications redémarrent lorsqu’elles reçoivent leur première requête, y compris à partir du module d’initialisationde l’application.

ASP.NET Core adopte le comportement de restauration par progression pour les mises à jour correctives des packages d’infrastructure partagés. Lorsque les applications hébergées par IIS redémarrent avec IIS, elles sont chargées avec les dernières versions de correctif de leurs packages référencés lorsqu’elles reçoivent leur première demande. Si IIS n’est pas redémarré, les applications redémarrent et présentent le comportement de restauration par progression lorsque leurs processus de travail sont recyclés et qu’ils reçoivent leur première demande.

Notes

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 Web Deploy, utilisez Web Platform Installer (WebPI) ou obtenez un programme d’installation directement à partir du Centre de téléchargement Microsoft. 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

  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 la disposition d’un fichier d’une application, consultez Structure de répertoires ASP.NET Core.

  2. Dans le gestionnaire des services Internet, 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. Fournissez la configuration de liaison et créez le site Web en sélectionnant OK:

    Spécifiez le nom du site, le chemin physique et le nom d’hôte à l’étape Ajouter un site Web.

    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). Consultez la rfc7230 section-5.4 pour plus d’informations.

  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é :

    Définissez Aucun code managé pour la version CLR .NET.

    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 de Desktop CLR (CLR .NET)—la prise en charge du Common Language Runtime Core (CoreCLR) pour .NET Core est démarrée pour héberger l’application dans le processus Worker. La configuration de la version CLR .NET sur Aucun code managé est facultative, mais recommandée.

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

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

    Si l’identité par défaut du pool d’applications (modèle de processus > Identity ) est Identity remplacée par une autre identité, vérifiez que la nouvelle identité dispose des autorisations nécessaires pour accéder au dossier de l’application, à la base de données et à d’autres ressources requises. 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

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 lié à 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 ferme l’application normalement et sert le fichier app_offline.htm pendant 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 des app_offline.htm (nécessite PowerShell 5 ou 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 cookie jetons d’authentification de base 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. Cela peut inclure des jetons CSRF et des ASP.NET Core les de la MVC cookie .

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 repos à 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 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 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 :

  • 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 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>

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 :

  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 sur la configuration du module ASP.NET Core, consultez Module ASP.NET Core .

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 des variables d’environnement pour des 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 commandeAppCmd.exe de la rubrique variables <environmentVariables> d’environnement dans la documentation de référence IIS.

Sections de configuration de web.config

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

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

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

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

Un compte d’identité 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 pour le pool d’applications, assurez-vous que le Identity est configuré pour utiliser ApplicationPool Identity:

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 identité. Toutefois, cette identité 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 IIS AppPool\<app_pool_name> dans la zone Entrer les noms des 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\<app_pool_name> lors de la vérification du nom de l’objet.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : ajoutez le nom du pool d’applications « DefaultAppPool » à « IIS AppPool" dans la zone des noms d’objets avant de sélectionner « Vérifier les noms ».

  6. Sélectionnez OK.

    Sélectionnez la boîte de dialogue utilisateurs ou groupes pour le dossier d’applications : après avoir sélectionné « Vérifier les noms », le nom d’objet « DefaultAppPool » est indiqué dans la zone des noms d’objets.

  7. Les autorisations Lire & 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 le protocole HTTP/2, mais la connexion du proxy inverse au Kestrel serveur 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.

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 pour passer des demandes d’options, consultez activer les demandes Cross-Origin dans API Web ASP.NET 2 : fonctionnement de cors.

Déploiement de ressources pour les administrateurs IIS

Ressources supplémentaires