Mercredi 5 février a été la journée où je me suis cassé les dents sur un problème qui, à première vue, était inexplicable et totalement à l’encontre de l’ordre des choses.
S’il y a un signe universel qui signifie quelque chose en informatique, c’est bien celui-ci. Lorsque quelque chose doit fonctionner d’une façon et que, pour une raison inconnue, ce n’est pas le cas, il y a anguille sous roche.
Mise en contexte
Mon poste de développement utilise une configuration assez à jour (Windows 8 et IIS 8) et le projet sur lequel je travaille est aussi à la fine pointe (.NET 4 et ASP.NET MVC 5).
À ce moment de l’histoire, aucun signe ne pouvait laisser présager qu’un problème se pointe le bout du nez. Les fonctionnalités développées ont été accomplies dans le temps et le budget requis.
À partir de là, on pense vivre un rêve. On passe l’étape de la revue de sprint avec le client et tout le monde est heureux. Du beau travail, vraiment.
Juste pour tester…
Ce qui a été développé est un composant faisant oeuvre de service web reliant une application web et une application de gestion utilisée par le client. Étant donné que le composant développé se met les pieds dans une partie critique, il a été entendu qu’une bonne période de tests serait mise de l’avant avant de donner le feu vert pour la production.
Le principal but de cette période de tests sera d’exécuter parallèlement l’application afin d’être en mesure de comparer l’état des données avec la production pour en assurer la précision.
En bout de compte, pour valider ces données, le composant a été hébergé sur un serveur temporaire où il sera observé sous toutes ses coutures pendant quelques jours.
La mise en ligne
Une fois le serveur web accessible, je me lance dans la mise en ligne. Une fois le nécessaire déployé, j’ouvre un nouvel onglet à partir de mon navigateur web et j’ai la page suivante :
Après les vérifications nécessaires permettant de m’assurer que je ne suis pas fou ou que j’ai commis une erreur humaine, je demande une double vérification par un collègue. Malheureusement, tout est en ordre du côté de mon application. Le site web servait le contenu sauf celui provenant d’ASP.NET MVC.
L’ordre normal des choses n’est soudainement pas respecté. Je confirme que je n’étais pas très heureux à cet instant. La mise en ligne allait prendre officiellement plus de temps que prévu.
Une mise à jour
Dans mon cas, le serveur en question avait pris un peu la poussière dernièrement. Certaines mises à jour Windows étaient à appliquer sur celui-ci.
Une mise à jour en particulier est importante à appliquer, car elle vise précisément à adresser cette situation. Il s’avère qu’IIS 7 n’avait pas été initialement conçu pour servir des contenus web n’ayant pas d’extension (ex. : mapage.aspx au lieu de /monaction/1).
Donc, la mise à jour corrige le tir à ce sujet. Une fois qu’elle a été installée sur le serveur, mon application s’est mise à fonctionner comme prévu.
Alternativement, j’aurais pu activer l’option runAllManagedModulesForAllRequests= »true ». Toutefois, comme son nom l’indique, la totalité des requêtes faites à mon site web aurait passé à travers des modules ASP.NET. Selon l’achalandage à votre site, cela peut avoir un impact de performance majeur.
Sources :
- http://www.hanselman.com/blog/BackToBasicsDynamicImageGenerationASPNETControllersRoutingIHttpHandlersAndRunAllManagedModulesForAllRequests.aspx
- http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html
- http://stackoverflow.com/questions/8047709/asp-net-mvc-3-with-net-4-and-runallmanagedmodulesforallrequests-false
- http://support.microsoft.com/kb/980368
French Coding 