Initialisation de l’application IIS 8.0

par Shaun Eagan

Compatibilité

Version	Notes
IIS 8.0	L’initialisation de l’application a été intégrée pour IIS 8.0.
IIS 7.5	L’initialisation de l’application a été publiée en tant que module hors bande pour IIS 7.5.
IIS 7.0	L’initialisation de l’application n’a pas été prise en charge pour IIS 7.0.

Problème

Un problème courant rencontré par les administrateurs de site web est la nécessité d’effectuer des tâches d’initialisation et de « préchauffer » pour une application web. Les applications web plus volumineuses et plus complexes peuvent avoir besoin d’effectuer un traitement de démarrage long, des caches en mémoire prime, générer du contenu, etc. avant de traiter la première requête HTTP.

Solution

La fonctionnalité d’initialisation d’application IIS 8.0 permet aux administrateurs de site web de configurer IIS 8.0 de manière proactive pour effectuer des tâches d’initialisation pour une ou plusieurs applications web. Pendant qu’une application est initialisée, IIS 8.0 peut également être configuré pour retourner du contenu statique en tant qu’espace réservé ou « page de démarrage » jusqu’à ce qu’une application ait terminé ses tâches d’initialisation.

La fonctionnalité d’initialisation d’application est configurée via une combinaison de règles globales et spécifiques à l’application qui indiquent à IIS 8.0 comment et quand initialiser des applications web. La fonctionnalité d’initialisation d’application prend également en charge l’intégration au module de réécriture d’URL IIS pour prendre en charge la gestion plus complexe du contenu d’espace réservé pendant qu’une application est toujours initialisée.

Instructions pas à pas

Prérequis

La fonctionnalité d’initialisation d’application nécessite l’installation d’IIS 8.0. En outre, la fonctionnalité d’initialisation d’application dans la sous-fonctionnalité « Développement d’applications » IIS doit être installée.

La capture d’écran suivante de l’interface utilisateur de Windows Server 2012 Gestionnaire de serveur montre la fonctionnalité d’initialisation de l’application.

Solutions de contournement pour les bogues connus

• Il n’existe pas de bogues connus pour cette fonctionnalité pour l’instant.

Initialisation d’application globale

La fonctionnalité d’initialisation de l’application peut être configurée à deux emplacements : le fichier applicationHost.config à l’échelle de l’ordinateur et le fichier web.config au niveau de l’application. La configuration dans le fichier applicationHost.config contient des paramètres d’initialisation d’application « globaux », tandis qu’un fichier web.config au niveau de l’application contient des paramètres d’initialisation d’application « local ».

Dans cette procédure pas à pas, vous allez configurer un exemple d’application pour qu’elle soit toujours initialisée lorsque le pool d’applications associé à l’application démarre. Étant donné que les comportements de pool d’applications ne peuvent être configurés que dans applicationHost.config, l’exécution de l’initialisation de l’application chaque fois qu’un pool d’applications démarre est considéré comme faisant partie des paramètres d’initialisation d’application « globaux ».

Modifications dans applicationHost.config

Ouvrez le fichier applicationHost.config situé %WINDIR%\system32\inetsrv\config dans Bloc-notes Windows. (N’oubliez pas d’exécuter l’éditeur de texte avec l’option « Exécuter en tant que Administration istrator » !)

Recherchez la <section de configuration applicationPools> , puis recherchez l’entrée du pool d’applications avec le nom « .NET v4.5 ».

Modifiez l’entrée du pool d’applications afin que le pool d’applications soit toujours en cours d’exécution. Pour les applications où vous souhaitez que l’initialisation d’application globale se produise, vous souhaitez normalement que le pool d’applications associé soit démarré et en cours d’exécution. L’attribut en gras dans l’extrait de code de configuration montre ce qu’il faut ajouter à l’entrée de configuration.

<add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />

Faites défiler un peu plus vers le bas dans applicationHost.config jusqu’à l’élément <sites> de configuration. Dans cette section, il y aura une <application> entrée pour l’exemple d’application (consultez l’Annexe pour obtenir des instructions sur la création de l’exemple d’application sur votre ordinateur). L’application est appelée « appinit » et a une valeur d’attribut de chemin d’accès « /appinit ». Modifiez l’entrée <application> en ajoutant l’attribut preloadEnabled en gras, comme indiqué dans l’extrait de code de configuration, puis enregistrez vos modifications.

