Warum würde der Debugger nicht an einem Haltepunkt in meiner ASP.NET-Anwendung anhalten?

Question

Ich versuche, eine große ASP.NET-Anwendung zu debuggen.

Ich habe einen Breakpoint in der ersten Zeile von Page_Load in Default.aspx.cs gesetzt.

Wenn ich die Anwendung starte, wird mein Breakpoint kurz zu einem roten runden Umriss mit einem Ausrufezeichen darin, verwandelt sich dann wieder in einen regulären Breakpoint, und dann startet die Anwendung, ohne jemals an meinem Breakpoint anzuhalten.

MSDN sagt mir, dass dieses Symbol bedeutet "der Breakpoint-Standort wurde nicht geladen". Also, wie kann ich den Breakpoint-Standort laden lassen? Es hat vor ein paar Wochen funktioniert. Welche Arten von Dingen könnten dazu führen, dass ein Breakpoint "nicht geladen" wird?

Was kann ich tun, damit der Debugger wieder an meinen Breakpoints anhält?

Zusatz:

Ich kann das Debuggen immer noch nicht starten, indem ich F5 drücke, aber ich kann die Website starten und dann Debug/Anfügen-Prozess verwenden, um in den Debugmodus zu gelangen. Wenn jemand weiß, warum dies funktioniert, aber wenn ich F5 drücke es nicht funktioniert (die Debugging-Schaltflächen werden nicht einmal angezeigt, wenn ich F5 drücke), wären alle Ideen willkommen.

Answer 1

Versuchen Sie, ein vollständiges Rebuild der Anwendung durchzuführen. Achten Sie darauf, dass es sich um die Konfiguration "Debug" handelt.

Soweit ich verstehe (aber ich bin kein Experte in diesen Dingen), kann dies passieren, wenn die Debug-Informationen-Dateien (.PDB) nicht mit dem tatsächlich kompilierten Element synchron sind.

Answer 2

Leute.... Ich habe eine andere Lösung für den Breakpoint gefunden, der nicht stoppt. Im Fenster "An Prozess anhängen" in Visual Studio 2010 und unter Verwendung des Frameworks 3.5 wird standardmäßig automatisch die zu debuggenden Code-Typen (v2.0, v1.1, v1.0) und (v4.0) bestimmt.

Manchmal bringt Visual Studio durcheinander und bestimmt 2.0 verwalteten Code automatisch als 4.0 verwalteten Code.

In diesem Fall müssen Sie auf die Schaltfläche "Auswählen..." im Feld "Anhängen an" klicken und "Verwalten (v2.0, v1.1, v1.0)" auswählen.

Mit freundlichen Grüßen

Answer 3

VS Debug Problem mit IE8

Da dies mein erster Beitrag auf Weblogs ist, habe ich mich entschieden, über ein Problem zu schreiben, das im ASP.NET offiziellen Forum häufig aufgetreten ist - der VS-Debugger stürzt mit IE8 ab.

Ich hatte das gleiche Problem bereits 4 Mal beantwortet, deshalb hoffe ich, dass jemand diesen Beitrag sehr hilfreich findet, wenn er auf das gleiche Problem stößt.

Wie kann es sein, dass der VS-Debugger mit IE8 abstürzt?

Wenn Sie mehrere Instanzen von IE8 geöffnet haben und versuchen, Ihr Projekt zu debuggen, treten Sie höchstwahrscheinlich auf das Problem, dass der VS-Debugger einfach stoppt und Ihre Breakpoints ignoriert!

Warum passiert das?

IE 8 hat eine Funktion namens Loosely-Coupled Internet Explorer (LCIE), die dazu führt, dass IE in mehreren Prozessen läuft. http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

Ältere Versionen des Visual Studio Debugger sind davon irritiert und können nicht herausfinden, wie sie sich am richtigen Prozess anhängen sollen.

Um dieses Problem zu überwinden, müssen Sie die Prozesswachstumsfunktion von LCIE deaktivieren, indem Sie die folgenden Schritte befolgen:

1) RegEdit öffnen 2) Navigieren Sie zu HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main 3) Fügen Sie unter diesem Schlüssel ein DWORD mit dem Namen TabProcGrowth hinzu 4) Setzen Sie TabProcGrowth auf 0

Wenn Sie auf dem gleichen Problem auf Vista oder neuer stoßen, müssen Sie auch den geschützten Modus ausschalten.

