Ok, was ich habe:

Visual Studio 2010 RC, W7 x64, startete einen neuen Projekttyp einer Silverlight-Anwendung. Hosten der Silverlight-Anwendung in einem ASP.NET-Webanwendungsprojekt. Silverlight Version 3.0. Es wurden eine LinqToSQL-Klasse, ein WCF-Dienst, eine Winform-Tester-Anwendung (Projekt in der Lösung) und einige Klassen (auch als Projekte in der Lösung) hinzugefügt.

Gestern bekam ich plötzlich den 'Der Haltepunkt wird momentan nicht erreicht. Für dieses Dokument wurden keine Symbole geladen. ' Wenn die Meldung in der IDE angezeigt wird, sie jedoch nur die Webanwendung betrifft, kann ich das Silverlight und die Winform-App debuggen.

Was ich versucht / getan habe, um die Nachricht loszuwerden:

• Setzen Sie die Visual Studio-Einstellungen zurück
• Alle Dateien in jedem \ Temporären ASP.NET-Dateiordner wurden entfernt (es gibt eine für jedes 32-Bit / 64-Bit und für Framework 2.0 und 4.0).
• Ich habe versucht, mit Visual Studio Integrated Web Server zu debuggen. Normalerweise verwende ich IIS. In der Projektausgabe der Lösung habe ich alle obj- und bin-Ordner in jedem Projektordner gelöscht
• hat eine neue Lösung erstellt und alle Projekte zu dieser neuen Lösung hinzugefügt
• löschte die Lösung suo Datei
• hat eine neue ASP.NET-Webanwendung erstellt, um zu testen, ob es sich um ein VS-Installationsproblem handelt => Ich kann dieses neue Projekt / diese neue Lösung debuggen
• Starten Sie den Computer mehrmals neu
• Die vs.net-Installation wurde repariert
• hat einen IISReset durchgeführt
• Die Web-App wurde aus IIS entfernt
• Verwenden Sie die Schaltfläche Virtuelles Verzeichnis erstellen unter Projekteigenschaften der Webanwendung, um eine neue Webanwendung in IIS zu erstellen
• Die Framework-Version jedes Projekts wurde von 3.5 auf 4.0 geändert
• Öffnete die Lösung auf meinem zweiten Computer => gleiches Verhalten
• hat Microsoft Connect nach Fehlern / ähnlichen Problemen durchsucht
• 7 Stunden verbracht.

Das passiert also zum zweiten Mal in meinem Leben. Das letzte Mal habe ich es gelöst, indem ich den Ordner "Temporäre ASP.NET-Dateien" gelöscht habe, aber diesmal brauche ich Ihre Hilfe.

Klicken Sie mit der rechten Maustaste auf Lösung -> Eigenschaften

Suchen Sie unter Allgemeine Eigenschaften -> Startprojekt

Wählen Sie mehrere Startprojekte aus

Wählen Sie Aktion starten für die Projekte, die Sie debuggen möchten.

Ich hatte das gleiche Problem und nach dem Googeln fand ich zwei typische Lösungen dafür:

1. Stellen Sie sicher, dass der Silverlight-Debugger im .Web-Projekt aktiviert ist. Öffnen Sie die Projekteigenschaften und wählen Sie den Silverlight-Debugger auf der Registerkarte "Web" aus.

2. Starten Sie Visual Studio neu und löschen Sie alle Ordner bin und obj.

Aber keines davon hat bei mir funktioniert . Dann erwähnte jemand weit unten in einem Thread, um stattdessen den IE als Browser zu verwenden. Dadurch funktionierten Debugging und Haltepunkte wieder!

Bearbeiten:

Später habe ich Probleme damit, dass IE9 nicht funktioniert, weil es mit dem falschen Prozess verbunden ist. Anstatt jedes Mal manuell an den richtigen IE-Prozess anzuhängen, habe ich einen netten Trick gefunden :

• Klicken Sie mit der rechten Maustaste auf eine der generierten Seiten im .Web-Projekt (.html oder .aspx).
• Klicken Sie auf "Durchsuchen mit ..."
• Festlegen des IE als Standardbrowser (wirkt sich nur auf die Auswahl des Browsers durch Visual Studio aus)