<application path="/appinit" preloadEnabled="true" applicationPool=".NET v4.5">

La définition de preloadEnabled sur « true » indique à IIS 8.0 qu’elle envoie une demande « fake » à l’application lorsque le pool d’applications associé démarre. C’est pourquoi à l’étape précédente, nous définissons le startMode du pool d’applications sur « AlwaysRunning ».

Avec la combinaison du pool d’applications toujours en cours d’exécution et de l’application elle-même marquée pour recevoir toujours une fausse demande, chaque fois que la machine redémarre et/ou que le service World Wide Web est recyclé, IIS 8.0 garantit que l’instance du pool d’applications est en cours d’exécution et que l’application « /appinit » est toujours envoyée une fausse requête pour déclencher le démarrage de l’application.

Modifications dans le fichier web.config de l’application

À l’aide d’une deuxième instance de Bloc-notes Windows, ouvrez le fichier web.config au niveau de l’application situé à l’emplacement suivant. (N’oubliez pas d’exécuter l’éditeur de texte avec l’option « Exécuter en tant qu’administrateur » !)

C:\inetpub\wwwroot\appinit

Remarque : modifiez la lettre de lecteur si votre site web par défaut est installé sur un autre lecteur physique.

Le fichier web.config comporte quelques sections de configuration déjà préremplies, mais commentées. Supprimez les marques de commentaire de l’extrait de code de configuration indiqué à l’intérieur de la section de configuration <system.webServer> . Cet extrait de code se trouve juste sous le commentaire « Exercice 1 - Étape 1 » dans le fichier web.config. Ensuite, enregistrez vos modifications.

<applicationInitialization
    remapManagedRequestsTo="Startup.htm" 
    skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

L’élément applicationInitialization indique à IIS qu’il doit émettre une demande à l’URL racine de l’application (« /default.aspx » dans cet exemple) afin d’initialiser l’application. Si IIS attend la fin de la demande « /default.aspx, elle servira « Startup.htm » à tous les clients de navigateur actifs. « Startup.htm » est la « page de démarrage » de l’application.

Exécution de l'application

À partir d’une fenêtre d’invite de commandes avec élévation de privilèges , recyclez le service World Wide Web avec la commande indiquée ci-dessous :

net stop w3svc & net start w3svc

N’oubliez pas d’exécuter la fenêtre d’invite de commandes à l’aide de l’option « Exécuter en tant qu’administrateur ».

À l’aide d’Internet Explorer, accédez à l’URL suivante :

http://localhost/appinit/default.aspx

Le navigateur retourne la page statique « Startup.htm » avec un arrière-plan gris pendant les premières secondes, car il s’agit de la « page de démarrage » configurée dans web.config. Vous pouvez continuer à actualiser la page dans votre navigateur web et observer qu’environ huit secondes plus tard (simulées avec un thread en veille dans l’exemple d’application global.asax) vous recevez le contenu « réel » pour default.aspx avec un arrière-plan blanc. Cela indique que l’initialisation de l’application s’est terminée.

Configuration du recyclage des processus superposés

IIS 8.0 intègre l’initialisation globale des applications avec le recyclage des processus qui se chevauchent en effectuant l’initialisation d’application dans un processus superposé en arrière-plan. Lorsque IIS détecte qu’un processus de travail actif est recyclé, IIS ne bascule pas le trafic actif vers le nouveau processus de travail recyclé tant que le nouveau processus de travail n’a pas terminé d’exécuter toutes les URL d’initialisation de l’application dans le nouveau processus. Cela garantit que les clients parcourant votre site web ne voient pas les pages d’initialisation d’application une fois qu’une application est active et en cours d’exécution.

Revenez à l’instance du Bloc-notes qui a applicationHost.config. Modifiez l’entrée du pool d’applications pour .NET v4.5 » pour ressembler à l’extrait de code de configuration indiqué ci-dessous :

<add name=".NET v4.5"
                startMode="AlwaysRunning"
    managedRuntimeVersion="v4.0" >
  <recycling logEventOnRecycle="Schedule">
    <periodicRestart requests="30" />
  </recycling>
</add>

N’oubliez pas d’enregistrer vos modifications !

L’élément <de recyclage> indique à IIS de recycler le processus de travail toutes les 30 requêtes HTTP.