Und dann können Sie mit dem Debuggen Ihres Codes beginnen :)

Answer 4

Sie könnten auch Folgendes versuchen:

1. Schließen Sie die Lösung und Visual Studio.
2. Führen Sie iisreset /stop aus
3. Löschen Sie alles unter C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET Files. Wenn Sie Probleme beim Löschen einiger dieser Dateien haben, könnte eine Version von Visual Studio oder dessen Debugger noch ausgeführt werden.
4. Führen Sie iisreset /start aus
5. Öffnen Sie die Lösung in VS
6. Setzen Sie den Build auf Debug
7. Führen Sie einen vollständigen Neuaufbau auf der Lösungsebene durch
8. Drücken Sie F5

Answer 5

Wenn Sie Visual Studio 2005 und IE8 verwenden, könnte ich eine Erklärung haben: IE8 hat eine neue Funktion namens Loosely-Coupled IE (LCIE) eingeführt, die bekannte Probleme beim Debuggen von VS2005 ASP.NET-Anwendungen verursacht. Sehen Sie sich diesen Thread auf SO für weitere Details und einige Lösungen an.

Es stellte sich heraus, dass all meine Debugging-Probleme verschwanden, als ich alle laufenden Instanzen von IE8 heruntergefahren habe, bevor ich einen Debugging-Lauf in meinem ASP.NET-Projekt gestartet habe.

Ein weiterer Grund, warum ich hier poste, ist, einen Blog zu teilen, den ich gefunden habe, der eine Vielzahl von potenziellen Lösungen für das Problem 'Breakpoints funktionieren nicht' auflistet. Es ist nett, weil der Blog die meisten Lösungen an einem Ort auflistet, die ich im Internet verstreut gefunden habe. So oder so, der Autor des Blogs ist George P. Alexander; ich werde die interessanten Teile hier kopieren und einfügen, falls etwas mit dem Artikel passiert:

1. Verwendung von präzisionsgesteuerten Raketen: Löschen Sie die .pdb-Dateien in Ihren Obj- und Bin-Ordnern. Neu kompilieren. Ausführen.

2. Alle .dlls ausbomben: Löschen und neu laden Sie alle referenzierten .dlls (wie Ihre Klassenprojekte)

3. Einsatz einer Massenvernichtungswaffe: Wenn Punkt #1 und #2 nicht funktionierten, löschen Sie die Inhalte der Obj- und Bin-Ordner selbst, sodass alle .pdbs und .dlls vernichtet werden. Laden Sie die erforderlichen .dlls erneut und probieren Sie es aus.

4. VS.Net-Zauber: VS.Net schließen und neu starten. Neu erstellen. Ausführen. Ja, manchmal funktioniert es.

5. Windows-Zauber: Ihren Computer herunterfahren und neu starten. Neu erstellen. Ausführen.

6. Ausführungsmodus: Stellen Sie sicher, dass der Ausführungsmodus von VS.Net auf "Debug" und nicht auf "Release" eingestellt ist.

7. Web.config-Einstellungen: Stellen Sie sicher, dass das XML-Element "compilation" in Ihrer Web.config-Datei über ein Attribut mit debug = "true" verfügt. Nur wenn dies aktiviert ist, werden Webanwendungen und Dienste ihre .pdb-Dateien mit den .dlls generieren.

8. Projekteigenschaften #1: Stellen Sie sicher, dass Projekt Eigenschaften --> Debug --> Aktivieren von "ASP.Net-Debugging ist true" oder "Aktivieren des Visual Studio-Hosting-Prozesses" (je nach der Version von VS.Net, die Sie verwenden) aktiviert ist.

9. Projekteigenschaften #2: Stellen Sie sicher, dass Projekt Eigenschaften --> Konfigurationseigenschaften --> Erstellen --> "Debugging-Informationen generieren" auf "True" eingestellt ist.

10. Falscher Prozess angehängt: Möglicherweise ist Ihre Debugging-Session nicht am richtigen Prozess angehängt. Möglicherweise müssen Sie manuell den Prozess anhängen. Dies ist bei Webdiensten möglich. Die Option, einen Prozess anzuhängen, befindet sich im Debug-Menü.

11. Skript- und nicht verwalteter Code-Debugging: Können Sie Skripte oder nicht verwalteten Code nicht debuggen? Stellen Sie sicher, dass Projekt Eigenschaften --> Debug --> "ASP-Debugging aktivieren" oder "Nicht verwaltetes Debugging aktivieren" (je nach Ihrer Version von VS.Net) auf true eingestellt ist.