Jetzt startet Visual Studio den IE, wenn das .Web-Projekt ausgeführt wird, und hängt an den richtigen Prozess an. Das sollte es tun.

Immer wenn dieser Fehler aufgetreten ist, stellt sich heraus, dass sich der Ordner, aus dem Visual Studio Assemblys lädt, von dem Ordner unterscheidet, aus dem die Webanwendung ausgeführt wird.

Das heißt, der Anwendungsserver führt die Anwendung aus

C:\dev\MyApplication\bin 

aber Visual Studio debuggt von

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

Hinweis - Aus verschiedenen Gründen mache ich mein Debugging mit IIS als Anwendungshost anstelle des dinky Standalone-Gizmos, das die meisten Leute verwenden. Dies könnte die Nützlichkeit meiner Antwort beeinflussen!

Update :

Für IIS ist das Anwendungsserververzeichnis (dh C:\dev\MyApplicationoben) das physische Verzeichnis für die Webanwendung konfigurierte Dies kann durch Ändern der Grundeinstellungen für die App gesteuert werden.

Für Visual Studio ist das Debugging-Verzeichnis (dh C:\dev\MyOtherApplicationoben) das Verzeichnis, in dem sich Ihre svcDateien befinden, normalerweise dasselbe Verzeichnis wie Ihre csprojProjektdatei.

Für mich stellte sich heraus, dass das Kontrollkästchen Eigenschaften-> Erstellen-> Code optimieren in der Debug-Konfiguration aktiviert war. Das Ausschalten, Wiederherstellen und Debuggen funktionierte wie gewohnt.