Exécuter l’application une deuxième fois

À partir d’une fenêtre d’invite de commandes avec élévation de privilèges , recyclez le service World Wide Web avec la commande indiquée ci-dessous :

net stop w3svc & net start w3svc

À l’aide d’une nouvelle instance d’Internet Explorer, accédez une fois de plus à :

http://localhost/appinit/default.aspx

Notez que la page de démarrage « Startup.htm » avec l’arrière-plan gris s’affiche.

Ensuite, extrayez le Gestionnaire des tâches et vérifiez que l’onglet Processus s’affiche. Triez la liste des processus par nom jusqu’à ce qu’une instance de w3wp.exe s’exécute. Cette instance est le processus de travail qui exécute actuellement l’application « appinit » ASP.NET.

Actualisez le navigateur quelques fois jusqu’à ce que le contenu de la page de default.aspx réelle soit retourné. Vous savez que l’application exécute la page « réelle » default.aspx lorsque l’arrière-plan passe en blanc. Ensuite, organisez les fenêtres sur votre écran pour que vous puissiez voir à la fois le Gestionnaire des tâches et le navigateur.

Revenez maintenant au navigateur et actualisez la page au moins 30 fois, ce qui entraîne la recyclage du pool d’applications par IIS. Vous pouvez arrêter l’actualisation de la page lorsque vous voyez une deuxième instance de w3wp.exe s’afficher dans la liste des processus du Gestionnaire de tâches, comme indiqué ci-dessous :

La capture d’écran montre la deuxième instance de w3wp.exe a démarré en raison de la limite de recyclage des processus définie précédemment.

Vous pouvez continuer à actualiser régulièrement la fenêtre du navigateur pendant les dix prochaines secondes. Notez que default.aspx continue à s’exécuter. Lorsque le recyclage se chevauche, une instance w3wp.exe disparaît de la fenêtre Processus du Gestionnaire des tâches.

Pendant toute la durée du recyclage superposé, vous continuez à voir le contenu du default.aspx « réel » servi, même si l’initialisation de l’application a été configurée pour l’application et a exécuté l’URL d’initialisation en arrière-plan dans la nouvelle instance de w3wp.exe.

Réécriture d’URL et initialisation d’application

Par défaut, l’initialisation de l’application vous permet uniquement de spécifier une url de « page de démarrage » unique à afficher pendant l’initialisation d’une application. Toutefois, la fonctionnalité d’initialisation d’application prend en charge quelques variables serveur qui peuvent être utilisées pour contrôler le traitement des demandes pendant l’initialisation d’une application. Cela vous permet de créer des règles déclaratives à l’aide du module de réécriture d’URL contenant des mappages plus complexes pour le contenu statique prégénéré.

Dans cette procédure pas à pas, vous remplacez l’attribut remapManagedRequestsTo par un ensemble de règles de réécriture d’URL qui effectuent le même résultat final.

Remarque : Consultez l’annexe pour obtenir des instructions sur l’installation de la réécriture d’URL.

Modifications dans applicationHost.config

À l’aide de l’instance de Bloc-notes Windows avec applicationHost.config ouverte, rétablissez le pool d’applications et les éléments d’application pour désactiver tout traitement d’initialisation d’application global. Les paramètres globaux sont supprimés à cette étape, car le reste de cette procédure pas à pas se concentre sur le comportement d’initialisation d’application configuré.

Les entrées applicationHost.config pour le pool d’applications et l’application sont indiquées ci-dessous.

Entrée de configuration du pool d’applications :

<add name=".NET v4.5" managedRuntimeVersion="v4.0" />

Entrée de configuration d’application :

<application path="/appinit" applicationPool=".NET v4.5">

N’oubliez pas d’enregistrer vos modifications lorsque vous avez terminé !

En outre, pour vous assurer que les modifications prennent effet dans IIS, à partir d’une fenêtre d’invite de commandes avec élévation de privilèges, recyclez le service World Wide Web avec la commande ci-dessous :

net stop w3svc & net start w3svc

Modifications apportées au web.config au niveau de l’application

À l’aide de l’instance de Bloc-notes Windows qui a ouvert le fichier web.config au niveau de l’application, supprimez l’attribut remapManagedRequestsTo de l’élément<applicationInitialization>. La <applicationInitialization> section de configuration doit maintenant ressembler à cet extrait de code de configuration.

