50 Stimmen

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

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

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

Wenn ich die Anwendung starte, wird mein Haltepunkt kurzzeitig zu einem roten Kreis mit einem Ausrufezeichen darin, dann wird er wieder zu einem regulären Haltepunkt, dann startet die Anwendung, ohne jemals an meinem Haltepunkt anzuhalten.

MSDN sagt mir, dass dieses Symbol bedeutet "Der Haltepunktspeicherort wurde nicht geladen". Wie kann ich den Haltepunktspeicherort laden lassen? Es hat vor ein paar Wochen noch funktioniert. Welche Arten von Dingen könnten dazu führen, dass ein Haltepunkt "nicht geladen" wird?

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

Zusatz:

Ich kann das Debugging immer noch nicht durch Drücken von F5 zum Laufen bringen, aber ich kann die Website starten und dann debug/attach-process ausführen, um in den Debugging-Modus zu gelangen. Wenn jemand weiß, warum dies funktionieren würde, während es nicht funktioniert, wenn ich F5 drücke (die Debugging-Schaltflächen werden auf F5 nicht einmal angezeigt), sind alle Ideen willkommen.

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.)

55voto

Vilx- Punkte 100739

Versuchen Sie, einen vollständigen Neubau der Anwendung durchzuführen. Achten Sie darauf, dass es sich um die "Debug"-Konfiguration handelt.

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

0 Stimmen

Ich habe alle .pdb-Dateien im ../debug/bin gelöscht, aber das hat nicht geholfen.

3 Stimmen

Löschen ist nicht das Ding. Du musst sie neu erstellen. Hast du versucht, "Lösung neu erstellen" in Visual Studio?

3 Stimmen

Narr von mir, ich hatte die Build-Option auf Veröffentlichen, nicht Debuggen!

17voto

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

Visual Studio ist manchmal verwirrt und legt 2.0-Managed-Code automatisch als 4.0-Managed-Code fest.

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.

Grüße

0 Stimmen

Nun, was weißt du. Dies hat tatsächlich bei mir funktioniert. =) Danke Mann! (+1)

0 Stimmen

@Augusto Mazzoni Pierzynski Es wird nur Code in CS-Dateien ausgeführt und nicht der Javascript-Code. Im Fenster „Code-Typ auswählen“ habe ich versucht, sowohl „Managed (4.0)“ als auch „Script“ zu aktivieren, jedoch erlaubt Visual Studio dies nicht. Es heißt: „Skript-Debugging ist nicht kompatibel mit Managed (v4.0). Möchten Sie „Managed (v4.0)“ deaktivieren?“ Hast du eine Idee, wie man das Problem lösen kann?

0 Stimmen

Vielen Dank! Das war ein Problem für mich. Ich denke aufgrund der Fehlkonfigurationen in den Projekten konnte der Debugger nicht korrekt den richtigen Code-Typ bestimmen, bis ich manuell die .NET-Version UND den zusätzlichen "Managed Compatibility Mode" ausgewählt habe.

6voto

madhusudhan.K Punkte 61

VS Debug Problem mit IE8

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

Ich habe das gleiche Problem bereits 4 Mal beantwortet, daher hoffe ich, dass jemand diesen Beitrag als sehr hilfreich empfinden wird, wenn er mit dem gleichen Problem konfrontiert ist.

Wie könnte der VS-Debugger mit IE8 abstürzen?

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 Unterbrechungspunkte ignoriert!

Warum passiert das?

IE 8 verfügt über ein Feature namens Loosely-Coupled Internet Explorer (LCIE), das dazu führt, dass IE in mehreren Prozessen ausgeführt wird. http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

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

Um dieses Problem zu überwinden, müssen Sie das Prozesswachstumsfeature 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 namens TabProcGrowth hinzu 4) Setzen Sie TabProcGrowth auf 0

Wenn Sie dasselbe Problem auf Vista oder neuer haben, müssen Sie auch den geschützten Modus deaktivieren.

Und dann beginnen Sie mit dem Debuggen Ihres Codes :)

5voto

Jonathan Parker Punkte 6551

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-Dateien. Wenn Sie Probleme beim Löschen einiger dieser Dateien haben, könnte eine Version von Visual Studio oder sein 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 kompletten Neuaufbau auf Lösungsebene durch
  8. Drücken Sie F5

1 Stimmen

Ich habe alles auf dieser Liste gemacht (obwohl ich lokal kein IIS ausgeführt habe, sondern den localhost/port-Webserver), aber ich habe immer noch das Problem. Ich habe alle .pdb-Dateien gelöscht, keine Änderung. Die Build-Konfiguration für alle Projekte ist "Debug".

0 Stimmen

Vielleicht versuche es dann unter IIS auszuführen.

1 Stimmen

Das hat für mich funktioniert, obwohl der Ordner v4.0 anstelle von V2.0 war.

4voto

Jay Riggs Punkte 52013

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:

  1. Präzisionsgelenkte Raketen verwenden: Löschen Sie die .pdb-Dateien in Ihren Objekt- und Bin-Ordnern. Neu kompilieren. Ausführen.

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

  3. 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.

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

  5. Windows-Magie: Fahren Sie Ihren Computer herunter und starten Sie neu. 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 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

  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 Version von VS.Net, die Sie verwenden).

  9. Projekteigenschaften #2: Stellen Sie sicher, dass die Projekt Eigenschaften --> Konfigurationseigenschaften --> Build --> "Generieren von Debug-Informationen" auf "True" gesetzt ist.

  10. 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ü.

  11. 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.

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

  13. @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.

  14. 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:

  1. 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.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X