Der Grund dafür ist, dass die PDBs ("PDB steht für Program Database, ein proprietäres Dateiformat (von Microsoft entwickelt) zum Speichern von Debugging-Informationen zu einem Programm) nicht aktuell sind. Dies kann einige Gründe haben ::

1- Wie Bevan sagte, debuggen Sie möglicherweise eine andere Anwendung!

2- Sie debuggen eine andere Version derselben Anwendung. Sie haben beispielsweise eine zuvor erstellte Anwendung mit der aktuellen Version des Codes zum Debuggen angehängt, ohne sie (neu) zu erstellen.

Das Reinigen oder Wiederherstellen der Lösung löst solche Probleme für mich.

Um sicherzustellen, dass das Problem nicht bei Ihnen liegt, versuchen Sie, dieselbe Anwendung mit VS 2008 zu debuggen (ich befürchte, es könnte ein Fehler in VS 2010 sein - es ist noch Beta!).

Ich hatte das gleiche Problem, ich debuggte mein Projekt, und ich musste mit der rechten Maustaste auf das Projekt klicken und "Neue Debug-Instanz" auswählen. Ich musste das nur einmal machen, danach funktionierte es wie gewohnt.

Dieser Fehler tritt ab und zu bei mir auf und ich kann ihn immer auf die Projekteinstellungen für die betreffende Baugruppe zurückführen. Sie müssen nicht "warten", bis Ihr Code einen Haltepunkt nicht berücksichtigt oder bis Sie den Haltepunkt festgelegt haben, um zu wissen, in welche Assemblys Symbole geladen sind.

Wenn Sie ein Projekt im Debug-Modus ausführen, wird im Ausgabefenster aufgelistet, welche Assemblys die folgenden Symbole geladen haben (möglicherweise müssen Sie das Bild auf einer neuen Registerkarte öffnen): T.

In diesem Fall sind in BASD.Core.Data.dll KEINE Symbole geladen. Sie können dann die Projekteinstellungen für diese Assembly mit denen einer anderen Assembly vergleichen, die es geschafft hat, Symbole zu laden, um herauszufinden, warum einige Symbole laden und andere nicht.

"Für mich" jedoch "jedes" Mal, wenn dies passiert, liegt es daran, dass die Debug-Informationen nicht erstellt werden. Also öffne ich Projekteigenschaften> Erstellen> Erweitert in einem (C #) Projekt.

Für Basd.Core.Data.dll oben, dh ohne Symbole, waren die erweiterten Build-Einstellungen:

Während für Basd.Core.Configuration.dll, dh eine Assembly, in der ich einen Haltepunkt festlegen und erreichen konnte, folgende Einstellungen vorgenommen wurden:

Ich gebe also Debug-Informationen im letzteren Projekt aus und nicht im ersten, daher meine Fähigkeit, den Haltepunkt in Basd.Core.Configuration.dll zu erreichen

Beachten Sie auch, dass es nicht ausreicht, nur eine PDF-Datei im bin-Ordner eines Projekts für eine bestimmte DLL zu haben, da diese möglicherweise veraltet ist und daher von Visual Studio nicht als gültige Symboldatei für die DLL verwendet wird du versuchst durchzutreten.

Beachten Sie außerdem, dass durch Ändern der Build-Konfigurationen die Build-Info-Einstellungen und die Herkunft der Symbole geändert werden können.

(Mir ist klar, dass ich mich in diesem Fall im Release-Modus befinde, die Methode jedoch weiterhin gilt.)

Gehe zu Projekteigenschaften -> Erstellen -> Erweitert ...

Wählen Sie im Abschnitt "Ausgabe" in der Dropdown-Liste "Debug-Informationen" die Option "Voll"

Stellen Sie sicher, dass Sie Ihr Programm im DEBUG-Modus und nicht im RELEASE-Modus ausführen.

Debuggen -> An Prozess anhängen ->
Wählen Sie die folgenden Codetypen debuggen : Option -> Wählen
Sie Managed v3.5, v3.0, v2.0 oder Managed v4.5, v4.0

Ich habe dieses Problem gerade gemäß Bereitstellen von Silverlight-Anwendungen behoben . (Diese Antwort ist ein Duplikat einiger anderer, aber ich werde versuchen, sie genauer zu erklären.)

Das Problem ist höchstwahrscheinlich, dass Ihre Silverlight-Anwendung beim Erstellen / Starten nicht ordnungsgemäß in Ihrer Webanwendung bereitgestellt wird. Dies ist ein Referenzierungsproblem - es ist einfach zu verstehen, aber beim ersten Auftreten nicht offensichtlich.

Genau wie jede andere Projektverweis, der referenzierten Ausgabe des Projekts sollte auf die kopiert werden Referenzierung Projekt Binärordner , um zu debuggen. Bei Klassenbibliotheken geschieht dies, wenn Sie mit der rechten Maustaste klicken und "Referenz hinzufügen ..." auswählen. Für Silverlight sollten Sie über die Projekteigenschaften eine Referenz hinzufügen.

• Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie "Eigenschaften".
• Wählen Sie links die Registerkarte "Silverlight-Anwendungen"
• Klicken Sie auf die Schaltfläche "Hinzufügen ..." und wählen Sie Ihr Silverlight-Projekt aus dem Dialogfeld aus

Dadurch wird ein Verweis auf die Silverlight-Anwendung aus Ihrer Hosting-Webanwendung hinzugefügt und sichergestellt, dass die xapDatei beim Erstellen oder Bereitstellen in die Webanwendung kopiert wird. Das bedeutet, dass sich die aktuelle Silverlight-App und ihre Debug-Dateien in der zu debuggenden Anwendung befinden und Sie den Code schrittweise durchgehen können.

Wenn Sie ein Webprojekt debuggen, stellen Sie sicher, dass das Attribut debug = "true" in Ihrer Datei web.config festgelegt wurde:

<system.web>
    <compilation debug="true"   .../>

Ich hatte das gleiche Problem unter Windows 7 und habe alles versucht : bereinigte DLLs, untersuchte die Liste der Module, deaktivierte "Just My Code" und so weiter.

Das Problem wurde behoben, nachdem ich Visual Studio "als Administrator" ausgeführt habe. Ehrlich. Warum konnte Microsoft mich nicht einfach warnen, dass es nicht "als Administrator" ausgeführt wird? Das würde mir einige Stunden Arbeit ersparen.

Für mich war das Problem, dass ich "Code optimieren" auf der Registerkarte "Erstellen" der Einstellungen meines Projekts aktiviert hatte.

Hatte das gleiche Problem

Aus irgendeinem Grund wurde eine der DLLs im GAC registriert, daher hatte sie immer eine andere Version als der Code.

Nachdem ich es aus dem GAC entfernt hatte, war das Problem gelöst

Für diejenigen, die Visual Studio 2008 und nicht Visual Studio 2010 verwenden und diesen Fehler erhalten. Die obigen Antworten haben mir in dieser Situation nicht geholfen, daher teile ich meine Erfahrungen.

Wenn Sie eine IIS-Webanwendung in Visual Studio 2008 debuggen, indem Sie eine Verbindung zum Prozess w3wp.exe herstellen, anstatt den ASP.NET Development Server zum Debuggen zu verwenden (beginnen Sie mit dem Debuggen), ist dies möglicherweise Ihr Problem:

Visual Studio verweist möglicherweise immer noch auf eine Symboldatei (Datei, die beim Debuggen verwendet wird) aus Ihrer DLL aus einem veralteten IIS-Prozess. Diese Symboldatei wurde durch eine Neukompilierung des .NET-Quellcodes neu erstellt, aber der IIS-Prozess verweist weiterhin auf die alte Symboldatei.

Reparieren:

Beenden Sie einfach das Debuggen in Visual Studio, starten Sie die Webanwendung neu und hängen Sie sie erneut an den Prozess an. Dann sollten die Haltepunkte wieder von gelb (wenn Sie diesen Fehler sehen) zu rot wechseln.

========================

Weitere Dinge zum Ausprobieren (heute neue Situation gefunden):

Führen Sie jede Kugel im Link unten EINMAL aus, aber wiederholen Sie meine Schritte unten mit jeder, die Sie versuchen.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Beenden Sie das Debuggen (drücken Sie das rote Quadrat) in Visual Studio.
2.) Clean Solution
3.) Build Solution
4.) [BULLET-ANLEITUNG HIER EINFÜGEN]
5.) Tools> An Prozess anhängen (oder mit dem Debuggen beginnen)
6.) Starten Sie das Programm, an das Sie eine Verbindung herstellen, und führen Sie es so aus, dass Ihr Code getroffen wird

