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 alle meine Debugging-Probleme verschwanden, als ich vor dem Start eines Debugging-Laufs in meinem ASP.NET-Projekt alle laufenden Instanzen von IE8 schloss.
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 gefunden habe. Wie auch immer, der Autor des Blogs ist George P. Alexander; ich werde die interessanten Teile hier kopieren und einfügen, falls etwas mit dem Artikel passiert:
-
Präzisionsgeführte Raketen verwenden: Löschen Sie die .pdb-Dateien in Ihren Objekt- und Bin-Ordnern. Neu kompilieren. Ausführen.
-
Alle .dlls mit einem Flächenbombardement zerstören: Löschen und neu laden Sie alle referenzierten .dlls (wie Ihre Klassenprojekte)
-
Einen Massenvernichtungswaffen einsetzen: Wenn #1 & #2 nicht funktionierten, löschen Sie den Inhalt der betreffenden Objekt- und Bin-Ordner, so dass alle .pdb- und .dll-Dateien vernichtet sind. Laden Sie die benötigten .dlls neu und versuchen Sie es erneut.
-
VS.Net-Magie: VS.Net schließen und neu starten. Neu erstellen. Ausführen. Ja, manchmal funktioniert es.
-
Windows-Magie: Schalten Sie Ihren Computer aus und neu starten. Neu erstellen. Ausführen.
-
Ausführungsmodus: Stellen Sie sicher, dass der Ausführungsmodus von VS.Net auf "Debuggen" und nicht auf "Veröffentlichen" eingestellt ist
-
Web.config-Einstellungen: Stellen Sie sicher, dass das XML-Element "compilation"tag in Ihrer web.config-Datei ein Attribut mit debug = "true" hat. Nur wenn dies aktiviert ist, werden für Webanwendungen und -dienste ihre .pdb-Dateien zusammen mit den .dlls generiert
-
Projekteigenschaften #1: Stellen Sie sicher, dass Projekteigenschaften --> Debuggen --> Aktivieren Sie "ASP.Net-Debugging ist aktiviert" oder "Aktivieren Sie den Visual Studio-Hosting-Prozess" (je nach der Version von VS.Net, die Sie verwenden).
-
Projekteigenschaften #2: Stellen Sie sicher, dass Projekteigenschaften --> Konfigurationseigenschaften --> Erstellen --> "Debuginformation generieren" auf "True" eingestellt ist.
-
Falscher Prozess angehängt: Ihre Debugging-Sitzung ist möglicherweise nicht an den richtigen Prozess angehängt. Sie müssen möglicherweise manuell den Prozess anhängen. Dies ist bei Webdiensten möglich. Die Option zum Anhängen eines Prozesses befindet sich im Debug-Menü.
-
Skript- und nicht verwalteten Code debuggen: Können Sie Skripte oder nicht verwalteten Code nicht debuggen? Stellen Sie sicher, dass in den Projekteigenschaften --> Debuggen --> "ASP-Debugging aktivieren" oder "Nicht verwaltete Fehlersuche aktivieren" (abhängig von Ihrer Version von VS.Net) auf "True" festgelegt ist.
-
@Page-Direktive #1: Stellen Sie sicher, dass das Attribut AutoEventWireup in Ihrer .aspx-Dokuments @Page-Direktive auf "True" gesetzt ist.
-
@Page-Direktive #2: Stellen Sie sicher, dass das Attribut Debug in Ihrem .aspx Dokuments @Page-Direktive auf "True" gesetzt ist. Wenn Sie das Attribut nicht finden, ist das in Ordnung. Standardmäßig ist es true.
-
Feindliche .DLLs: Stellen Sie sicher, dass Sie keine andere Instanz der .dll am Laufen haben, die sich an einem anderen Ort als Ihrem beabsichtigten Projekt befindet.
14.1 Feindliche .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, anstatt derjenigen in Ihrem Bin-Ordner. Entfernen/Deinstallieren Sie die .dll aus dem GAC und versuchen Sie es erneut.
14.2 Feindliche .DLLs Schläferzelle #2:
C: \ Dokumente und Einstellungen[Benutzername]\VSWebCache[Computernamen]:
Setzen Sie eine Massenvernichtungswaffe (#3) auf die Ordner, die mit Ihrem Projekt zusammenhängen.
14.3 Feindliche .DLLs Schläferzelle #3: .dlls Ihres Projekts, die an einem anderen Ort liegen aber in Ihrem Projekt referenziert werden. Diese können durch Überprüfen der Projekteigenschaften gefunden werden. Kurz gesagt, VS.Net verweist auf eine andere .dll und nicht auf die in Ihrer Entwicklungs Umgebung geladene.
14.4 Feindliche .DLLs Schläferzelle #4: Hoffentlich müssen Sie sich nicht mit diesem Ordner beschäftigen, wenn Sie mit den obigen Punkten fertig sind...
Introducing 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önnen. Wenn dies passiert, ist das ärgerlich. Löschen Sie alle Ordner und Inhalte im Zusammenhang mit IHREM PROJEKT. Es könnten schreibgeschützte Sperren vorliegen, die Sie durch das Schließen von Prozessen deaktivieren müssen. Dies ist eher ein letzter Ausweg. Tun Sie dies nicht, wenn Sie noch nie mit Ihrem Windows-Ordner herumgespielt haben. In den meisten Fällen wird damit etwas getan, was vor diesem Punkt üblicherweise das Problem behebt. Idealerweise sollten Sie diesen Punkt nicht erreichen müssen, wenn Sie mit den oben genannten Punkten fertig sind. Und nur zur Aufzeichnung: Ich empfehle niemandem, diese Option zu erkunden oder an Ihrem Windows-Ordner herumzuspielen, wenn Sie keinen Doktortitel in Physik, Mathematik, Windows und .Net haben.
Weitere Tipps:
- Modulfenster: Das Modulfenster kann während der Ausführung Ihrer Anwendung von VS.Net aus angezeigt werden (Debug --> Fenster --> Module). Alle Module Ihres Projekts sollten dort aufgelistet sein. Wenn die .dll Ihres Projekts aufgeführt 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. Möglicherweise müssen Sie das Debuggen neu starten oder VS.Net erneut laden. Der Status sollte sich jetzt zu "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 zugegriffen werden.
0 Stimmen
In meinem Fall läuft dieselbe ASP.NET App auf mehreren Domains und verwendet die Domain aus der Anfrage, um den Inhalt zu wählen, der bereitgestellt werden soll. Es ist so eingestellt, dass es auf dem lokalen IIS läuft und über die hosts-Datei die Domains auf 127.0.0.1 aufgelöst werden. Die App lief einwandfrei, aber der Debugger hielt nicht an den Haltepunkten an, bis ich die Projekteigenschaften > Web > Server > Projekt-URL auf die Domain gesetzt habe, die für die Anfrage verwendet wird. (Es enthielt eine andere Domain, unter der die App verfügbar ist.)