Faire un site web, c'est bien. Le déployer, c'est mieux…

Malheureusement, trop peu de développeurs font attention au déploiement. Ce qui fait qu'ils ne sont pas habitués à diagnostiquer une installation ratée ou à identifier une topologie dangereuse. Via ce court article, je me propose de faire un rappel sur la gestion des fichiers de configuration.

On oublie bien vite, qu'une application web ne dépend pas que d'un seul fichier de configuration.

Configuration dans l'application

Les fichiers web.config font partie intégrante de votre application. Vous pouvez en avoir plusieurs. En général, on a un fichier principal et des fichiers secondaires que l'on dépose dans les répertoires où l'on souhaite ajouter ou retirer des paramètres (typiquement, la gestion de droits sur un dossier).

Exemple type :

Chaque dossier a son fichier web.config. Les fichiers dans Admin et Services ajoutent ou retirent des paramètres et héritent des paramètres définis dans le fichier de configuration à la racine de la configuration. Cette partie étant fournie avec votre code, en général, il n'y a pas de problèmes.

Configuration liée au serveur IIS

La configuration IIS est stockée dans le fichier applicationHost.config que l'on peut trouver ici : «  %windir%\system32\inetsrv\config\ ». Celle-ci peut avoir un impact direct sur votre applicatif. Malheureusement, elle diffère d'un OS à l'autre.

Si vous utilisez un OS client (Vista, Windows 7, Windows 8, Windows 10), la configuration sera peut-être différente de l'OS serveur que vous utiliserez en production (2008, 2008R2, 2012, 2012R2). Par prudence, il vaut donc mieux faire ses recettes sur un vrai serveur que sur un poste client.

À noter que :

• certains paramètres fixés peuvent être verrouillés pour vous interdire de les modifier dans vos fichiers web.config. Il est donc bon de connaitre ces verrous (Certains verrous peuvent sauter si on vide les collections via <clear/> et qu'on les repeuple à la main dans son fichier web.config avec des <add>)
• certains paramètres verrouillés sur un OS client, ne le sont pas sur un OS serveur (ex : authentification anonyme déverrouillée sur 2008R2 et verrouillée sur Windows 7)
• certains paramètres n'existent pas dans IIS Express, il est donc bon d'utiliser un IIS complet pour développeur.

  
  

Configuration liée au pool

Le choix du pool a un impact direct sur la configuration. Il y a trois notions à retenir :

1. Pour chaque plateforme x64, x86, il y a un fichier de configuration

Par défaut, notre pool fonctionne en 64 bits. Si on l'autorise à fonctionner en 32, il ne fera plus que du 32 bits.

• Le fichier de configuration 64bits se trouve dans le dossier « %windir%\Microsoft.NET\Framework64 ».
• Le fichier de configuration 32bits se trouve dans le dossier « %windir%\Microsoft.NET\Framework ».

  
  

2. Pour chaque CLR .net, il y a un fichier de configuration

Dans chaque dossier lié à une plateforme, il y a un dossier par CLR déployée. Dans ce dossier se trouve un dossier « config » contenant les configurations.

Exemple pour un pool 64 bits et une CLR4 (c'est le cas par défaut sur les serveurs récents)

%windir%\Microsoft.NET\Framework64\v4.0.30319\Config

3. La gestion du pipeline intégré ou non, a un impact sur les sections utilisables dans vos fichiers de configuration

Avant II7, la notion de pipeline intégré n'existait pas. Il s'agit d'une évolution de IIS qui nous permet d'utiliser nos applications dans un pipeline full .net (au revoir ISAPI) et d'utiliser nos modules .net pour des éléments qui n'étaient pas couverts (exemple : contenu statique).

Avec cette option, un certain nombre de configurations sont déportées dans la section system.webServer. Si vous utiliser httpModules, httpHandler, dans vos fichiers de configurations, ils ne seront pas pris en comptes. Il faudra les remplacer par leurs équivalents dans system.webServer.

Ex : https://msdn.microsoft.com/fr-fr/library/bb763179(v=vs.100).aspx

Imbrication d'applications

Un site peut contenir plusieurs applications. Les applications héritent de la configuration de l'application qui est à leur racine. Cette situation est extrêmement courante. Par exemple, TFS utilise ce type d'implantation pour fonctionner.

Exemple :

Certaines sections de la configuration de l'application racine peuvent ne pas être compatibles avec les applications App1 et App2. Si vous avez pour responsabilité de gérer App1 ou App2, il faudra dans la mesure du possible connaitre la configuration se trouvant à la racine du site.

Si ce n'est pas possible, il faut être prudent et utiliser autant que possible <clear/> et <remove/> dans vos collections de paramètres. En supprimant systématiquement les paramètres dont vous n'avez pas besoin, vous vous prémunissez de leurs éventuels effets de bords.

Imbrication d'applications et de pools

Avec l'imbrication d'applications, on peut aussi se retrouver à imbriquer des pools. On peut donc imbriquer des CLR, et des plateformes 32/64 bits différentes !…

Courage fuyons !

Cette situation est à éviter autant que possible, car on peut conjuguer une multitude de configurations qui ne sont peut-être pas compatibles (exemple : sections qui n'existent pas en .net 2 car elles proviennent de .net 4).

Si vous n'avez pas le choix, et que vous devez effectuer ce genre de déploiement, il faudra utiliser des sections <location>. En utilisant <location> dans le fichier de configuration à la racine du site (et non pas de vos propres applications), vous pourrez créer des zones d'exceptions et ainsi ne pas propager la configuration du site racine aux applications imbriquées.

Bons déploiements ;)