6 erklärt:

Wenn Sie eine Verbindung zu nunit.exe herstellen, öffnen Sie NUnit und führen Sie einen Test durch, damit Ihr Haltepunkt erreicht wird

Wenn Sie eine Verbindung zu w3wp.exe (IIS-Site) herstellen, öffnen Sie Ihre Site im Browser und wechseln Sie zu der Seite, die Ihren Haltepunkt erreicht

BEARBEITEN:

Heute ist mir aufgefallen, dass wenn Sie versuchen, ein Projekt zu debuggen, das nicht als Startprojekt festgelegt ist, dies angezeigt wird. Wenn Sie eine Verbindung zu Ihrem w3wp.exe-Prozess herstellen, wird dessen Debugging für das Projekt in Betracht gezogen, das als Startprojekt festgelegt ist. Klicken Sie zum Auflösen einfach mit der rechten Maustaste auf das Webanwendungsprojekt und wählen Sie "Als Startprojekt festlegen". Versuchen Sie dann erneut, eine Verbindung zu Ihrem Prozess herzustellen.

Das Szenario lautet wie folgt: Ein bestimmtes Projekt ist Ihr Startprojekt (z. B. hat die Hauptmethode). Dieses Projekt verweist auf andere Projekte in Ihrer Lösung. Haltepunkte in den anderen Projekten werden nicht getroffen.

Schnelle Lösung: Wenn Sie Ihre Lösung erstellen, suchen Sie im Ausgabepfad Erstellen (normalerweise bin \ Debug) nach dem Startprojekt. Sehen Sie sich die DLL- und PDB-Dateien für die Projekte an, auf die Sie verweisen. Stellen Sie sicher, dass das Datum der letzten Änderung das Datum ist, an dem Sie Ihre Lösung zuletzt erstellt haben. Wenn dies nicht der Fall ist, kopieren Sie sie aus dem Build-Ausgabepfad für jedes Projekt in Ihren Build-Ausgabepfad für Startprojekte. Zum Beispiel:

