En clair
IIS est le serveur web de Windows. Il reçoit les requêtes, les distribue aux applications, et redémarre une appli qui plante. Chaque appli tourne dans un « pool d'applications », un processus isolé, pour qu'un crash n'emporte pas les applis voisines.
Le trajet d'une requête Confirmé
w3wp.exe à la première requête, où l'ASP.NET Core Module charge votre appli.| Composant | Rôle |
|---|---|
| HTTP.sys | Pilote noyau : écoute les ports, termine TLS, met en file par pool, sert le cache noyau |
| WAS | Windows Process Activation Service : crée, surveille et recycle les processus de travail |
| W3SVC | Service web : lit la configuration et programme HTTP.sys |
| Pool d'applications | Frontière d'isolation : un ou plusieurs w3wp.exe, une identité, des règles de recyclage |
| ANCM | Module natif IIS fourni par le .NET Hosting Bundle, charge l'appli ASP.NET Core |
applicationHost.config | Configuration du serveur (%windir%\System32\inetsrv\config) ; web.config au niveau de l'appli |
Réglages du pool d'applications Senior
| Paramètre | Défaut | Recommandation |
|---|---|---|
| Version du CLR .NET | v4.0 | No Managed Code pour ASP.NET Core ; v4.0 pour .NET Framework |
| Identité | ApplicationPoolIdentity | La garder ; donner les droits NTFS à IIS AppPool\NomDuPool ; compte de service géré (gMSA) pour accéder à SQL Server en auth Windows |
| Recyclage périodique | 1 740 min (29 h) | Le remplacer par une heure fixe hors trafic, ou le désactiver si l'appli est saine |
| Délai d'inactivité | 20 min | 0 pour une API qui doit répondre vite après une période calme |
| Mode de démarrage | OnDemand | AlwaysRunning + preloadEnabled sur le site (module Application Initialization) |
| Protection contre les échecs rapides | 5 échecs en 5 min | La garder : le pool s'arrête au lieu de boucler |
| Nombre max. de processus (web garden) | 1 | 1, sauf appli sans état en mémoire |
web.config généré par dotnet publish (in-process)
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Shop.Api.dll"
hostingModel="inprocess" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>
</aspNetCore>
</system.webServer>
</location>
</configuration>Déployer sans casser
- Déposer un fichier
app_offline.htmà la racine : ANCM arrête l'appli et sert ce fichier (libère les DLL verrouillées). - Copier la nouvelle publication (Web Deploy,
robocopy, pipeline CI). - Supprimer
app_offline.htm: l'appli redémarre à la requête suivante. - Pour zéro interruption : deux sites derrière ARR / un load balancer, bascule bleu-vert.
Diagnostiquer les erreurs ANCM
| Erreur | Cause fréquente | Où regarder |
|---|---|---|
| 500.19 | Module ANCM absent : Hosting Bundle non installé (ou installé avant IIS) | Réinstaller le Hosting Bundle, iisreset |
| 500.30 | L'appli in-process plante au démarrage (config, secret manquant, exception dans Program.cs) | Observateur d'événements → Application ; activer stdoutLogEnabled temporairement |
| 500.31 | Runtime .NET requis introuvable | Version du Hosting Bundle vs TargetFramework |
| 500.35 | Deux applis in-process dans le même pool | Un pool par appli |
| 502.5 | Out-of-process : le processus dotnet ne démarre pas | Journaux stdout, chemin processPath |
| 503 | Pool arrêté (protection contre les échecs rapides) | Gestionnaire IIS → pools, puis cause racine |
ASP.NET classique (.NET Framework)
Une appli ASP.NET MVC 5 / Web Forms tourne dans le pipeline intégré d'IIS : System.Web, HttpModule, HttpHandler, Global.asax, pool en CLR v4.0. L'état de session in-proc et le cache HttpRuntime disparaissent à chaque recyclage : pour une ferme ou un recyclage sans douleur, session en SQL Server ou State Server, et machineKey identique sur tous les serveurs. Migration vers ASP.NET Core : progressive avec YARP et l'approche « strangler fig » (le nouveau site relaie vers l'ancien les routes non migrées).
Piège
- Hosting Bundle installé avant IIS : ANCM n'est pas enregistré. Réparer le Hosting Bundle après l'ajout du rôle IIS.
- Clés Data Protection : sans profil utilisateur chargé (
Load User Profile= false), les clés ne sont pas persistées et les cookies d'auth deviennent invalides après chaque recyclage. Persister les clés explicitement. - Derrière un reverse proxy / load balancer : sans
UseForwardedHeadersconfiguré (et lesKnownProxies), l'appli voit l'IP du proxy et le schéma HTTP. - Web garden + cache mémoire : chaque processus a son propre cache et ses propres verrous.
À retenir
- HTTP.sys écoute, WAS gère les processus, ANCM charge l'appli dans
w3wp.exe. - In-process par défaut, un pool par appli, « No Managed Code ».
- Recyclage maîtrisé,
AlwaysRunningpour les API, Data Protection persistée.
