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

513

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?

David
quelle
36
Kompilieren / erstellen Sie das Projekt neu, bevor Sie den Haltepunkt hinzufügen
Lexu
Öffnen Sie ein Projekt, das in einer anderen Version von Visual Studio geschrieben wurde?
Mahesh Velaga
2
Es ist ein Website-Projekt. Es sollte nicht notwendig sein, es explizit zu erstellen. Es sollte bei Verwendung kompiliert werden. Ich vermute, VS kann die Website nicht erstellen, aber das sagt mir das nicht! Mahesh - nein, alle die gleiche Version von VS.
David
In meinem Fall habe ich verschiedene Versionen desselben Codes (zum Beispiel test.cs in der Live-Version und der Devolopment-Version). Als ich die Devolopment-Version geöffnet und den Haltepunkt auf test.cs gesetzt habe, gab es den gleichen Fehler, aber ich habe herausgefunden, dass ich den Haltepunkt-Test gesetzt habe .cs Klasse, die sich auf Live-Version sln nicht Entwicklung bezieht, überprüfen Sie, dass die cs bereits unter Gebäudelösung hat)
dankyy1
5
Das Löschen von bin- und obj-Verzeichnissen als das Wiederherstellen hat bei mir funktioniert.
Aycan Yaşıt

Antworten:

277

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!

Veedrac
quelle
120
Die Verwendung von clean funktioniert nicht immer. Ich musste alles in meinem bin-Ordner manuell löschen, damit es wieder funktioniert.
Carra
3
Ich hatte fälschlicherweise einen Verweis auf eine DLL in meinem bin-Ordner. Referenzpfad korrigiert behoben.
Brad Urani
39
Für mich hat sogar das Löschen der Ordner bin und obj nicht funktioniert. Ich musste auch Visual Studio neu starten.
d512
1
Verbrachte fast einen Tag, um die Lösung zu finden. Vielen Dank für die Bereitstellung einer Lösung.
Rennen
8
Ich habe VS geschlossen, alle bin- und obj-Ordner gelöscht, alles neu erstellt, Build-Konfigurationen doppelt überprüft, Build ist erfolgreich. Kein Würfel. Einfache Dinge sollten nicht so kompliziert sein. >: |
Snarf
129

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.

Oliver
quelle
Danke für den Vorschlag Oliver. Das ist hier definitiv nicht passiert, ich würde es ziemlich schnell bemerken, wenn eines meiner Projekte nicht gebaut würde.
David
3
Ich hatte genau das gleiche Problem, nur hatte nichts ungeprüft. Es wurde nur für x86 in diesem Dialogfeld erstellt, während mein lokaler Computer x64 ist! Also habe ich die Any CPUOption ausgewählt und es funktioniert wieder.
JP Hellemons
3
Das Entfernen von Projekten aus der Debug-Konfiguration ohne gültigen Grund sollte eine Hauptsünde sein, da diese Konfiguration möglicherweise von der CI-Build-Maschine verwendet wird (ich weiß, dass sie hier ist), sodass sie letztendlich bestehen kann, wenn sie fehlschlägt. Ich weiß, dass es einer von vielen Bauschritten sein könnte, aber trotzdem ... @Oliver Ich hoffe, das Teammitglied hat dir ein paar Kekse gekauft! :)
Fetchez la vache
Ich hatte dieses Problem, als ich zu x86 anstelle von AnyCPU wechselte. Es wurden Projekte aus unbekannten Gründen nicht mehr erstellt.
Adam Pedley
Das Projekt ist für Build in Configuration Manager aufgeführt, daher hat mir das
leider
43

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.

AnthonyVO
quelle
2
Das Leeren der temporären Dateien im Windows-Verzeichnis hat bei mir funktioniert, Prost!
ChrisFletcher
7
Ich wollte nur eine ähnliche Antwort hinzufügen - stellen Sie sicher, dass keine alte Kopie der DLL Ihres Projekts in einem der von ASP.NET verwendeten temporären Ordner wie C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ herumliegt Temporäre ASP.NET-Dateien - wie erwähnt - aber auch C: \ Windows \ Microsoft.NET \ Framework_64_ \ v4.0.30319 \ Temporäre ASP.NET-Dateien . Ich benutze Everything, um schnell nach diesen Kopien zu suchen .
Oliver
12
Nur ein kurzer Hinweis: %localappdata%C:\Documents and Settings\%username%\AppData\Local
Wenn
1
Kann bestätigen, dass dies für mich in Visual Studio 2013 bei einem Webservice-Projekt funktioniert hat.
Moeri
Hat das alles getan, aber es scheint nicht geholfen zu haben. Ich war auch sehr aufgeregt, das zu sehen.
Ortund
40

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
Codesleuth
quelle
Ich glaube nicht, dass ich das getan habe. Danke für den Link. Es gab mir einen Einblick, was diese Aufforderung bedeutet!
David
11
Visual Studio hatte diese Option seit Jahrzehnten (zumindest VS98 hatte sie). Ich habe nie verstanden, warum jemand den letzten erfolgreichen Build ausführen möchte. Wenn ich das gewollt hätte, hätte ich es schließlich direkt gestartet, da ich sowieso nicht debuggen konnte. Nicht starten wäre eine sinnvollere Standardeinstellung gewesen.
OregonGhost
6
Ich habe es ein paar Mal verwendet, um das Projekt auszuführen (aus welchem ​​Grund auch immer, um nur jemand anderem zu zeigen), während ich noch Code schreibe, der nicht kompiliert werden kann. Manchmal ist es praktisch. Persönlich lasse ich es deaktiviert.
Codesleuth
3
Vielleicht, wenn sie ihren Vorgesetzten zeigen müssten, als er plötzlich vorbeikam. Sie könnten f5 drücken und sagen: "Sie sehen, es funktioniert!"
Gigala
33

Gehe zu

  • Werkzeuge
    • Optionen
      • Debuggen
        • Allgemeines

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

Rachmad
quelle
17
@Rachmad Diese Lösung funktioniert. Aber es scheint nicht die vollständige Lösung zu sein, da dies bedeutet, dass unsere Quelldateien nicht genau mit der Originalversion
übereinstimmen
Genau das, wonach ich von @entropy gesucht habe, ist richtig. Auf diese Weise können die Haltepunkte festgelegt werden. Fakt ist jedoch, dass die verwendete Quelle nicht mit der verwendeten PDF-Datei übereinstimmt. Die beste Lösung ist, das zu beheben. In Zeiten, die nicht möglich sind, funktioniert dies hervorragend.
JamesG
Selbst
wenn
12
Dies ist KEINE Lösung für dieses Problem, sondern eine Problemumgehung. Natürlich möchte ich nicht mit veralteten Dateien im Debugger arbeiten.
Obi Wan
2
@ObiWan Nicht offensichtlich. Ich mag es, kleinere Änderungen vorzunehmen und das Debuggen fortzusetzen, auch wenn ich weiß, dass die Quelle und der Build unterschiedlich sind.
Alan Baljeu
30

Wählen Sie Debug in Solution Configurations anstelle von Release

Screenshot des Menüs

AdiKonstantin
quelle
1
Das war mein Problem. Ich hatte im Debug-Modus kompiliert, den Code geändert und ihn später im Release-Modus ausgeführt. Kein Wunder, dass der Debugger dachte, der Code sei anders - die Debug-Symbole waren anders. Beim Löschen des Bin-Ordners, wie von anderen vorgeschlagen, wurde die Fehlermeldung "Für dieses Dokument wurden keine Symbole geladen" angezeigt. Erst dann stellte ich die Verbindung her und machte mich auf den Weg zu dieser Antwort. Es braucht mehr Stimmen!
indot_brad
Es ist möglich, dass das Projekt auch in der Debug-Build-Konfiguration für den Build deaktiviert wird. Eine Überprüfung der Build-Konfiguration ist erforderlich. Ein Flip-Flop zwischen der Debug- / Release-Konfiguration ist sinnlos.
Asad Saeeduddin
Das war es auch für mich. versuchte zu reinigen, die anderen Lösungen, auf die verwiesen wird, ohne Erfolg wieder aufzubauen. Ich habe nicht bemerkt, dass die Lösung mich ins Gesicht starrte
Adam Hey
Dies ist, was mit mir passiert ist - ich habe mein Projekt erstellt und meine DLLs immer wieder ersetzt, aber das Problem wird einfach nicht verschwinden. Ich stellte fest, dass der Code im Release-Modus erstellt wurde, während ich die DLLs aus dem Ordner / bin / debug ersetzte. Ich Idiot.
displayName
Ich wollte mich an einen Prozess anhängen, der im Release-Modus erstellt wurde. Der Wechsel zum Debug hat mein Problem gelöst.
fünf
27

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.

Tormod
quelle
1
Denken Sie auch daran, aber ich denke nicht, dass es hier das Problem ist, da ich versuche, in ein Website-Projekt einzubrechen, nicht in eine Klassenbibliothek.
David
24

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.

Luke Whyte
quelle
4
Das Schließen von Visual Studio hat auch bei mir funktioniert. Auch mit Clean / Rebuild-Aktionen.
DanielB
3
Dies
behebt
3
Feste Ausgabe in VS 2017
Daniel Fisher Lennybacon
Das Problem in VS 2012 wurde
behoben
19

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.

John Hatton
quelle
Der Status ist jetzt "Behoben - ausstehende Veröffentlichung" seit zwei Tagen (9. Oktober 2017). Das sind gute Nachrichten, da UTF-8 heutzutage die einzig vernünftige Standardeinstellung für die Textcodierung ist. :-)
rmunn
Ich merke auch , dass die eigentliche Ursache des Problems war offenbar das andere Bugfix , wo charset=utf8als „UTF-8 mit BOM“ interpretiert wurde. Durch Ändern dieser Interpretation in "ohne Stückliste" wurden einige UTF-8-Dateien beschädigt, in denen sich die Stückliste befand. Wenn Sie also auf dieses Problem stoßen und das Visual Studio-Update noch nicht veröffentlicht wurde, entfernen Sie die Stückliste vom Anfang Ihrer Textdateien. Dadurch wird das Problem möglicherweise behoben. (Dieser Kommentar bittet um eine Zero Wing Referenz ... :-))
rmunn
Das war auch für mich das Problem. Derzeit ist dies noch nicht behoben oder zumindest noch nicht veröffentlicht oder der Fehler wurde erneut eingeführt (Version 15.4.2)
avidenic
12

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.

Stijn
quelle
Ich verstehe, was Sie meinen, und das ist es wert, für die Zukunft berücksichtigt zu werden, aber die fragliche Quelle ist ein Website-Projekt, keine Klassenbibliothek.
David
Dies ist ein häufiges Problem beim Aufnehmen von Legacy-Code, bei dem ich mich am Kopf kratzt und mich frage, welches Genie beschlossen hat, auf eine DLL aus einem Projekt in der Lösung zu verweisen, die immer nur von einem anderen Projekt in der Lösung verwendet wird. Seufzer
Kell
10

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

Mehrdad Babaki
quelle
7

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.

Tomi
quelle
Ich kann das nicht genug +1. Ich habe kürzlich Windows neu installiert und nicht bemerkt, dass meine Systemuhr ausgeschaltet war. Sicher genug, diese Änderung hat alles vermasselt und durch den Wiederaufbau der gesamten Lösung / des gesamten Projekts auf magische Weise behoben.
Kyle Baran
7

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.

JBSnorro
quelle
Ich hatte genau das gleiche Problem. Ihre Antwort hat mir geholfen! Vielen Dank! +1
Jweyrich
5

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 )

FrankyHollywood
quelle
Mit Build-> Clean Solution sollten auch die zu entfernenden Dateien entfernt werden.
Dave
Nach einem enormen Zeitverlust aufgrund dieses Problems machte diese Lösung den Trick. Thx FrankyHollywood
AD
4

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.

Stijn
quelle
4

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.

baker.nole
quelle
3

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.

mikeTheLiar
quelle
3

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.

Stijn
quelle
3

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.

Anzeigename
quelle
Es ist auch erwähnenswert, dass Sie (nach dem Starten des Hauptprojekts) dies tun können, wenn sich Ihr Haltepunkt in einem Projekt befindet, das NICHT Ihr Startprojekt ist, und es NICHT zu Ihrem Startprojekt gemacht werden kann (weil Sie beispielsweise ein anderes Projekt als Startprojekt benötigen). Klicken Sie mit der rechten Maustaste und wählen Sie Debug >> Neue Instanz des Projekts starten , dessen Haltepunkt Sie erreichen möchten
Caius Jard
3

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.

nurettin
quelle
3

Für mich war die Lösung in Advanced Build Settingsden Projekteigenschaften versteckt : Geben Sie hier die Bildbeschreibung ein

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.

Riqitang
quelle
3

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

Priyankara
quelle
2

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.

leiser Ton
quelle
In meinem Fall habe ich an w3wp.exe angehängt, um .NET-Code zu debuggen, aber aus irgendeinem Grund wurde der Script-Debugger angehängt, der meine C # -Haltpunkte nicht sehen konnte. Durch das Ändern in den .NET-Debugger konnten meine C # -Haltpunkte funktionieren.
Oran Dennison
2

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.

Julen
quelle
2

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.

John
quelle
2
Vielleicht hat die Wahl der CPU überhaupt keinen Einfluss auf das Problem und es ist nur die Tatsache, dass ein Neuaufbau erzwungen wird?
JWG
Es wird einen anderen bin-Ordner verwenden, wahrscheinlich war eine alte DLL in Ihrer CPU-Karte.
Carra
Ich hatte dieses Problem während der aktiven Plattform x86 (die ich nie verwendet habe). Durch das Zurückschalten auf Win32 wurde das Problem behoben. Der PC ist ein gemeinsam genutzter PC, sodass jemand anderes diese Plattform aus irgendeinem Grund eingerichtet hat.
Zac
2

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 .

Pete
quelle
1
Hier kann es vorkommen, dass sich Ihre Release-Konfiguration von x32 auf x64 ändert, wenn Sie den Kompatibilitätsmodus deaktivieren, und möglicherweise nicht alle Projekte für die Erstellung in x32 ausgewählt sind. Warum bestimmte Projekte für die Erstellung in x32 deaktiviert sind, müssen Sie mit Ihren Teammitgliedern besprechen.
Asad Saeeduddin
Das war genau mein Problem. Vielen Dank!
Johan Holtby
2

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

Teoman Shipahi
quelle
2

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!

Sarah
quelle
2

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
Laurian
quelle
Vielen Dank für diese Lösung! Keiner hat vorher funktioniert, und das hat mir den Tag gerettet :)
StefanaB
2

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

Komm herein
quelle