Projekt A hat Main. Es verweist auf Projekt B. Ihre Haltepunkte werden in Projekt B nicht erreicht. Kopieren Sie die DLL- und PDB-Datei aus dem Build-Ausgabepfad von Projekt B in den Build-Ausgabepfad von Projekt A. Führen Sie dann Ihre Lösung aus. Der Haltepunkt wird jetzt erreicht.

Jetzt müssen Sie herausfinden, warum Projekt A nicht über die DLL- und PDB-Datei von Projekt B kopiert. Die Antworten hier decken die meisten Szenarien ab. Ein Szenario, das nicht berührt wird, besteht darin, sicherzustellen, dass Ihre Projekte und Lösungen ordnungsgemäß an TFS gebunden sind. Ich hatte einige Projekte gebunden und einige nicht richtig gebunden. Das hat das Problem für mich verursacht. Nachdem ich das behoben hatte, verschwand das Problem und ich musste nicht mehr über die DLL- und PDB-Dateien kopieren.

Die Lösung für das gleiche Problem in meinem Fall war die folgende Kombination von Schritten:

1. Lösung -> Eigenschaften Mehrere Startprojekte auswählen Wählen Sie Aktion starten für die Projekte aus, die Sie debuggen möchten.
2. Der Dienst wurde aus den Dienstreferenzen entfernt und die Lösung bereinigt.
3. Erstellen Sie das Serviceprojekt neu
4. Es wurde wieder zu den Servicereferenzen hinzugefügt
5. Bereinigen Sie die Lösung und erstellen Sie sie neu.

Um dieses Problem in Web.config zu beheben, musste ich nur hinzufügen debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

Was mir bei der Suche nach dieser Lösung geholfen hat, war das Betrachten der Modulfenster beim Debuggen und die Feststellung, dass für meine geladenen ASP.NET-DLLs Folgendes vorhanden war: Binär wurde nicht mit Debuginformationen erstellt.

Ich hatte das gleiche Problem, aber in VS2013 für eine Web-App. Für mich bestand die Antwort darin, die Build-Konfiguration für die Lösung zu aktualisieren:

1. Klicken Sie mit der rechten Maustaste auf die Lösung und wählen Sie Eigenschaften
2. Wählen Sie die Debug-Konfiguration
3. Wählen Sie im Untersetzer unter "Konfigurationseigenschaften" die Option "Konfiguration"
4. Aktivieren Sie das Kontrollkästchen "Erstellen" für jedes Projekt, das Sie debuggen möchten

Sobald ich dies getan hatte, begannen alle meine Haltepunkte zu funktionieren.

Okay, los geht's:

(In einer "Silverlight-App": Bitte überprüfen Sie zuerst, ob Silverlight in "Web" in den Eigenschaften Ihres Serverprojekts "Eigenschaften" aktiviert ist. Wenn dies nicht behoben wurde, versuchen Sie dies unten.)

Beim ersten Mal: ​​Führen Sie Folgendes aus: devenv.exe / ResetSettings und 1: Klicken Sie im oberen Menü auf Debug-Tag 2: Klicken Sie auf Optionen und Einstellungen. 3: Klicken Sie unter "Allgemein" auf "Optionen". 4: Aktivieren Sie das Kontrollkästchen. 5: Und jetzt werden alle Symbole heruntergeladen und neu konfiguriert :)

Wenn es nach dem oben genannten Vorgang erneut auftritt, löschen Sie einfach den Ordner, in dem sich die Symbole befinden:

1: Klicken Sie im oberen Menü auf Debug-Tag 2: Klicken Sie auf Optionen und Einstellungen. 3: Suchen Sie unter "Debugging" und unter "Symbole" die Schaltfläche "Leerer Symbol-Cache" und klicken Sie darauf.

Öffnen Sie die Webanwendungs-URL im Browser und verwenden Sie dann in der VS.Net-IDE Tools -> AttachtoProcess

