Application_Start ne se déclenche pas?

J'ai une application ASP.NET MVC (bêta) sur laquelle je travaille et j'ai du mal à déterminer si je fais quelque chose de mal ou si ma Application_Startméthode dans Global.asax.cs ne se déclenche pas lorsque j'essaye pour déboguer l'application.

J'ai mis un point d'arrêt sur une ligne dans ma Application_Startméthode et je m'attends à ce que lorsque j'essaye de déboguer l'application, le point d'arrêt soit touché ... mais cela ne le fait jamais. Pas après avoir réinitialisé IIS, pas après le redémarrage, jamais. Est-ce que je manque quelque chose? Pourquoi cette méthode n'est-elle jamais appelée?

Si cela se trouve dans IIS, l'application peut démarrer avant que le débogueur ne soit attaché. Si tel est le cas, je ne suis pas sûr que vous puissiez endormir suffisamment longtemps pour vous attacher.

Dans Visual Studio, vous pouvez attacher le débogueur à un processus. Pour ce faire, cliquez sur Déboguer >> Attacher au processus. Connectez-vous au navigateur, puis appuyez sur votre application. Pour être sûr, redémarrez IIS et accédez au site. Je ne suis pas convaincu à 100% que cela résoudra le problème, mais cela fera beaucoup mieux que de déclencher un sommeil de thread dans App_Start.

Une autre option consiste à héberger temporairement sur le serveur Web intégré jusqu'à ce que vous ayez terminé le démarrage de l'application de débogage.

Remarque: une alternative simple et intéressante à l'utilisation du "Serveur de développement Visual Studio" ou IIS Express intégré (par exemple, parce que vous développez contre IIS et que vous avez des paramètres particuliers dont vous avez besoin pour le bon fonctionnement de votre application) est de simplement continuer à fonctionner dans IIS (je utiliser le serveur Web personnalisé + entrée de fichier hosts + liaison IIS au même domaine)

1. attendez que la session de débogage démarre ok
2. puis modifiez simplement un espace blanc dans le fichier web.config racine et enregistrez le fichier
3. rafraîchir votre page (Ctrl + F5)

Votre point d'arrêt doit être correctement atteint et vous pouvez continuer à déboguer dans votre habitat IIS naturel . Génial !