<applicationInitialization skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

Étant donné que l’élément <applicationInitialization> ne définit plus d’URL pour remapper les demandes, ajoutez un ensemble de règles de réécriture d’URL. Ensuite, ajoutez une règle de réécriture qui mappe explicitement les demandes adressées à « default.aspx », ainsi que « / » pour acheminer vers « Startup.htm ». Deux règles sont nécessaires, car le module de réécriture d’URL ne « sait pas » sur le fonctionnement des documents par défaut. Étant donné que « / » équivaut à « default.aspx » dans ASP.NET applications, vous avez besoin de deux règles de réécriture d’URL : une règle pour chaque variante d’URL.

Les nouvelles règles sont présentées en gras ci-dessous. Vous pouvez également annuler les marques de commentaire des règles de réécriture d’URL préremplies sous le commentaire « Exercice 2 - Étape 2 Mappage des demandes à la page d’accueil » dans le fichier web.config.

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
  </rules>
</rewrite>

Certains éléments à noter sur ces règles : tout d’abord, l’attribut stopProcessing est défini sur « true » sur la <règle/> les éléments. Cela est nécessaire pour ajouter une règle de réécriture d’URL catch-all ultérieurement, et pour les demandes de default.aspx ou « / » que vous ne souhaitez pas que la règle catch-all s’exécute.

Ensuite, notez que nous avons une condition de réécriture d’URL dans les <conditions/> l’élément. Cette condition indique effectivement « appliquer une règle uniquement lorsque l’application est dans un état d’initialisation ». La variable de serveur « APP_WARMING_UP » est définie par IIS sur une valeur de « 1 » lorsque l’initialisation de l’application est active et IIS traite toujours toutes les URL d’initialisation.

Enfin, notez que l’action a été définie pour réécrire la requête active pour exécuter « Startup.htm ». Cette règle a l’effet d’indiquer à IIS de transmettre la requête au gestionnaire de fichiers statiques qui restitue ensuite la page statique Startup.htm.

Ensuite, vous ajoutez une règle de réécriture catch-all. Lorsque vous utilisez le module de réécriture d’URL conjointement avec l’initialisation de l’application, une règle catch-all qui se déclenche si aucune des règles précédentes ne correspond est nécessaire. Ajoutez la règle en gras indiquée ci-dessous à la section réécriture en tant que règle catch-all. Vous pouvez également supprimer les commentaires de la règle catch-all préremplie dans web.config située sous le commentaire « Exercice 2 - Étape 2 Configuration d’une règle catch-all » dans le fichier web.config.

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="All Other Requests">
      <match url=".*" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <serverVariables>
        <set name="SKIP_MANAGED_MODULES" value="0" />
      </serverVariables>
      <action type="Rewrite" url="{URL}" />
    </rule>
  </rules>
</rewrite>

Enregistrez vos modifications lorsque vous avez terminé !

La nouvelle règle correspond à toute URL qui l’atteint et indique à IIS de continuer à traiter la demande qui a été adressée à l’URL entrante. La règle définit également une variable serveur appelée « SKIP_MANAGED_MODULES » sur une valeur de « 0 », qui équivaut à « false ». Ce paramètre indique à IIS qu’il doit traiter la requête réécrite à partir de la réécriture d’URL de la même façon que si la demande était normalement arrivée hors du réseau.

Exécution de l'application

À partir d’une fenêtre d’invite de commandes avec élévation de privilèges, recyclez le service World Wide Web avec la commande indiquée ci-dessous :

net stop w3svc & net start w3svc

À l’aide d’une nouvelle instance d’Internet Explorer, accédez une fois de plus à :

http://localhost/appinit/default.aspx

Même si les règles de réécriture d’URL sont maintenant utilisées pour définir la logique de page de démarrage, vous voyez toujours le même comportement à partir de la première procédure pas à pas. La page Startup.htm avec l’arrière-plan gris s’affiche initialement. Si vous actualisez régulièrement le navigateur, environ huit secondes plus tard, vous voyez à nouveau le changement d’arrière-plan de la page en blanc, indiquant que la page « réelle » default.aspx est en cours de traitement maintenant que l’initialisation de l’application est terminée.

Règles de page de démarrage complexes

Les procédures pas à pas précédentes utilisent l’initialisation de l’application comme mappage direct de l’URL « X » à l’URL « Y ». Dans cette procédure pas à pas, vous allez implémenter un scénario d’initialisation d’application plus complexe.

