Application_Start wird nicht ausgelöst?

Ich habe eine ASP.NET MVC (Beta) -Anwendung, an der ich arbeite, und habe Probleme herauszufinden, ob ich etwas falsch mache oder ob meine Application_StartMethode in Global.asax.cs tatsächlich nicht ausgelöst wird, wenn ich es versuche um die Anwendung zu debuggen.

Ich habe in meiner Application_StartMethode einen Haltepunkt in eine Zeile eingefügt und erwarte, dass beim Versuch, die Anwendung zu debuggen, der Haltepunkt erreicht wird ... aber das tut er nie. Nicht nach dem Zurücksetzen von IIS, nicht nach dem Neustart, niemals. Vermisse ich etwas Warum wird diese Methode nie aufgerufen?

Wenn dies in IIS ist, kann die App gestartet werden, bevor der Debugger angehängt wurde. Wenn ja, bin ich mir nicht sicher, ob Sie lange genug schlafen können, um sich zu verbinden.

In Visual Studio können Sie den Debugger an einen Prozess anhängen. Klicken Sie dazu auf Debug >> An Prozess anhängen. Stellen Sie eine Verbindung zum Browser her und klicken Sie dann auf Ihre Anwendung. Starten Sie aus Sicherheitsgründen IIS neu und rufen Sie die Site auf. Ich bin nicht zu 100% davon überzeugt, dass dies das Problem lösen wird, aber es wird viel besser funktionieren, als einen Thread-Schlaf in App_Start auszulösen.

Eine weitere Option ist das vorübergehende Hosten auf dem integrierten Webserver, bis Sie den Start der Debugging-Anwendung abgeschlossen haben.

Hinweis: Eine gute und einfache Alternative zur Verwendung des integrierten "Visual Studio Development Server" oder von IIS Express (z. B. weil Sie gegen IIS entwickeln und bestimmte Einstellungen haben, die Sie für das ordnungsgemäße Funktionieren Ihrer App benötigen) besteht darin, die Ausführung in IIS (I) einfach fortzusetzen Verwenden Sie den benutzerdefinierten Webserver + Hosts-Dateieintrag + IIS-Bindung an dieselbe Domäne.

1. Warten Sie, bis die Debugging-Sitzung gestartet ist
2. Nehmen Sie dann einfach eine Whitespace-Bearbeitung in der Root-Datei web.config vor und speichern Sie die Datei
3. Aktualisieren Sie Ihre Seite (Strg + F5)

Ihr Haltepunkt sollte gut getroffen werden, und Sie können weiterhin in Ihrem natürlichen IIS-Lebensraum debuggen . Toll !

Folgendes hilft auf jeden Fall (egal ob Sie IIS, Cassini oder was auch immer verwenden):

1. Legen Sie Ihren Haltepunkt in Application_Start fest
2. Starten Sie das Debuggen (Haltepunkt wird höchstwahrscheinlich nicht erreicht) -> Eine Seite wird im Browser angezeigt
3. Ändern Sie web.config (z. B. geben Sie eine leere Zeile ein) und speichern Sie sie
4. Laden Sie die Seite im Browser neu -> Haltepunkt ist erreicht!

Warum funktioniert das? Wenn web.config geändert wird, führt der Webserver (IIS, Cassini usw.) eine Wiederverwertung durch. In diesem Fall (aus welchem ​​Grund auch immer) bleibt der Prozess unverändert, sodass Sie mit dem Debugger (Visual Studio) an ihn gebunden bleiben ).

Ich habe auch Probleme mit Haltepunkten in application_start mit IIS, einer gehosteten App. Eine gute Problemumgehung ist die Verwendung von Debugger.Break (); im Code anstelle des VS-Haltepunkts

Ich habe genau das gleiche Problem. Ich habe in meiner Lösung viel umbenannt. Danach bekam ich zwei nicht funktionierende Webanwendungen und mehrere andere Webanwendungen waren in Ordnung. Ich habe die Fehlermeldung erhalten, dass ich falsche Routen habe. Wenn ich versucht habe, den Haltepunkt in der Application_StartMethode einzurichten und dann IIS neu zu starten, hat VS die Ausführung nicht unterbrochen. Mit funktionsfähigen Webanwendungen funktionierte Pause. Dann habe ich daran erinnert, dass "saubere Lösung" und "neu erstellen" keine Assemblys löschen, die nach dem Umbenennen übrig geblieben sind. Und das war Lösung! Ich habe die binVerzeichnisse meiner Buggy-Webanwendungen manuell bereinigt und dann festgestellt, dass auf einen neuen Fehler im Global.asax Inherits=""Attribut verwiesen wurde. Ich habe es auf neu geändert und Pause begann zu arbeiten. Angenommen, während des Umbenennens wurde Global.asax nicht aktualisiert.