Ce qui suit aide dans tous les cas (peu importe si vous utilisez 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. Changez web.config (par exemple, entrez une ligne vide) et enregistrez-le
4. Rechargez la page dans le navigateur -> le point d'arrêt est atteint!

Pourquoi ça marche? Lorsque 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, vous y restez donc attaché avec le débogueur (Visual Studio ).

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

J'ai juste le même problème. J'ai beaucoup renommé dans ma solution. Après cela, j'ai eu deux applications Web qui ne fonctionnaient pas et plusieurs autres applications Web allaient bien. J'ai eu l'erreur que j'ai de mauvais itinéraires. Lorsque j'ai essayé de configurer le point d'arrêt dans la Application_Startméthode, puis de redémarrer IIS, VS n'a pas interrompu l'exécution. Avec des applications Web fonctionnelles, la pause fonctionnait. Ensuite, j'ai rappelé que la "solution propre" et la "reconstruction" ne suppriment pas les assemblys qui sont restés après le changement de nom. Et c'était la solution! J'ai nettoyé manuellement les binrépertoires de mes buggy-web-applications, puis j'ai vu une nouvelle erreur d' Global.asax Inherits=""attribut référencée sur l'ancienne DLL. Je l'ai changé sur nouveau et la pause a commencé à fonctionner. Supposons que, lors du changement de nom Global.asax n'a pas été mis à jour,

Nous avons eu le même problème dans un projet que nous avions repris après qu'un autre fournisseur l'ait construit. Le problème était que même s'il y avait un certain nombre de commandes écrites par le fournisseur précédent dans Global.asax.cs, ce qui pouvait vous amener à croire qu'il était utilisé, il était en fait entièrement ignoré. Global.asax n'en a pas hérité, et il est facile de ne jamais voir ce fichier si le fichier .cs est présent - vous devez cliquer avec le bouton droit sur Global.asax et cliquer sur Afficher le balisage pour le voir réellement.

Global.asax:

<%@ Application Language="C#" %>

Doit être changé en:

<%@ Application Codebehind="Global.asax.cs" Inherits="ProjectNamespace.MvcApplication" Language="C#" %>

Où ProjectNamespace est quel que soit l'espace de noms de votre classe Global.asax.cs (généralement le nom de votre projet).

Dans notre cas, le fichier contenait un tas de code en ligne, dont certains ont été copiés à partir du fichier .cs, d'autres non. Nous venons de transférer le code en ligne dans le fichier .cs et avons progressivement fusionné nos modifications.

Essayez de basculer le mode de pipeline géré pour le pool d'applications sur "Classique" au lieu de "Intégré". Cela a résolu le problème pour moi. En regardant la raison maintenant ...

(Les accessoires pour cette réponse appartiennent à Flores (voir son commentaire sur sa propre réponse), je voulais juste fournir cela comme une réponse séparée pour attirer plus l'attention sur elle)

Assurez-vous que votre global.asax ne se trouve pas dans un sous-répertoire. Il doit être placé au niveau racine de votre projet.

Nous avons eu un problème similaire, où global.asax.cs était ignoré.

Il s'avère que le site a été mis à niveau d'un site Web .NET 2 précompilé vers un site .NET 4.0. Sur le serveur, le PrecompiledApp.configfichier n'a pas été supprimé du dossier racine. Après l'avoir supprimé, recyclé le pool d'applications IIS et touché web.config pour redémarrer l'application, le code de Global.asax.cs a commencé à fonctionner correctement.

J'ai eu un problème une fois où Global.asax et Global.asax.cs n'étaient pas réellement copiés dans le dossier IIS par les scripts de déploiement ... Cela fonctionnait donc lors du débogage sur le serveur de développement, mais pas sous IIS.

Une entrée tardive ...

Pour tester si l'application IIS démarre ou non avant que le débogueur n'ait eu suffisamment de temps pour l'attacher, ajoutez-le simplement en haut ou en bas de votre GLOBAL.ASAX Application_Start.

throw new ApplicationException("Yup, it fired");

Lorsque vous dites «débogage», voulez-vous dire lancer réellement l'application à partir du serveur Web intégré de Visual Studio pour le débogage, ou voulez-vous dire attacher au processus dans IIS? Si c'est le premier, vous devriez frapper Application_Start, mais si c'est le dernier, il peut être difficile d'être sur le processus assez tôt pour l'attraper.

Fermez Visual Studio et supprimez les dossiers binet objdans votre projet Web (ou tous les projets de la solution).

Voici les commandes pour supprimer ces dossiers de tous vos projets:

rm *\bin -r
rm *\obj -r

J'avais apporté quelques modifications basées sur "l'analyse du code lors de la construction" de Visual Studio. L'analyse de code a suggéré "CA1822 Marquer les membres comme statiques" pour Application_Start () dans Global.asax. Je l'ai fait et je me suis retrouvé avec ce problème.

Je suggère de supprimer ce message d'analyse du code et de ne pas modifier la signature des méthodes / classes créées automatiquement par la plate-forme utilisée pour le démarrage de l'application. La signature de la méthode Application_Start était probablement non statique pour une raison.

Je suis revenu à cette méthode-signature et Application_Start () se déclenchait à nouveau:

    protected void Application_Start()
    { ... }

J'ai rencontré ce problème lors de l'utilisation d'une page statique (par exemple, index.html) comme page de démarrage - Application-Start n'est pas appelée. J'ai découvert que le service d'une page statique ne démarre pas réellement l'application. Demander une page .aspx fait.

Assurez-vous que les espaces de noms dans Global.asax et Global.asax.cs sont identiques. S'ils sont différents, il ne lèvera aucune erreur mais n'atteindra pas le point d'arrêt car il n'exécute pas du tout application_start.

Je pense que l'événement de démarrage de l'application n'est déclenché que lorsque la première demande est faite, accédez-vous à votre site Web (c'est-à-dire en faisant une demande)?

J'ai eu ce problème dans un projet de formulaires Web .net 4 vs2010 et j'ai essayé tout ce qui est mentionné sur cette page. J'ai fini par supprimer et ajouter global.asax a en fait résolu le problème pour moi.

J'ai le même problème, je n'ai pas pu attraper Application_Start. Et la raison était qu'il ne tirait pas pour une erreur de correspondance dans le fichier de balisage. Le fichier de balisage Global.asax héritait d'une autre classe ...

Avez-vous vérifié les paramètres du projet? J'ai eu ce problème et j'ai eu l'URL de début allant à un port différent de celui de mon port spécifique de serveur. Il m'a fallu trop de temps pour comprendre ...

Après avoir essayé autant d'autres réponses que possible dans ma situation et n'avoir eu aucune chance avec l'une d'entre elles, je suis allé dans les propriétés du projet Web (le projet côté serveur pour une application Silverlight utilisant les services RIA), j'ai cliqué sur le Onglet "Web" et a changé le serveur sélectionné de "IIS local" à "IIS Express". (Notez que j'utilise VS2013.) Cela a résolu le problème. Application_Start s'exécute sous «IIS Express» mais pas sous «IIS local». Intéressant...

