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 bei der Fehlersuche von VS2005 ASP.NET-Anwendungen bekanntermaßen Probleme verursacht. Sehen Sie sich diesen Thread auf SOfür weitere Details und einige Lösungen an.
Es stellte sich heraus, dass alle meine Debugging-Probleme verschwanden, als ich alle laufenden Instanzen von IE8 schloss, bevor ich einen Debugging-Durchlauf in meinem ASP.NET-Projekt startete.
Ein weiterer Grund, warum ich hier poste, ist, um einen Blog zu teilen, den ich gefunden habe, der eine große Anzahl von potenziellen Lösungen für das Problem der nicht funktionierenden Breakpoints auflistet. Es ist schön, weil der Blog an einem Ort die meisten Lösungen auflistet, die ich im Internet verstreut gefunden habe. Jedenfalls ist der Autor des Blogs George P. Alexander; Ich werde die interessanten Teile hier kopieren, falls etwas mit dem Artikel passiert:
-
Präzisionsgelenkte Raketen verwenden: Löschen Sie die .pdb-Dateien in Ihren Objekt- und Bin-Ordnern. Neu kompilieren. Ausführen.
-
Alle .dlls flächenbombardieren: Löschen und neu laden Sie alle referenzierten .dlls (wie Ihre Klassenprojekte)
-
Eine Massenvernichtungswaffe einsetzen: Wenn #1 & #2 nicht funktionierten, löschen Sie die Inhalte der Objekt- und Bin-Ordner selbst, sodass alle .pdbs und .dlls vernichtet werden. Laden Sie die erforderlichen .dlls neu und versuchen Sie es erneut.
-
VS.Net-Magie: Schließen Sie VS.Net und starten Sie neu. Neu erstellen. Ausführen. Ja, manchmal funktioniert es.
-
Windows-Magie: Fahren Sie Ihren Computer herunter und starten Sie neu. Neu erstellen. Ausführen.
-
Ausführungsmodus: Stellen Sie sicher, dass der Ausführungsmodus von VS.Net auf "Debug" und nicht auf "Release" eingestellt ist
-
Web.config-Einstellungen: Stellen Sie sicher, dass das XML-Element "compilation" in Ihrer Web.config-Datei ein Attribut mit debug = "true" hat. Nur wenn dies aktiviert ist, werden für Web-Apps und -Dienste die .pdb-Dateien zusammen mit den .dlls generiert
-
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 Version von VS.Net, die Sie verwenden).
-
Projekteigenschaften #2: Stellen Sie sicher, dass die Projekt Eigenschaften --> Konfigurationseigenschaften --> Build --> "Generieren von Debug-Informationen" auf "True" gesetzt ist.
-
Falscher Prozess angehängt: Ihre Debugging-Sitzung ist möglicherweise nicht mit dem richtigen Prozess verbunden. Möglicherweise müssen Sie manuell in den Prozess eingreifen, um den Prozess anzuhängen. Dies ist bei Webdiensten möglich. Die Option zum Anhängen eines Prozesses befindet sich im Debug-Menü.
-
Skript- und unverwaltete Code-Debugging: Können Sie Skripte oder nicht verwalteten Code nicht debuggen? Stellen Sie sicher, dass Projekt Eigenschaften --> Debug --> "ASP Debuggen" oder "Unmanaged Debugging aktivieren" (je nach Ihrer VS.Net-Version) auf true gesetzt ist.
-
@Page-Direktive #1: Stellen Sie sicher, dass das Attribut AutoEventWireup in Ihrer .aspx-Dokumenten-@Page-Direktive auf "true" gesetzt ist.
-
@Page-Direktive #2: Stellen Sie sicher, dass das Attribut Debug in Ihrer .aspx-Dokumenten-@Page-Direktive auf "true" gesetzt ist. Wenn Sie das Attribut nicht finden, ist es in Ordnung. Standardmäßig ist es true.
-
Rogue .DLLs: Stellen Sie sicher, dass Sie keine weitere Instanz der .dll haben, die an einem anderen Ort als Ihrem beabsichtigten Projektordner ausgeführt wird.
14.1 Rogue .dlls Schläferzelle #1: Haben Sie Ihre Projekt .dll im GAC-Ordner installiert? Möglicherweise wird die .dll ausgeführt, die in Ihrem GAC-Ordner gehostet wird, anstelle derjenigen im 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 verbunden sind.
14.3 Rogue DLLs Schläferzelle #3: .dlls von Ihrem Projekt, die an einem anderen Ort liegen, aber stattdessen in Ihrem Projekt referenziert werden. Sie können dies herausfinden, indem Sie die Projekteigenschaften untersuchen. Kurz gesagt, VS.Net bezieht sich auf eine andere .dll und nicht auf die in Ihrer Entwicklungsumgebung geladene .dll.
14.4 Rogue .DLLs Schläferzelle #4: Hoffentlich müssen Sie mit diesem Ordner nicht spielen, wenn Sie mit den oben genannten Punkten fertig sind...
Vorstellung 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 möglicherweise beim Ausführen von VS.Net referenziert werden. Wenn dies passiert, ist das schlecht. Sie können so viele Ordner und Inhalte wie möglich, DIE SICH AUF IHR PROJEKT BEZIEHEN, löschen. Es könnten nur Lese-Sperrungen vorhanden sein, die Sie deaktivieren müssen, indem Sie Prozesse schließen. Dies ist eher ein letzter Ausweg. Tun Sie dies nicht, wenn Sie noch nie in Ihrem Windows-Ordner herumgespielt haben. In den meisten Fällen wird durch etwas, das vor diesem Punkt getan wird, das Problem in der Regel behoben. Idealerweise müssen Sie diesen Punkt nicht lesen, wenn Sie mit den obigen Punkten fertig sind. Und nur zur Erinnerung, ich empfehle niemandem, diese Option zu erkunden oder in Ihrem Windows-Ordner herumzuspielen, wenn Sie keinen Doktortitel in Physik, Mathematik, Windows und .Net haben.
Weitere Tipps:
- Modul-Fenster: Das Modul-Fenster kann während des Ausführens Ihrer Anwendung von VS.Net (Debug --> Windows --> Module) angezeigt werden. Alle Module Ihres Projekts sollten dort aufgelistet sein. Wenn die .dll Ihres Projekts aufgelistet ist und der Status der Symbole "Symbole geladen" ist, haben Sie keine Probleme.
Wenn es sich um eine Nachricht zu Ihrer .pdb-Datei handelt, gehen Sie zu "Symbole auswählen" und wählen Sie die entsprechende .pdb-Datei aus. Möglicherweise müssen Sie das Debuggen neu starten oder VS.Net erneut laden. Der Status sollte sich jetzt auf "Symbole geladen" ändern.
2. VS.Net-Optionen: Tool --> Optionen --> Debuggen In VS.Net 2005 und später gibt es einen weiteren Knoten namens "Symbole", über den Sie VS.Net bitten können, nach Symbolen zu suchen. Dies kann auch über das Modulfenster beim Debuggen erfolgen.
0 Stimmen
In meinem Fall wird dieselbe ASP.NET-App auf mehreren Domains ausgeführt und verwendet die Domain aus der Anfrage, um den Inhalt zu bestimmen. Es ist so eingestellt, dass es auf dem lokalen IIS läuft und über die Hosts-Datei die Domains in 127.0.0.1 aufgelöst werden. Die App lief gut, aber der Debugger hielt nicht an den Haltepunkten an, bis ich unter Projekteigenschaften > Web > Server > Projekt-URL die Domain festlegte, die für die Anfrage verwendet wurde. (Es enthielt eine andere Domain, unter der die App verfügbar ist.)