„Der Haltepunkt wird derzeit nicht erreicht. Der Quellcode unterscheidet sich von der Originalversion. “ Was bedeutet das?

Beim Debuggen in Visual Studio füge ich manchmal einen Haltepunkt hinzu, der jedoch hohl ist, und VS sagt: "Der Haltepunkt wird derzeit nicht erreicht. Der Quellcode unterscheidet sich von der Originalversion." Dies verhindert natürlich, dass ich debuggen kann.

Was um alles in der Welt bedeutet die Botschaft? Welche Originalversion? Wenn ich gerade die Lösung geöffnet und keinerlei Änderungen am Code vorgenommen habe, wie kann es dann eine "Originalversion" geben?

Wie es heißt, unterscheidet sich der "Quellcode von der Originalversion".

Klicken Sie mit der rechten Maustaste auf den Projektordner im Lösungs-Explorer und wählen Sie Clean. Erstellen Sie eine neue Version des Projekts und der Haltepunkt funktioniert wieder!

Wenn Sie das DLL-Projekt in der Debug-Build-Konfiguration deaktiviert haben, wird Ihr neuer Code niemals erstellt!

Gehen Sie zu Build --> Configuration Manager ...(in VS2010) und überprüfen Sie, ob das Projekt mit dem Code, den Sie debuggen möchten, auf die aktuelle Build-Konfiguration überprüft wurde.

Für mich war es während der Arbeit an einem WebSite-Projekt. Nach dem Bereinigen dieser temporären Ordner habe ich die richtigen Compilerfehler zurückbekommen:

• C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
• C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Ich habe das Problem endlich gelöst, als ich herausfand, dass eine Klassendatei, die ich absichtlich in einen Unterordner verschoben hatte, irgendwie wieder im Stammordner angezeigt wurde. VS hat das eine verwendet, während ich das andere bearbeitet habe.

Hast du das jemals gemacht?

Möchten Sie fortfahren und den letzten erfolgreichen Build ausführen?

Wenn Sie das Kontrollkästchen aktiviert und "Ja" gedrückt haben, wird der letzte erfolgreiche Build ausgeführt, obwohl Ihr Projekt nicht kompiliert wird. Dies bedeutet, dass bei jedem Festlegen eines Haltepunkts dieser Fehler angezeigt wird.

Versuchen Sie, diesen Wert zu ändern:

• Werkzeuge
  • Optionen
    • Projekte und Lösungen
      • Erstellen und ausführen
        • Beim Ausführen, wenn Build- oder Bereitstellungsfehler auftreten: Nicht starten

Gehe zu

• Werkzeuge
  • Optionen
    • Debuggen
      • Allgemeines

Deaktivieren Sie Quelldateien erforderlich , um genau mit der Originalversion übereinzustimmen

Wählen Sie Debug in Solution Configurations anstelle von Release

Beachten Sie das Fenster "Ausgabe" in VS. Hier erfahren Sie, welche Assemblys wann geladen werden. Möglicherweise wird eine ältere Version Ihrer Assembly irgendwo im Ordner geladen.

Wenn Sie beispielsweise mehrere Assemblys haben und derzeit versuchen, eine der Support-Assemblys aufzubrechen, übernimmt die CLR die Auflösung der Assembly, wodurch möglicherweise eine andere Assemblydatei als die im Projekt referenzierte geladen wird.

Das Schließen von Visual Studio und das erneute Öffnen der Lösung können das Problem beheben, dh es handelt sich um einen Fehler in der IDE selbst (ich verwende VS2010).

Wenn mehr als eine Instanz von Visual Studio ausgeführt wird, müssen Sie nur die Instanz schließen, auf der die Lösung mit dem Problem ausgeführt wird.

Ab Visual Studio 2017 15.3.1 bis 15.3.5 wurde ein neuer Weg gefunden, um dieses Problem zu beheben. Wenn Sie EditorConfig verwenden , verursacht die charset=utf8Option diese Symptome. Das VS-Team hat dies reproduziert und sagt, dass sie daran arbeiten .

Eine Lösung besteht darin, Ihre charset=utf8Zeile in der .editorconfig-Datei zu kommentieren .

Bearbeiten: Dies sollte ab VS 15.5 behoben sein.

Dies tritt häufig auch dann auf, wenn Sie Dateiverweise auf Binärdateien verwenden (anstelle von Projektverweisen auf Code in Ihrem Projekt) und die kompilierte Binärdatei, auf die Sie verweisen, nicht mit dem entsprechenden Quellcode auf Ihrem Computer synchronisiert ist. Dies kann passieren, weil Sie eine neue Version der Binärdatei von der Quellcodeverwaltung ohne den dazugehörigen neuen Quellcode heruntergeladen haben oder wenn Sie einige Versionen der Binärdatei auf Ihrem Computer haben und auf eine alte Kopie verweisen usw. Wenn dies tatsächlich der Fall ist Das Problem ist, dass es ein guter Grund ist, Projektreferenzen so oft wie möglich zu verwenden.

Für mich hat keiner der Punkte das Problem gelöst. Ich habe gerade eine neue Codezeile in diese Funktion eingefügt, etwa:

int a=0;

Ich schätze, ich habe Visual Studio ausgelöst, um diese Funktion zur Originalversion hinzuzufügen

Dies kann passieren, wenn sich die Systemzeit während des Debuggens oder zwischen Debug-Sitzungen ändert, sei es programmgesteuert, manuell oder durch ein externes Programm.

Es gibt eine fast unmerkliche Einstellung, die dieses Problem für mich behoben hat. Wenn es eine bestimmte Quelldatei gibt, in der der Haltepunkt nicht erreicht wird, kann sie in aufgelistet werden

• Lösungsforscher
  • Klicken Sie mit der rechten Maustaste auf Lösung
    • Eigenschaften
      • Allgemeine Eigenschaften
        • Debug-Quelldateien
          • "Suchen Sie nicht nach diesen Quelldateien".

Aus einem mir unbekannten Grund hat VS 2013 beschlossen, dort eine Quelldatei abzulegen, und anschließend konnte ich den Haltepunkt in dieser Datei nicht mehr erreichen. Dies kann der Schuldige für "Quellcode unterscheidet sich von der Originalversion" sein.

Das Problem ist, dass Ihre Debug-Informationen nicht mit Ihrer Assembly synchronisiert sind. Die Lösung ist einfach:

1. Gehen Sie zu Ihrem Bin-Ordner
2. Entfernen Sie die PDF-Dateien
3. Wiederaufbauen

Sollte den Trick machen!

(Das Seltsame ist, dass eine Neuerstellung ohne Wegwerfen der PDF-Dateien nicht immer funktioniert. Ich kann sehen, dass das Änderungsdatum aktualisiert wird, aber immer noch irgendwo in der Kette (VS2013-Debugger, IIS, Assembly-Cache). Diese Änderung wird nicht erkannt )

Sie können diese Meldung erhalten, wenn Sie einen Aktivator verwenden und die Assembly, in der Sie den Haltepunkt festgelegt haben, noch nicht geladen wurde.

Der Haltepunkt wird aufgelöst, sobald der Aktivator die Assembly lädt (vorausgesetzt, die Assembly- und Debug-Symbole sind aktuell). Ein guter Ort zum Anschauen ist das Modulfenster im Debugging-Menü. Dort sollten Sie nach der Assembly suchen, zu der auch Ihre Datei gehört. Überprüfen Sie zunächst, ob die Baugruppe geladen ist. Woher wird es dann geladen? Dann wird die Symboldatei geladen. Woher wird die Symboldatei wieder geladen? Überprüfen Sie abschließend die Versionen von beiden.

Ich bin auch darauf gestoßen. Die Bedingungen, die mein Problem verursacht haben:

• Ich führe lokal eine vollständige IIS7-Instanz aus
• Ich versioniere meine Software in separate Projekte

Ich hatte dies verursacht, indem ich eine frühere Version geöffnet hatte (VS wurde gefragt, ob ich beim IIS-Debugging auf diese Instanz verweisen wollte, ich antwortete mit "Ja") und dann die aktuelle Version öffnete (erneut auf die IIS-Eingabeaufforderung mit "Ja" antwortete). ) und versucht dann, in der vorherigen Version zu debuggen.

Zur Lösung habe ich lediglich die vorherige und beabsichtigte Version geschlossen und erneut geöffnet und sie erneut als Debugging-Quelle bestätigt.

Versuchen Sie, den Haltepunkt zu deaktivieren und neu festzulegen, während Sie im Debug-Modus ausgeführt werden, anstatt dies zu tun, bevor Sie den Debug-Modus starten.