J'essayais de parcourir le code dans RegisterRoutes () appelé depuis le démarrage de l'application et de ne pas toucher mon point d'arrêt. J'ai déterminé que Application_Start n'était pas appelé. J'ai dû faire une modification pour apporter une modification superficielle à App_start / RouteConfig.cs et l'enregistrer avant que Application_Start ne soit appelée. Je suppose que ces fichiers sont mis en cache quelque part et ne sont appelés que si une modification est apportée.

Mon même problème a été résolu en ajoutant une référence d' System.Web.Routingassemblage dans le projet

Si vous utilisez System.Diagnostics.Debugger.Break (); solution de contournement (qui, je pense, est très bien pour une utilisation temporaire) et "ne fonctionne tout simplement pas" sur votre machine Windows 8. La raison est un bogue dans le "Débogage juste à temps" de Visual Studio.

Le correctif est le suivant pour corriger la clé du «débogueur juste à temps de Visual Studio»

Ouvrez regedit et accédez à HKEY_CLASSES_ROOT \ AppID {E62A7A31-6025-408E-87F6-81AEB0DC9347} pour la valeur de registre 'AppIDFlags', définissez l'indicateur sur 0x8

Plus d'informations ici: http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

Dans mon cas, la suppression de l'instance de serveur de développement ASP.NET intégrée via la barre d'état système a résolu le problème.

Des trucs bizarres et fous ... mais le débogage sur une machine serveur et un autre utilisateur ont laissé IIS Express s'exécuter sur leur session. J'ai dû déconnecter cet utilisateur pour tuer ses processus IIS Express en cours d'exécution. Cela semble avoir résolu le problème!

Mettre à jour

Après avoir passé plus d'une heure à rechercher ce qui causait le problème ... voici l'affaire: j'ai un peu réussi à taper un sà l'intérieur de la <appSettings>section Web.config. Visual Studio a essayé de m'avertir dans la Error Listfenêtre avec un avertissement . J'avoue que je vérifie rarement les avertissements ... devrait commencer à le vérifier à partir de maintenant. : D Dès que j'ai supprimé sle point d'arrêt, le point d'arrêt a été touché Application_Start.

J'ai eu ce problème en essayant d'initialiser log4net. J'ai décidé de simplement créer un constructeur statique pour le Global.asax

static Global(){
//Do your initialization here statically
}

Le problème se produit principalement lorsque vous essayez de déplacer le fichier Global.asax vers un autre répertoire de solution. Replacez le fichier Global.asax dans l'emplacement par défaut. Cela fonctionnera comme prévu.

Aucune des solutions décrites ci-dessus n'a fonctionné pour moi. Cependant réinstaller le package

Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

utiliser nuget gui est un (pas trop beau) walkaround