Dans votre navigateur, accédez aux deux URL suivants :

• http://localhost/appinit/ImageHandler.ashx?image=Lighthouse
• http://localhost/appinit/ImageHandler.ashx?image=Tulips

Ces URL sont des exemples de contenu statique généré dynamiquement. Pour cet exemple d’application, le code à l’intérieur de ImageHandler.ashx examine la clé de chaîne de requête « image ». Si la valeur de cette chaîne de requête est « Lighthouse » ou « Tulips », le gestionnaire ASP.NET transmet le JPG correspondant situé dans le dossier App_Data.

Étant donné que le gestionnaire d’images retourne simplement des images, vous souhaitez pouvoir continuer à retourner une image appropriée même lors de l’initialisation de l’application. Bien que la mécanique de service de ces images utilise du code managé, vous pouvez rapidement servir des images prégénérées aux clients, même si l’application ASP.NET sous-jacente prend beaucoup de temps pour démarrer et initialiser elle-même.

Modifications apportées au web.config au niveau de l’application

À l’aide de l’instance de Bloc-notes Windows qui a ouvert web.config au niveau de l’application, ajoutez une autre règle de réécriture d’URL avant la règle catch-all finale. Le nouvel extrait de code à ajouter est illustré ci-dessous. Vous pouvez également supprimer les marques de commentaire de la règle de gestionnaire d’images préremplie dans web.config située sous le commentaire « Exercice 3 - Étape 1 Règles de page de démarrage complexes » dans le fichier web.config.

<rule name="Image Handler Remapping" stopProcessing="true">
  <match url="ImageHandler.ashx" />
  <conditions>
    <add input="{APP_WARMING_UP}" pattern="1" /> 
    <add input="{QUERY_STRING}" pattern="image=([A-Za-z]+)&amp;?" /> 
  </conditions>
  <action type="Rewrite" url="Images/{C:1}_static.jpg" appendQueryString="false" />
</rule>

Enregistrez vos modifications lorsque vous avez terminé !

Tout comme avec les règles de réécriture pour default.aspx et « / », cette règle a l’attribut stopProcessing défini sur « true » pour s’assurer que les requêtes adressées à ImageHandler.ashx ne sont pas accidentellement passées à la règle de réécriture catch-all finale lors de l’initialisation de l’application.

Pour les demandes adressées à « ImageHandler.ashx », la règle de réécriture utilise un groupe de capture d’expressions régulières pour extraire l’image demandée à partir de la chaîne de requête. Modèle de définition de modèle de correspondance="image=([A-Za-z]+)& ? » indique à IIS d’extraire la valeur de la variable de chaîne de requête « image ». Cette valeur est ensuite utilisée dans l’attribut URL de l’attribut d’action : url="Images/{C :1}_static.jpg »..

L’attribut d’URL sur l’élément d’action indique au module Url Rewrite de réécrire ImageHandler.ashx pour pointer au lieu de cela sur les fichiers du sous-répertoire Images de l’application. En outre, la valeur de chaîne de requête capturée par l’expression régulière est utilisée pour former le nom du fichier qui sera finalement servi à partir du sous-répertoire Images. Par exemple, une demande adressée à ImageHandler.ashx ?image=Tulips sera réécrite en Images/Tulips_static.jpg.

Si vous accédez au répertoire inetpub\wwwroot\appinit à l’aide de l’Explorateur Windows et recherchez dans le sous-répertoire Images, vous voyez deux fichiers : un représentant la version « statique » de Tulips.jpg et l’autre représentant la version « statique » de Lighthouse.jpg. Ces images statiques agissent comme du contenu prégéné qui peut être servi pendant l’initialisation de l’application.

Exécution de l'application

À partir d’une fenêtre d’invite de commandes avec élévation de privilèges, recyclez le service World Wide Web avec la commande indiquée ci-dessous :

net stop w3svc & net start w3svc

À l’aide d’Internet Explorer, accédez à l’une des options suivantes :

http://localhost/appinit/ImageHandler.ashx?image=Lighthouse

or

http://localhost/appinit/ImageHandler.ashx?image=Tulips

Notez comment les images retournées dans les deux cas incluent un filigrane indiquant qu’il s’agit des versions prégénées « statiques » des images. Le filigrane est du texte dans la partie supérieure de l’image indiquant « Cette image est la version statique de.... »