Hatte das gleiche Problem in einem Projekt, das wir übernommen hatten, nachdem ein anderer Anbieter es erstellt hatte. Das Problem war, dass zwar eine Reihe von Befehlen des vorherigen Anbieters in Global.asax.cs geschrieben wurden, die Sie möglicherweise zu der Annahme veranlassen, dass sie verwendet werden, sie jedoch tatsächlich vollständig ignoriert wurden. Global.asax hat nicht davon geerbt, und es ist einfach, diese Datei nie zu sehen, wenn die CS-Datei vorhanden ist. Sie müssen mit der rechten Maustaste auf Global.asax klicken und auf Markup anzeigen klicken, um sie tatsächlich anzuzeigen.

Global.asax:

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

Musste geändert werden zu:

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

Wobei ProjectNamespace der Namespace Ihrer Global.asax.cs-Klasse ist (normalerweise der Name Ihres Projekts).

In unserem Fall enthielt die Datei eine Reihe von Inline-Code, von denen einige aus der CS-Datei kopiert wurden, andere nicht. Wir haben den Inline-Code einfach in die CS-Datei kopiert und unsere Änderungen nach und nach wieder zusammengeführt.

Versuchen Sie, den verwalteten Pipeline-Modus für den App-Pool auf "Klassisch" anstatt auf "Integriert" umzustellen. Das hat das Problem für mich gelöst. Jetzt den Grund untersuchen ...

(Die Requisiten für diese Antwort gehören Flores (siehe seinen Kommentar zu seiner eigenen Antwort). Ich wollte dies nur als separate Antwort bereitstellen, um mehr Aufmerksamkeit darauf zu lenken.)

Stellen Sie sicher, dass sich Ihre global.asax nicht in einem Unterverzeichnis befindet. Es muss auf Stammebene in Ihr Projekt eingefügt werden.

Wir hatten ein ähnliches Problem, bei dem global.asax.cs ignoriert wurde.

Es stellt sich heraus, dass die Site von einer vorkompilierten .NET 2-Website auf eine .NET 4.0-Site aktualisiert wurde. Auf dem Server wurde die PrecompiledApp.configDatei nicht aus dem Stammordner gelöscht. Nach dem Löschen, dem Recycling des IIS-App-Pools und dem Berühren von web.config, um die Anwendung neu zu starten, funktionierte der Code in Global.asax.cs einwandfrei.

Ich hatte einmal ein Problem, bei dem Global.asax und Global.asax.cs von den Bereitstellungsskripten nicht in den IIS-Ordner kopiert wurden. Es funktionierte also beim Debuggen auf dem Entwicklungsserver, jedoch nicht unter IIS.

Ein später Eintrag ...

Um zu testen, ob die IIS-Anwendung gestartet wird, bevor der Debugger genügend Zeit zum Anhängen hatte, fügen Sie diese einfach oben oder unten in Ihre GLOBAL.ASAX-Dateien ein Application_Start.

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

Wenn Sie "Debuggen" sagen, meinen Sie damit, dass die Anwendung tatsächlich vom integrierten Webserver von Visual Studio zum Debuggen gestartet wird, oder meinen Sie das Anhängen an den Prozess in IIS? Wenn es das erstere ist, sollten Sie Application_Start drücken, aber wenn es das letztere ist, kann es schwierig sein, früh genug im Prozess zu sein, um es zu fangen.

Schließen Sie Visual Studio und löschen Sie die Ordner binund objin Ihrem Webprojekt (oder allen Projekten in der Lösung).

Hier sind Befehle zum Löschen dieser Ordner aus all Ihren Projekten:

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

Ich hatte einige Änderungen basierend auf "Code Analysis on Build" von Visual Studio vorgenommen. Die Codeanalyse schlug "CA1822 Mitglieder als statisch markieren" für Application_Start () in Global.asax vor. Ich habe das getan und bin zu diesem Problem gekommen.

Ich empfehle, diese Code-Analyse-Nachricht zu unterdrücken und die Signatur von Methoden / Klassen, die automatisch von der Plattform erstellt werden, die zum Booten der Anwendung verwendet wird, nicht zu ändern. Die Signatur der Methode Application_Start war wahrscheinlich aus einem bestimmten Grund nicht statisch.

Ich kehrte zu dieser Methodensignatur zurück und Application_Start () wurde erneut ausgelöst:

    protected void Application_Start()
    { ... }

Ich hatte dieses Problem, als ich eine statische Seite (z. B. index.html) als Startseite verwendete - Application-Start wird nicht aufgerufen. Ich habe festgestellt, dass das Bereitstellen einer statischen Seite die Anwendung nicht startet. Das Anfordern einer ASPX-Seite funktioniert.

Stellen Sie sicher, dass die Namespaces in Global.asax und Global.asax.cs identisch sind. Wenn sie unterschiedlich sind, wird kein Fehler ausgegeben, aber der Haltepunkt wird nicht erreicht, auch weil application_start überhaupt nicht ausgeführt wird.

