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

Question

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.

Answer 1

Hast du in deiner web.config festgelegt?

Answer 2

Ich hatte ein ähnliches Problem mit Breakpoints, die nicht funktionierten und gleichzeitig konnte ich in der IIS-Konsole die Konfiguration für mein Projekt nicht bearbeiten, d.h. die Schaltfläche Konfiguration bearbeiten war ausgegraut.

[Um die Schaltfläche Konfiguration bearbeiten zu finden: Start | Alle Programme | Verwaltungstools | Internet Information Services, dann den erforderlichen Computer erweitern, Web Sites erweitern, Default Web Site erweitern, Ihr Projekt suchen und mit der rechten Maustaste darauf klicken, Eigenschaften auswählen und dann den Tab ASP.Net.]

Ich habe festgestellt, dass in IIS die ASP.Net-Version für mein Projekt auf 4.0.30319 eingestellt war. Als ich sie auf 2.0.50727 geändert habe, wurde die Schaltfläche Konfiguration bearbeiten wieder verfügbar (anklickbar) und meine Breakpoints funktionierten wieder.

Ich habe auch bemerkt, dass es sich lohnen könnte, die in IIS für "Default Web Site" eingestellte ASP.Net-Version zu überprüfen [in der IIS-Konsole Web Sites erweitern, mit der rechten Maustaste auf Default Web Site klicken und Eigenschaften auswählen, dann den Tab ASP.Net], so dass neue Projekte, die in Visual Studio erstellt werden, die Einstellung der Default Web Site übernehmen.

Answer 3

Suchen Sie immer nach Lösungskonfigurationen, die als "Debug" festgelegt sind, um Debugging zu ermöglichen. Es kann nach der Veröffentlichung zur Release-Konfiguration wechseln.

Answer 4

Ich hatte kürzlich dieses Problem (WinXP, VS2003) und habe viele der oben genannten Lösungen ausprobiert, jedoch ohne Erfolg. Dann wurde mir klar, dass mehrere Versionen der .Net-Runtime installiert waren. Also habe ich IIS 5.1 geöffnet, den richtigen virtuellen Ordner gefunden, bin in die Eigenschaften gegangen und dann auf den ASP.NET-Tab und habe die ASP.NET-Version von 4.? auf 1.1 geändert, und es schien, als ob das das Problem gelöst hätte. Es könnte sein, dass die Lösung dies ist, PLUS eine oder mehrere der oben genannten Dinge.

Außerdem bilden alle oben genannten Dinge einen "Alleskönner" an verschiedenen Dingen, die man ausprobieren kann. Das ist, als würde man eine Menge Spaghetti-Nudeln an die Wand werfen und hoffen, dass einige davon kleben bleiben. Und einige dieser "Lösungen" können andere Probleme in Ihrem Programm verursachen. Zum Beispiel könnte der Vorschlag, AutoEventWireup="true" zu setzen, dazu führen, dass einige Ihrer Ereignisse zweimal ausgelöst werden!!! (siehe http://support.microsoft.com/kb/814745).

Answer 5

In meinem Fall hing das Problem damit zusammen, dass sowohl der Einsatz von vollständigem IIS (nicht Express) als auch ein Debug-Build, der vollständige Debug-Symbole enthielt, aber auch Projekt-Eigenschaften, Build, Optimize code aktiviert hatte.

Unter Express funktioniert dies einwandfrei, aber unter vollem IIS funktioniert es nicht. Visual Studio hängt den w3wp-Prozess korrekt an, lädt jedoch keine Symbole für die optimierte DLL. In Visual Studio können Sie zu Debug, Windows, Module gehen, dann für die spezifische DLL scrollen und prüfen, ob in der Spalte Symbol Status Skipped Loading Symbols. angezeigt wird. Klicken Sie mit der rechten Maustaste darauf und wählen Sie Symbole laden, um es zum funktionieren zu bringen.

Eine zusätzliche Einstellung, die dies beeinflussen kann, ist, ob Visual Studio nur den Benutzercode im Debug-Modus debuggen soll unter Debug, Optionen und Einstellungen, Debugging, Allgemein, Nur meinen Code aktivieren. Wenn optimiert, werden die DLLs als nicht Benutzercode markiert, wenn sie unter vollem IIS ausgeführt werden, sodass bei Aktivierung von Nur mein Code alle Haltepunkte darin übersprungen werden. Sie können entweder VS so einstellen, dass nicht-Benutzercode debuggt wird, oder den Build nicht optimieren, um Haltepunkte zu erreichen.