12. @Page-Direktive #1: Stellen Sie sicher, dass das Attribut AutoEventWireup in Ihrer .aspx-Dokumenten-@Page-Direktive auf "true" eingestellt ist.

13. @Page-Direktive #2: Stellen Sie sicher, dass das Attribut Debug in Ihrer .aspx-Dokumenten-@Page-Direktive auf "true" eingestellt ist. Wenn Sie das Attribut nicht finden, ist das in Ordnung. Standardmäßig ist es true.

14. Rogue .DLLs: Stellen Sie sicher, dass Sie keine andere Instanz der .dll laufen haben, die sich an einem anderen Ort als dem beabsichtigten Projektordner befindet.

14.1 Rogue .dlls Schläferzelle #1: Haben Sie Ihre Projekt .dll im GAC-Ordner installiert? Möglicherweise führen Sie die .dll aus Ihrem GAC-Ordner aus, anstelle derjenigen aus Ihrem Bin-Ordner. Entfernen/Deinstallieren Sie die .dll aus dem GAC und versuchen Sie es erneut.

14.2 Rogue .DLLs Schläferzelle #2:

C:\Dokumente und Einstellungen[Benutzername]\VSWebCache[Rechnername]:

Führen Sie eine Massenvernichtungswaffe (#3) auf den Ordnern aus, die mit Ihrem Projekt zusammenhängen.

14.3 Rogue DLLs Schläferzelle #3: .dlls aus Ihrem Projekt, die an einem anderen Ort liegen, aber stattdessen in Ihrem Projekt referenziert sind. Sie können dies herausfinden, indem Sie die Projekteigenschaften untersuchen. Kurz gesagt, VS.Net verweist auf eine andere .dll und nicht auf die in Ihrer Entwicklungs Umgebung geladene .dll.

14.4 Rogue .DLLs Schläferzelle #4: Hoffentlich müssen Sie nicht mit diesem Ordner spielen, wenn Sie mit den obigen Punkten fertig sind...

Vorstellung von C:\WINDOWS\Microsoft.NET\Framework[.Net-Version]\Temporary ASP.NET-Dateien\

Dieser Ordner könnte ältere Versionen von .dlls enthalten, die in Ihrem Windows-Ordner gespeichert sind und beim Ausführen von VS.Net referenziert werden könnten. Wenn dies passiert, ist es ärgerlich. Sie können so viele Ordner und Inhalte löschen, WIE SIE IHREM PROJEKT ANGEHÖREN. Es könnten schreibgeschützte Sperren vorhanden sein, die Sie deaktivieren müssen, indem Sie Prozesse schließen. Das ist eher ein letzter Ausweg. Tun Sie dies nicht, wenn Sie noch nie mit Ihrem Windows-Ordner herumgespielt haben. In den meisten Fällen hilft etwas, das vor diesem Punkt getan wird, die Probleme zu beheben. Idealerweise müssen Sie diesen Punkt nicht mehr lesen, wenn Sie mit den obigen Hinweisen fertig sind. Und nur zur Sicherheit: Ich empfehle niemandem, diese Option zu erkunden oder in Ihrem Windows-Ordner herumzuspielen, wenn Sie keinen Doktortitel in Physik, Mathematik, Windows und .Net haben.

Andere Tipps:

1. Modul-Fenster: Das Modul-Fenster kann angesehen werden, während Ihre Anwendung von VS.Net ausgeführt wird (Debug --> Windows --> Module). Alle Module Ihres Projekts sollten dort aufgeführt sein. Wenn die .dll Ihres Projekts aufgelistet ist und der Status der Symbole "Symbole geladen" ist, haben Sie kein Problem.

Wenn es sich um eine Nachricht handelt, die sich auf Ihre .pdb-Datei bezieht, gehen Sie zu "Symbole auswählen" und wählen Sie die entsprechende .pdb-Datei aus. Sie müssen möglicherweise das Debugging neu starten oder VS.Net erneut laden. Der Status sollte jetzt auf "Symbole geladen" geändert werden.
2. VS.Net-Optionen: Werkzeug --> Optionen --> Debuggen In VS.Net ab 2005 gibt es einen weiteren Knoten namens "Symbole", in dem Sie VS.Net bitten können, nach Symbolen zu suchen. Dies kann auch über das Modul-Fenster beim Debuggen erfolgen.