Dies geschieht auch beim Debuggen eines C ++ - Projekts, das ein Modul lädt, das mit einer CRL-Sprache (Managed C ++, C # usw.) implementiert wurde. In dieser Situation ist die Fehlermeldung tatsächlich irreführend.

Die Lösung besteht darin, die Konfigurationseigenschaft für die Unterstützung der Common Language Runtime (CLR) in das Startprojekt zu übernehmen und diese neu zu kompilieren.

Wenn Ihre Lösung mehr als ein Projekt enthält , stellen Sie sicher, dass das richtige Projekt als festgelegt ist StartUp Project. Um ein bestimmtes Projekt als Startprojekt Ihrer Lösung festzulegen, klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie Set As StartUp Project.

Nachdem ich mein StartUp-Projekt richtig eingestellt habe, hat der Thread den gewünschten Haltepunkt erreicht.

Ich habe dies in einem 32-Bit-Build auf vs2017 erlebt.

Genau keine der Lösungen hat bei mir funktioniert. Ich habe neu gestartet, IDE-Dateien gelöscht, die Lösung bereinigt, aus dem Git-Repo gezogen und die Lösung ohne Erfolg neu erstellt.

Ich habe eine 64-Bit-Abhängigkeit von Nuget abgerufen und sobald ich die Assembly verwendet habe, wurden die Quellen nicht mehr in die endgültige ausführbare Datei integriert, sondern die zwischengespeicherten IDE-Quellen.

Ich habe die Nuget-Konfiguration entfernt, die referenzierte Assembly entfernt, die Quelle heruntergeladen, log4net manuell erstellt, signiert, einem Ordner in meinem Projekt hinzugefügt, einen Verweis darauf hinzugefügt und konnte erneut debuggen.

Das war ein Schmerz, ich hoffe, es wird in der Antwortliste für alle sichtbar.

Bearbeiten: Während der Erstellung ist kein Fehler aufgetreten, obwohl in den IDE-Einstellungen die Option "Eingabeaufforderung bei Erstellungsfehler" aktiviert ist.

Für mich war die Lösung in Advanced Build Settingsden Projekteigenschaften versteckt :

Aus einem unbekannten Grund wurde Folgendes festgelegt none: Durch Festlegen auf wurde fullder Haltepunkt erreicht.

Um zu diesem Dialogfeld zu gelangen, öffnen Sie die Projekteigenschaften, gehen Sie zu Buildund wählen Sie die Advanced...Schaltfläche unten auf der Seite.

Ich hatte das gleiche Problem in mehreren Projekten in einem Projekt mit geschichteter Architektur und das Problem war, dass in Konfigurationen das Kontrollkästchen "Erstellen" für das ausgewählte Projekt nicht aktiviert wurde. Daher wurde das Problem für ein Projekt behoben.

Für eine andere Ebene gab es das gleiche Problem, auch wenn der Build in den Konfigurationen aktiviert ist. Ich habe alle anderen Optionen wie den Neustart des Projekts durchgeführt, aber keine davon hat geholfen. Schließlich habe ich das Kontrollkästchen Build für das jeweilige Projekt deaktiviert und bereinigt und neu erstellt. Das markierte erneut das Kontrollkästchen und tat dasselbe. dann wurde das Problem behoben.

Hoffe das hilft..

In meinem Fall habe ich in VS 2012 eine Verbindung zu einem laufenden Prozess hergestellt. Beim Anhängen haben Sie die Möglichkeit, in verschiedenen Modi (nativ, Skript, Silverlight, Managed 2.0, Managed 4.0 usw.) zu debuggen. Standardmäßig wählt der Debugger den Modus automatisch aus. Automatisch trifft jedoch nicht immer die richtige Wahl. Wenn Ihr Prozess mehrere Codetypen enthält, stellen Sie sicher, dass der Debugger den richtigen verwendet.

In meinem Fall habe ich eine Windows CE-App entwickelt, die gegen einen Emulator getestet wurde. Das Problem war, dass die ausführbare Datei nicht auf dem Emulator bereitgestellt wurde, sodass die PDF-Datei (in der Entwicklungsumgebung) nicht mit der EXE-Datei (im Emulator) synchronisiert war, da die neue EXE-Datei nie in den Emulator kopiert wurde. Ich musste die EXE-Datei im Emulator löschen, um eine neue Bereitstellung zu erzwingen. Dann hat es funktioniert.

Für mich hat es funktioniert, die Lösungsplattform von x86 auf Any CPU zu ändern. Nachdem ich zu Beliebig gewechselt hatte, legte ich eine Stoppadresse fest, führte die Website aus, öffnete die Seite, klickte auf die Schaltfläche und sie wurde gestoppt. Ich habe die Site geschlossen, wieder auf x86 umgestellt und dieselbe Sequenz erfolgreich ausgeführt.

Wenn Sie unter Windows 7, Visual Studio Express 2010, die Option Kompatibilitätsmodus für Windows XP SP3 verwenden aktiviert haben , kann dieser Fehler auftreten.

Ich habe die Option deaktiviert und es hat wieder perfekt funktioniert. Klicken Sie mit der rechten Maustaste auf die Verknüpfung zu VS oder die ausführbare Datei und wählen Sie Eigenschaften aus und dann Kompatibilität aus .

Zuerst habe ich es über die Kommandozeile versucht.

Das Löschen von temporären Dateien über die Befehlszeile hat funktioniert.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporäre ASP.NET-Dateien> rd / s-Stammverzeichnis

Wenn ich "Nur meinen Code aktivieren" deaktiviere Option -> Optionen -> Debuggen -> Allgemein

Das Problem wurde für mich gelöst . Es ist eine WCF-Anwendung, die versucht hat, eine Ashx-Seite zu debuggen. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Es ist mir passiert, weil ich andere Projekte in der Lösung hatte, die nicht gebaut wurden. Nachdem ich diese problematischen Projekte entladen hatte (Rechtsklick auf das Projekt im Lösungs-Explorer -> Projekt entladen), die Lösung neu erstellt und erneut ausgeführt habe, wurde der Haltepunkt erreicht!

Es war glücklich, in Visual Studio 2017 zu sein, nachdem ich dem Projekt vorhandene Dateien hinzugefügt hatte. Das hat bei mir funktioniert:

1. Schließen Sie die Lösung,
2. gehe zu SolutionFolder\.vs\SolutionName\v15\sqlite3und entfernestorage.ide
3. Öffnen Sie die Lösung erneut

Stellen Sie sicher, dass Sie sich beim Debuggen nicht im Release-Modus befinden.