Si vous actualisez votre navigateur environ 10 secondes plus tard, le contenu de l’image retourné passe au contenu « réel » servi par le gestionnaire ImageHandler.ashx. Le filigrane disparaît, ce qui indique que le contenu est désormais généré dynamiquement par le gestionnaire ASP.NET depuis l’initialisation de l’application.

[Remarque : Si Internet Explorer semble ne pas être actualisé, cliquez sur l’icône « document rompu » dans la barre d’adresses ou sur l’icône d’actualisation pour forcer Internet Explorer à recharger la page.]

Résumé

La fonctionnalité d’initialisation d’application IIS 8.0 permet aux développeurs et aux administrateurs de retourner du contenu statique aux navigateurs pendant que IIS initialise une application « froide ». Le service de contenu statique immédiatement aux navigateurs offre aux clients une meilleure expérience utilisateur. Au lieu d’applications de démarrage à froid entraînant une page de navigateur vide ou une icône d’attente en rotation, la fonctionnalité d’initialisation de l’application peut être utilisée pour servir du contenu statique pertinent pendant que l’application sous-jacente termine le traitement d’initialisation coûteux.

Le processus d’initialisation peut se produire automatiquement chaque fois qu’un serveur web est mis en ligne ou recyclé. Pour les scénarios où les administrateurs de serveur ne veulent pas initialiser greedily les applications, le processus d’initialisation peut être déclenché à la demande lorsque la première requête arrive à une application « froide ».

Pour l’initialisation globale et locale de l’application, le module Réécriture d’URL peut être intégré pour fournir des règles d’initialisation plus riches et plus complexes. À l’aide de règles de réécriture d’URL intégrées à la fonctionnalité d’initialisation d’application, il est possible de servir différents types de contenu statique prédéfini pour différentes URL et chemins virtuels tandis que IIS continue de démarrer une application en arrière-plan.

Annexe - configuration de l’exemple d’application ASP.NET

Remarque - les étapes suivantes supposent que votre serveur a déjà installé IIS 8.0 et ASP.NET 4.5 activé pour une utilisation dans IIS 8.0.

Décompresser l’exemple d’application

L’exemple d’application ASP.NET est contenu dans le fichier .zip suivant :

Décompressez le fichier dans le dossier wwwroot sur votre serveur web. Par exemple, si votre serveur web a installé le « site web par défaut » sur le lecteur C :\, décompressez le contenu du fichier c:\inetpub\wwwroot\appinitsur .

Créer une application dans IIS 8.0

Après avoir décompressé l’exemple « appinit » sur le système de fichiers, vous devez configurer le dossier en tant qu’application ASP.NET dans IIS 8.0. La capture d’écran ci-dessous montre l’exemple d’application appinit configuré en tant qu’application dans IIS 8.0. Notez également que l’application est affectée au pool d’applications .NET v4.5 ».

Installer le module de réécriture d’URL

L’exemple d’application utilise le module Réécriture d’URL pour une intégration avancée à la fonctionnalité d’initialisation d’application. Vous devez installer le module Réécriture d’URL sur votre serveur ; il peut être téléchargé à partir de : https://www.iis.net/downloads/microsoft/url-rewrite.

Configurer le module de réécriture d’URL

Une fois que le module réécriture d’URL a été installé sur votre serveur web, vous devez modifier le fichier APPLICATIONHost.config IIS pour autoriser l’utilisation de la variable de serveur SKIP_MANAGED_MODULES prise en charge par la fonctionnalité d’initialisation de l’application.

Ouvrez le fichier applicationHost.config à l’échelle de l’ordinateur dans un éditeur de texte tel que le Bloc-notes. Par exemple, si vous avez installé le système d’exploitation sur le lecteur C :\, le fichier applicationHost.config se trouve à l’emplacement C:\Windows\System32\inetsrv\config.

Faites défiler le fichier vers le bas et recherchez la section de sécurité. Cette section commence par l’élément Xml : <sécurité>.

Tapez les éléments Xml suivants avant l’élément <de sécurité> :

<rewrite>
  <allowedServerVariables>
    <add name="SKIP_MANAGED_MODULES" />
  </allowedServerVariables>
</rewrite>

Enregistrez les modifications apportées au fichier applicationHost.config.