Application_Start ne se déclenche pas ?

Question

J'ai une application ASP.NET MVC (beta) sur laquelle je travaille et j'ai du mal à savoir si je fais quelque chose de mal, ou si mon Application_Start dans Global.asax.cs ne se déclenche pas lorsque j'essaie de déboguer l'application.

J'ai placé un point d'arrêt sur une ligne dans mon Application_Start et je m'attends à ce que, lorsque je tente de déboguer l'application, le point d'arrêt soit atteint... mais il ne l'est jamais. Pas après avoir réinitialisé IIS, pas après avoir redémarré, jamais. Est-ce que quelque chose m'échappe ? Pourquoi cette méthode n'est-elle jamais appelée ?

Answer 1

Note : une belle une alternative simple à l'utilisation du serveur intégré "Visual Studio Development Server". o IIS Express (par exemple, parce que vous êtes développer contre IIS et avoir des paramètres particuliers dont vous avez besoin pour le bon fonctionnement de votre application) est de rester simplement en cours d'exécution dans IIS (j'utilise le serveur Web personnalisé + entrée dans le fichier hosts + liaison IIS au même domaine).

1. attendez que la session de débogage démarre ok
2. il suffit alors de modifier le web.config racine à l'aide d'un espace et de sauvegarder le fichier fichier
3. rafraîchissez votre page (Ctrl + F5)

Votre point d'arrêt devrait être atteint correctement et vous pouvez continuer à déboguer dans votre fichier habitat naturel de l'IIS . Super !

Answer 2

Si c'est dans IIS, l'application peut démarrer avant que le débogueur ne soit attaché. Si c'est le cas, je ne suis pas sûr que vous puissiez mettre le thread en veille suffisamment longtemps pour que le débogueur s'y attache.

Dans Visual Studio, vous pouvez attacher le débogueur à un processus. Pour ce faire, cliquez sur Debug >> Attach to process. Attachez le processus au navigateur, puis lancez votre application. Pour plus de sécurité, redémarrez ensuite IIS et lancez le site. Je ne suis pas convaincu à 100% que cela résoudra le problème, mais c'est beaucoup mieux que de déclencher un thread sleep dans App_Start.

Une autre option consiste à héberger temporairement le serveur web intégré jusqu'à ce que vous ayez fini de déboguer le démarrage de l'application.

Answer 3

Ce qui suit est utile dans tous les cas (peu importe que vous utilisiez IIS, Cassini ou autre) :

1. Définissez votre point d'arrêt dans Application_Start
2. Démarrer le débogage (le point d'arrêt n'est probablement pas atteint) -> une page est affichée dans le navigateur.
3. Modifiez le fichier web.config (par exemple, entrez une ligne vide) et sauvegardez-le.
4. Rechargez la page dans le navigateur -> le point d'arrêt est atteint !

Pourquoi cela fonctionne-t-il ? Lorsque le web.config est modifié, le serveur web (IIS, Cassini, etc.) effectue un recyclage, mais dans ce cas (pour une raison quelconque), le processus reste le même, donc vous restez attaché à lui avec le débogueur (Visual Studio).

Answer 4

J'ai moi aussi des problèmes avec les points d'arrêt dans application_start avec IIS une application hébergée. Une bonne solution consiste à utiliser Debugger.Break() ; dans le code au lieu du point d'arrêt de VS.

Answer 5

J'ai exactement le même problème. J'ai fait beaucoup de renommage dans ma solution. Après cela, j'ai deux applications web qui ne fonctionnent pas et plusieurs autres applications web qui fonctionnent bien. J'ai reçu une erreur disant que j'ai de mauvaises routes. Lorsque j'ai essayé de configurer le point de rupture dans Application_Start puis redémarrer IIS, VS n'a pas interrompu l'exécution. Avec des applications web utilisables, la rupture fonctionnait. Ensuite, je me suis souvenu que "clean solution" et "rebuild" ne suppriment pas les assemblages laissés après le renommage. Et c'était la solution ! J'ai nettoyé manuellement bin des répertoires de mes applications Web boguées, puis j'ai vu une nouvelle erreur dans Global.asax Inherits="" a été référencé comme une ancienne dll. Je l'ai changé sur la nouvelle et la rupture a commencé à fonctionner. Supposons que, pendant le renommage, Global.asax n'a pas été mis à jour, et que IIS a pris l'ancien assemblage (avec de mauvaises routes) pour démarrer l'application.