Ich denke, das Anwendungsstartereignis wird erst ausgelöst, wenn die erste Anfrage gestellt wird. Treffen Sie Ihre Website (dh stellen Sie eine Anfrage)?

Ich hatte dieses Problem in einem .net 4 Web Forms vs2010-Projekt und habe alles versucht, was auf dieser Seite erwähnt wird. Das Entfernen und Hinzufügen von global.asax hat das Problem für mich behoben.

Ich hatte das gleiche Problem und konnte Application_Start nicht abfangen. Und der Grund war, dass es nicht zu einem Missmatch in der Markup-Datei kam. Die Markup-Datei Global.asax hat eine andere Klasse geerbt ...

Haben Sie die Projekteinstellungen überprüft? Ich hatte dieses Problem und die Start-URL wurde an einen anderen Port als meinen serverspezifischen Port gesendet. Ich habe zu lange gebraucht, um herauszufinden ...

Nachdem ich so viele der anderen Antworten ausprobiert hatte, wie in meiner Situation zutreffend waren, und mit keiner von ihnen Glück hatte, ging ich in die Eigenschaften für das Webprojekt (das serverseitige Projekt für eine Silverlight-App mit RIA Services) und klickte auf Registerkarte "Web" und änderte den ausgewählten Server von "Local IIS" in "IIS Express". (Hinweis: Ich verwende VS2013.) Dadurch wurde das Problem behoben. Application_Start wird unter "IIS Express" ausgeführt, jedoch nicht unter "Local IIS". Interessant...

Ich habe versucht, den Code in RegisterRoutes () zu durchlaufen, der vom Start der Anwendung aufgerufen wurde, und meinen Haltepunkt nicht erreicht. Ich habe festgestellt, dass Application_Start nicht aufgerufen wurde. Ich musste eine Änderung vornehmen, um eine oberflächliche Änderung an App_start / RouteConfig.cs vorzunehmen und diese zu speichern, bevor Application_Start aufgerufen wurde. Ich denke, diese Dateien werden irgendwo zwischengespeichert und nicht aufgerufen, es sei denn, eine Änderung wird vorgenommen.

Mein Problem wurde durch Hinzufügen einer System.Web.RoutingBaugruppenreferenz im Projekt behoben

Wenn Sie System.Diagnostics.Debugger.Break () verwenden; Problemumgehung (die meiner Meinung nach für die vorübergehende Verwendung in Ordnung ist) und auf Ihrem Windows 8-Computer "funktioniert einfach nicht". Der Grund ist ein Fehler in Visual Studios "Just in Time Debugging".

Das Update lautet wie folgt: Der Schlüssel für den "Visual Studio Just-In-Time-Debugger" wird behoben.

Öffnen Sie regedit und gehen Sie zu HKEY_CLASSES_ROOT \ AppID {E62A7A31-6025-408E-87F6-81AEB0DC9347} für den Registrierungswert 'AppIDFlags'. Setzen Sie das Flag auf 0x8

Weitere Informationen finden Sie hier: http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

In meinem Fall wurde das Problem behoben, indem die integrierte ASP.NET Development Server-Instanz über die Taskleiste beendet wurde.

Seltsames und verrücktes Zeug ... aber das Debuggen auf einem Server und einem anderen Benutzer ließ IIS Express in ihrer Sitzung laufen. Ich musste diesen Benutzer abmelden, um seine laufenden IIS Express-Prozesse zu beenden. Das scheint das Problem behoben zu haben!

Aktualisieren

Nachdem ich mehr als 1 Stunde damit verbracht hatte, den Ursachen des Problems nachzujagen ... hier ist der Deal: Ich habe es etwas geschafft, einen Abschnitt in sden <appSettings>Abschnitt einzutippen Web.config. Visual Studio hat versucht, mich im Error ListFenster mit einer Warnung zu warnen . Ich gebe zu, dass ich Warnungen selten überprüfe ... sollte von nun an damit beginnen, sie zu überprüfen. : D Sobald ich die Beleidigung entfernt habe, wurde sder Haltepunkt getroffen Application_Start.

Ich hatte dieses Problem beim Versuch, log4net zu initialisieren. Ich habe mich entschieden, nur einen statischen Konstruktor für Global.asax zu erstellen

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

Das Problem tritt hauptsächlich auf, wenn Sie versuchen, die Datei Global.asax in ein anderes Lösungsverzeichnis zu verschieben. Verschieben Sie die Datei Global.asax erneut an den Standardspeicherort. Es wird wie erwartet funktionieren.

Keine der oben beschriebenen Lösungen hat bei mir funktioniert. Neuinstallation des Pakets

Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

Die Verwendung von Nuget GUI ist ein (nicht allzu schöner) Rundgang