Migration vers IIS7 : Résoudre les problèmes liés aux handlers

17 Fév

Lors d’une migration vers de IISx vers IIS7, il n’est pas rare d’avoir des problèmes de retrocompatibilité de la configuration(et autres 😉 ). Mon usecase est le suivant:

  • développement VS2008 (donc utilisation du serveur web embarqué)
  • publication sous IIS7 sous un Windows Server 2008 R2 en 64bit
  • rien ne marche.

Après étude rapide, il s’avère que la configuration des handlers n’est pas compatible dans IIS7.

En trois étape, je vais montrer comment résoudre le problème.

Pour expliquer la démarche, j’utilise un handler nommé IISHandler, et qui appelé par l’url:

http://url_de_la_webapp/IISHandler

Etape 1: la migration automatique de la configuration vers IIS7

Pour cela, il existe un outil qui va configurer automatique le contenu du fichier web.config vers le bon format. Cet outil se trouve dans le répertoire « C:WindowsSystem32inetsrv » et se lance par la commande:

appcmd.exe migrate config "Default Web Site/WebApplication"

où:

  • « Default Web Site » correspond au site web
  • « WebApplication » l’application concerné par la migration de configuration

Bon. Bien que je sois pas trop fan parce qu’on n’a pas trop la main dessus et qu’il rajoute pleins de truc, cela fonctionne bien.

Dans l’étape suivante, je vais les migrer à la main.

Etape 2: L’erreur 404

La log est la suivante:

Erreur 404

Erreur 404

Ici le handler ne peut pas être chargé. Aucune erreur de compilation. Le problème vient du fait que la configuration des handlers dans les versions antérieurs à IIS7 se faisait dans la partie « system.web » qui doit se trouver dorénavant dans la partie « system.webserver ». Donc:

  • Sous IIS 5.1:
<system.web>
 (...)
 <httpHandlers>
 <add verb="*" path="IISHandler" type="WebApplication.code.IISHandler, WebApplication" />
 </httpHandlers>
 </system.web>

avec « verb » les requests ayant accès(GET, POST…), « path » le chemin dans l’url et « type » le nom de la classe avec son package, suivi du nom du projet.

  • Devient sous IIS7:
<system.webServer>
 <validation validateIntegratedModeConfiguration="false" />
 (...)
 <handlers accessPolicy="Read, Execute, Script">
 <add name="IISHandler" path="IISHandler" verb="*" type="IISHandler" modules="IsapiModule" scriptProcessor="C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" />
 </handlers>
 </system.webServer>

Il faut donc:

  • rajouter « name »
  • le module: IsapiModule pour les handlers
  • la dll faisant tourner le module isapi. Elle peut se trouver dans un autre framework
  • les autorisations et le type de ressource

Et voilà, plus d’erreur 404.

Etape 3: L’erreur 500

La log est la suivante:

Erreur 500

Erreur 500

Cette erreur est due, dans mon cas, à…un problème de compilation. Non pas que la dll n’a pas compilé ou mal, mais elle n’est pas compilée pour du 64bit.

Pour résoudre ce problème, il faut dire au pool d’application lié à l’application qu’il a le droit d’utiliser des applications compilées pour 32bit.

Pour cela:

  • sur le pool d’application concerné, faire « Advanced settings… »
  • la deuxième option est « Enable 32bits Applications ».
  • Setter la valeur à « True »
Paramétrage du pool d'applications

Paramétrage du pool d'applications

Voilà. Je n’ai pas rencontré d’autres problèmes concernant une migration vers IIS7.

One thought on “Migration vers IIS7 : Résoudre les problèmes liés aux handlers

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *