Ich habe gerade ein Upgrade von Visual Studio 2013 auf 2015 durchgeführt und habe jetzt Probleme mit Haltepunkten.
Es ist ein Treffer oder ein Fehler, bei dem Haltepunkte tatsächlich funktionieren, und wenn ich beim Debuggen einen festlege, wird folgende Fehlermeldung angezeigt:
Der Haltepunkt konnte nicht gebunden werden.
Jede Hilfe wäre dankbar. Ich bin bereit, 2015 aufzugeben und zurückzukehren.
Antworten:
Ich hatte das gleiche Problem, aber eine andere Lösung. Bitte beachten Sie, dass ich auf VS 2015 Update 1 aktualisiert habe und das Problem weiterhin besteht.
In der vorherigen Ausgabe von VS löste das Starten des Debugs automatisch einen Build im Debug-Modus aus. Bei VS2015 ist dies jedoch nicht der Fall.
Wenn sich Ihr letzter Build im Release-Modus befand und Sie versuchen, Fehler zu beheben, funktioniert der Haltepunkt nicht.
Sie müssen zuerst manuell im Debug-Modus erstellen und dann mit dem Debuggen beginnen.
Ich hatte das gleiche Problem.
Ich habe das Problem gelöst, indem die Option "Code optimieren" auf der Registerkarte "Projekteigenschaften" deaktiviert wurde.
Dies mag trivial erscheinen, aber nach vielen Headscratchings mit den gleichen Problemen, die Sie erwähnt haben, stellte ich fest, dass mein Build auf "Release" anstatt auf "Debug" eingestellt war, als ich versuchte zu debuggen. Die Lösung für "Debug" neu zu erstellen "behoben, und ich konnte Haltepunkte wie gewohnt setzen
Ich hatte ein ähnliches Problem mit nicht bindenden Haltepunkten sowie bestimmten lokalen Variablen, die im Fenster "Lokale" nicht ausgewertet wurden. Was schließlich behoben wurde, war die Aktivierung der Option "JIT-Optimierung beim Laden des Moduls unterdrücken (nur verwaltet)" auf der Registerkarte Optionen-> Debug-> Allgemein. Sobald ich festgelegt habe, dass es ohne Probleme binden konnte.
Ich hatte dieses Problem. Ich habe eine Sitzung zur Leistungsprofilerstellung ausgeführt, bei der die Web.configDatei mit den Einstellungen für den Leistungsmonitor geändert wurde :
<appSettings>
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>
<compilation debug="true" targetFramework="4.5"
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
...
</compilation>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
</dependentAssembly>
</assemblyBinding>
</runtime>Dies brach meine Fähigkeit, an Haltepunkten anzuhalten. Als ich zur ursprünglichen Web.config zurückkehrte (die Performance Profiler-Einstellungen wurden entfernt), funktionierten die Haltepunkte wieder.
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>
Ich hatte gestern das gleiche Problem. Ich habe die Funktion "Lösung reinigen" verwendet und sie hat geholfen.
Die Lösung besteht darin, die Entwurfsoptimierung zu deaktivieren.
Project Properties> Build> Advanced Compile Options> Enable Optimizations
Ich führe Leistung auf meiner Lösung aus und das fügte dies meiner web.config hinzu
<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> Das assemblyPostProcessorTypeist das Problem, ich habe es gelöscht und das hat mein Problem gelöst
Ändern Sie den Release-Modus in Debug. In meinem Fall wurde mein Problem dadurch behoben.
Ich habe die Einstellung "Optimieren" nicht geändert, aber basierend auf anderen Antworten hier habe ich
Bisher hat das für mich behoben. Das Update auf VS2015 Update 2 scheint ein paar Dinge auf meinem System gestört zu haben.
Ich weiß, dass dies ein alter Beitrag ist, aber falls alle anderen oben genannten Tricks für Sie nicht funktionieren, stellen Sie sicher, dass das Image, das Sie debuggen möchten, aktuell ist. Aus irgendeinem Grund wurden nach dem Veröffentlichen und Übertragen eines .NET Core-Projekts auf meinen Raspberry Pi 'unzip' auf dem RPi einige DLLs im Arbeitsverzeichnis nicht kopiert und überschrieben. Als ich den Debugger anhängte und dachte, alles sei in Ordnung, wurden einige Haltepunkte erreicht, andere nicht und einige andere gaben mir den Fehler "Kann nicht binden". Nachdem ich das Entpackungsproblem behoben hatte, kamen alle meine Haltepunkte und Symbole zurück. Ich hoffe das hilft.
Ich bin heute auf die Bindungsbruchpunktfehler gestoßen. Und ich habe mein Problem gelöst, indem ich unten war.
Wenn Ihre Debug-Konfigurationen nicht korrekt sind, können Sie das folgende Problem nicht beheben.
Vielleicht hilft diese Lösung jemandem.
Ich hatte das gleiche Problem, hatte aber nicht bemerkt, dass "Debug" in der Debug-Symbolleiste (normalerweise direkt unter dem Menü) in "Release" geändert wurde. Also habe ich es auf "Debug" gesetzt, es hat funktioniert.
Das neue Update für Microsoft Visual Studio 2015 Update 3 (KB3165756) hat das Haltepunktproblem für mich behoben, bei dem ich versuche, die lokalen Variablen in C # -Code zu überprüfen, die in cshtml-Dateien in ASP.NET Core-Anwendungen eingebettet sind.
SCHRITT 1: Schließen Sie das Offensichtliche aus:
SCHRITT 2 Für C ++ - Projekte:
Überprüfen Sie die folgenden Projekteigenschaften:
Führen Sie Schritt 1 erneut aus
Sie können versuchen, __debugbreak () hinzuzufügen. Diese Anweisung muss sich in Ihrer Quelldatei befinden, in der Sie brechen möchten.
SCHRITT 2 Für C # -Projekte:
Versuchen Sie, Ihre Lösung auf einem anderen Computer zu öffnen. Wenn Sie einen Haltepunkt auf einem anderen Computer binden können, kann dies bedeuten, dass ein Problem mit Ihrem VS oder Ihrem Betriebssystem vorliegt.
SCHRITT 3: Stellen Sie sicher, dass Ihr VS auf dem neuesten Stand ist:
Es gab Berichte über solche Probleme im VS2013 RTM sowie im VS2015 Update 1 und Update 2.
Gehen Sie in VS zu Tools / Erweiterungen und Updates / Updates / Produktupdates und sehen Sie, welche Version Sie ausführen. Wenn ein Update benötigt wird, wird es dort angezeigt.
SCHRITT 4: Stellen Sie sicher, dass Ihr Betriebssystem auf dem neuesten Stand ist:
Wenn Sie ein Win 10-Betriebssystem ausführen, wurde ein Fehler in Bezug auf dieses Problem gemeldet, der in Build 14251 aufgetreten ist. Dieser Fehler wurde in Build 14257 (und höher) behoben.
Ich bin gerade auf ein ähnliches Problem gestoßen, und keine der Antworten hier traf auf das Problem, mit dem ich konfrontiert war. Anders als in der Frage erhalte ich jedoch nie eine Nachricht, dass die Bindung fehlgeschlagen ist. Der Haltepunkt trifft einfach nie. Hoffentlich ist dies hilfreich für jemanden in der Zukunft, der mit WCF seinen Kopf gegen die Wand schlägt.
TL / DR:
In der SOAP-Nachricht gab es einen Datensatz mit fehlerhaften Daten, der dazu führte, dass der Haltepunkt nicht getroffen wurde.
Ganze Geschichte:
Ich habe einen WCF-Dienst basierend auf WSDL von einem anderen Team. Nicht meine Definition, keine Kontrolle darüber ... Ich erhalte über diesen Service Nachrichten von diesem anderen Team. In meinem Fall erhalte ich Nachrichten, kann die Nachricht in der Nachrichtenprotokolltabelle in der Datenbank protokollieren (was vor dem Aufruf meiner Dienstmethode geschieht), die Dienstmethode wird anscheinend aufgerufen (möglicherweise nicht) und der Server antwortet mit a 202 Akzeptiert. Die Kommunikation funktioniert, außer dass während des Methodenaufrufs keine Daten in der Datenbank gespeichert werden.
Da der Service eine erfolgreiche Antwort zurückgibt, habe ich http- und transportbezogene Probleme ausgeschlossen.
Also habe ich VS2015 gestartet, um den Dienst zu debuggen. Die fragliche Nachricht ist groß, aber innerhalb der Grenzen dessen, was ich erwarten würde. Ich habe einen Haltepunkt in die erste Zeile der Dienstmethode gesetzt und die große Nachricht durchgeschickt, aber der Haltepunkt wurde nie erreicht. Ich habe eine kleinere Nachricht ausprobiert, von der ich wusste, dass sie auf derselben Ausführungsinstanz funktioniert, und der Haltepunkt wurde einwandfrei erreicht. Also schien alles in der Konfiguration in Ordnung zu sein. Ich dachte, vielleicht liegt etwas in der Nachrichtengröße.
Ich habe alles versucht, was ich finden konnte - sicherstellen, dass ich mich in einer Debug-Konfiguration befand, bereinigen und neu erstellen, den Debugger manuell an den w3wp-Prozess (der VS bereits war) anhängen und verwenden Debugger.Break() anstelle eines Haltepunkts mehrere Startprojekte und mein Testprojekt entladen Damit war das Dienstprojekt das einzige, das .NET aktualisiert, VS2015 neu startet, neu startet, von lokalem IIS zu IIS Express und zurück wechselt und den Dienst mit der garantierten neuesten WSDL neu erstellt. Nichts war wichtig. Der Haltepunkt wurde nie erreicht.
Am Ende musste ich die Datensätze in der großen Nachricht einzeln aussortieren, bis ich einen einzelnen Datensatz mit schlechten Daten fand. In meinem Fall war es ein Datensatz, der keinen Wert für 2 DateTime-Felder hatte. Als ich eine Nachricht mit nur diesem Datensatz erstellt und gesendet habe, wurde der Haltepunkt nicht erreicht. Als ich Werte für diese 2 DateTime-Felder angegeben und dieselbe (feste) Nachricht im Haltepunkt gesendet habe, wurde sie wie erwartet ausgelöst.
Ich hatte jede einzelne CLR-Ausnahme aktiviert, nichts anderes als fehlende .pbd-Dateien, die mir egal waren. WCF schickte die Anfrage glücklich mit einer schlechten Aufzeichnung durch. Ich sage nicht, dass WCF es aufgrund der Verträge nicht hätte durchschicken sollen, nur dass die schlechte Aufzeichnung dazu geführt hat, dass der Haltepunkt nicht erreicht wurde.
Ich musste die Datei web.config ändern, um das Debuggen zu aktivieren. Ändere das:
<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>zu:
<compilation debug="true"/>Reinigen Sie die gesamte Lösung, bevor Sie eine der anderen Lösungen ausprobieren. Nachdem Sie fast alles versucht haben, was in früheren Antworten gesagt wurde, und Visual Studio mehrmals neu gestartet haben, hat es den Trick getan, nur die Lösung zu reinigen!
Ich habe alles versucht, was hier vorgeschlagen wurde. Schließlich setze ich die "Spezifische Seite" in Projekteigenschaften -> Web auf meine lokale Start-URL, Seite und Abfrageparameter. Habe im Debug-Modus bereinigt und neu erstellt und es hat meinen Haltepunkt erreicht.
Obwohl dies ein viel späterer Build ist (VS2017), hatte ich dieses Problem mit C # -Projekten. Versucht zu reinigen, wieder aufzubauen, Visual Studio neu zu starten, etc.
Das Problem wurde behoben, indem Visual Studio geschlossen und der Ordner .vs gelöscht wurde, bei dem es sich um einen versteckten Ordner im Lösungsverzeichnis handelt. Das Löschen des .vs-Ordners sollte keine Probleme verursachen, obwohl Sie Ihr Startprojekt zurücksetzen müssen.
Ich habe mir die vorherigen Antworten angesehen und @ Wills Answear hat das Hauptproblem behoben, das ich hatte. Der andere konnte bearbeiten und fortfahren, aber als ich mir die AssemblyInfo.cs-Datei genauer ansah, fand ich heraus, dass einige Debugging-Funktionen deaktiviert waren.
Dann entfernte ich alte Debug-Attribute und fügte Folgendes hinzu, das ich aus einem anderen Projekt übernommen hatte
#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endifIch bin jedoch der Meinung, dass dies nicht der beste Weg ist, dies zu tun.