dann an aspnet_wp.exe anhängen.

Der Debugger beginnt zu arbeiten

Ich musste alle Instanzen der DLL manuell aus der Registrierung und alle Instanzen der DLL von meinem lokalen Laufwerk deinstallieren. Deinstallierte / installierte meine App neu und jetzt erreiche ich Haltepunkte! Einen halben Tag damit verschwendet :(.

Ich habe versucht, die .pdbDatei in obj\debugOrdner umzubenennen und eine saubere Lösung und Neuerstellung durchgeführt.
Es wurde eine neue .pdbDatei erstellt und ich konnte Haltepunkte korrekt treffen.

Ich hatte das gleiche Problem - ich habe viel Zeit verloren, als ich versuchte, das Debuggen in Visual Studio zum Laufen zu bringen.

Am Ende war es Nuget - ich hatte 3 Versionen von Newtonsoft.Json (über 7 C # -Projekte). Die Lösung würde kompiliert, war aber nicht debuggbar.

Ich habe das Problem behoben, indem ich Folgendes in der Package Manager-Konsole von Nuget ausgeführt habe:

PM> Update-Paket Newtonsoft.Json

Für meine WPF-App habe ich den Anwendungsordner gelöscht, "Neueste" aus der Quellcodeverwaltung erneut ausgeführt und neu erstellt. Alle Haltepunkte funktionieren jetzt hervorragend.

Versuchen Sie, Silverlight Application Project als Startprojekt festzulegen: Klicken Sie mit der rechten Maustaste auf Projekt -> Als Startprojekt festlegen. Drücken Sie dann F5 und prüfen Sie, ob Sie Haltepunkte abfangen können ...

Versuchen Sie jedes Mal, Browser- / temporäre Daten in Ihrem Browser zu löschen, wenn Sie Änderungen an der Silverlight-Anwendung vornehmen

Eine weitere Anekdote, die nützlich sein könnte -

Dieses Problem trat auf, als eines meiner Projekte Dateiverweise aus einem Release-Ausgabeordner verwendete. Wenn die Build-Ergebnisse in einem Warenordner abgelegt wurden, überschrieben diese Release-DLLs die Debug-DLLs.

Die Lösung bestand darin, in der csproj-Datei sicherzustellen, dass der HintPath meiner Referenz war

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

und nicht

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>

Ich hatte dieses sehr Problem , wenn bei einem Client , auf dem - für jede Anwendungslösung - sie am gemeinsamen Baugruppen zu einem „kopiert Referenzen “ -Ordner, dann sie zu der Lösung , die sowohl als „hinzugefügt Lösung Artikel “ und als ein „ Projekt “ in der Lösung.

Ich weiß noch nicht warum, aber einige waren debuggbar, andere nicht, obwohl in den Referenzeinstellungen für die Assemblys die richtigen vollständigen Pfade angegeben wurden.

Dieses unvorhersehbare Verhalten hat mich fast verrückt gemacht :)

Ich habe dieses Problem gelöst, indem ich alle Assemblys aus dem Ordner " References " entfernt habe, für die es Projekte mit Quellcode gab, und die Versionsinformationen für freigegebene Assemblys sehr gut verfolgt habe.

Ich hatte ein ähnliches Problem, außer dass mein Problem albern war - ich hatte 2 Instanzen des eingebauten Webservers, die unter 2 verschiedenen Ports ausgeführt wurden UND ich hatte mein Projekt -> Eigenschaften -> Web -> "Start URL", das auf einen festen Port zeigte, aber Die Web-App wurde unter diesem Port nicht ausgeführt. Mein Browser wurde also auf die "Start-URL" umgeleitet, die sich auf 1539 bezog, aber die Code- / Debug-Instanz wurde unter Port 50803 ausgeführt.

Ich habe den eingebauten Webserver so geändert, dass er unter einem festen Port ausgeführt wird, und meine "Start-URL" so angepasst, dass auch dieser Port verwendet wird. Projekt -> Eigenschaften -> Web -> Abschnitt "Server" -> "Visual Studio Development Server verwenden" -> spezifischer Port