Ik heb zojuist een upgrade uitgevoerd van Visual Studio 2013 naar 2015 en nu heb ik problemen met onderbrekingspunten.
Het is een hit of een misser waarbij breekpunten echt werken en als ik er een instel tijdens het debuggen krijg ik de foutmelding:
Het breekpunt kon niet binden.
Alle hulp wordt op prijs gesteld. Ik sta op het punt om 2015 op te geven en terug te gaan.
Antwoord 1, autoriteit 100%
Ik had hetzelfde probleem, maar een andere oplossing.
Let op: ik heb geüpdatet naar VS 2015 Update 1 en het probleem is er nog steeds.
In de vorige editie van VS activeerde het starten van debug automatisch een build in debug-modus. Maar met VS2015 niet.
Dus als je laatste build in de release-modus was en je probeert te debuggen, werkt het breekpunt niet.
Je moet handmatig in de foutopsporingsmodus bouwen en dan beginnen met foutopsporing.
Antwoord 2, autoriteit 34%
Ik had hetzelfde probleem.
Ik heb het opgelost door de optie “Optimaliseer code” uit te schakelen in de projecteigenschappen Build-tabblad.
Antwoord 3, autoriteit 18%
Dit lijkt misschien triviaal, maar na veel hoofdbrekens met dezelfde problemen als je noemt, kwam ik erachter dat mijn build was ingesteld op “release” in plaats van “debug” toen ik probeerde te debuggen.. de oplossing opnieuw bouwen voor “debug” repareerde het, en ik kon breekpunten instellen als normaal
Antwoord 4, autoriteit 15%
Ik had een soortgelijk probleem met breekpunten die niet konden binden, evenals bepaalde lokale variabelen die niet werden geëvalueerd in het venster Locals. Wat het uiteindelijk heeft opgelost, was het inschakelen van de optie “Onderdruk JIT-optimalisatie bij het laden van modules (alleen beheerd)” op het tabblad Opties->Debug->Algemeen. Toen ik dat eenmaal had ingesteld, kon het zonder problemen binden.
Antwoord 5, autoriteit 6%
Ik had dit probleem. Ik heb een prestatieprofileringssessie uitgevoerd die het bestand Web.config
heeft gewijzigd met instellingen voor de prestatiemonitor:
<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>
Dit verbrak mijn vermogen om te stoppen bij breekpunten. Toen ik terugging naar de originele Web.config (de Performance Profiler-instellingen verwijderd), begonnen de onderbrekingspunten weer te werken.
Antwoord 6, autoriteit 3%
Verander de release-modus in Debug, in mijn geval heeft dit mijn probleem opgelost.
Antwoord 7, autoriteit 2%
Ik had gisteren hetzelfde probleem. Ik gebruikte de functie “Oplossing opschonen” en het hielp.
Antwoord 8, autoriteit 2%
de oplossing is om de ontwerpoptimalisatie uit te schakelen.
Project Properties> Build> Advanced Compile Options> Enable Optimizations
9
Ik weet dat dit een oude post is, maar voor het geval dat alle andere trucs hierboven niet voor u werken, zorg er dan voor dat de afbeelding die u probeert te debuggen is actueel. Om een of andere reden na het publiceren en overbrengen van een .NET-kernproject naar mijn Raspberry PI ‘unzip’ op de RPI kopieerde en overschreven en overschreven enkele DLL’s in de werkdirectory. Toen ik de debugger bijheen, bleek dat alles in orde was, waren wat breakpoints geraakt, anderen waren niet en sommige anderen gaf me de “Can not binden” -fout. Zodra ik het unzip-probleem heb opgelost, kwamen al mijn breekpunten en symbolen terug. Ik hoop dat dit helpt.
10
vs breakpoints kunnen niet binden op Async-methoden.
Ik had een app-dynamics-agent geïnstalleerd die dit heeft veroorzaakt. Verwijder dat en je bent goed om te gaan.
11
Ik had hetzelfde probleem, maar had niet gerealiseerd dat “debug” was gewijzigd in “ontgrendelen” op de Debug-toolbalk (meestal direct onder het menu). Dus ik heb het ingezet op “debuggen”.
12
De nieuwe update voor Microsoft Visual Studio 2015 update 3 (kb3165756) heeft het breakpoint-probleem voor mij vastgesteld, waar ik probeer de lokale variabelen in C # -code in te inspecteren die zijn ingesloten in CSHTML-bestanden in ASP.NET-kerntoepassingen.
Antwoord 13
Ik kwam net een soortgelijk probleem tegen en geen van de antwoorden hier had betrekking op het probleem waarmee ik werd geconfronteerd. In tegenstelling tot de vraag ontvang ik echter nooit een bericht dat de binding niet is gelukt. Het breekpunt raakt gewoon nooit. Hopelijk is dit nuttig voor iemand die in de toekomst met zijn hoofd tegen de muur bonkt met WCF.
TL/DR:
In het SOAP-bericht was er een record met slechte gegevens waardoor het breekpunt niet werd geraakt.
Volledig verhaal:
Ik heb een WCF-service op basis van WSDL van een ander team. Niet mijn definitie, geen controle over… Ik ontvang berichten van dit andere team via deze dienst. In mijn geval ontvang ik berichten, kan ik het bericht loggen in de berichtenlogboektabel in de database (wat gebeurt voordat mijn servicemethode wordt aangeroepen), de servicemethode wordt schijnbaar aangeroepen (misschien is het niet), en de server reageert met een 202 Geaccepteerd. De communicatie werkt, behalve dat er tijdens de methodeaanroep geen gegevens in de database worden opgeslagen.
Aangezien de service een succesvolle reactie retourneert, heb ik http- en transportgerelateerde problemen uitgesloten.
Dus ik startte VS2015 om de service te debuggen. Het bericht in kwestie is groot, maar ruim binnen de grenzen van wat ik zou verwachten. Ik plaatste een breekpunt op de eerste regel van de servicemethode en stuurde het grote bericht door, maar het breekpunt raakte nooit. Ik probeerde een kleiner bericht waarvan ik wist dat het op dezelfde run-instantie werkte en het breekpunt werd prima bereikt. Dus alles in de configuratie leek in orde. Ik dacht dat er misschien iets in de berichtgrootte zat.
Ik heb alles geprobeerd wat ik kon vinden – ervoor zorgen dat ik in een debug-configuratie zat, opschonen en opnieuw opbouwen, de debugger handmatig aan het w3wp-proces koppelen (wat VS al was), met behulp van Debugger.Break()
in plaats van een breekpunt, meerdere opstartprojecten instellen, mijn testproject uitladen zodat het serviceproject het enige was, .NET bijwerken, VS2015 opnieuw opstarten, opnieuw opstarten, overschakelen van Local IIS naar IIS Express en terug, de service opnieuw creëren met de gegarandeerde laatste WSDL.
Niets deed ertoe. Het breekpunt is nooit bereikt.
Uiteindelijk moest ik de records in het grote bericht een voor een verwijderen totdat ik één record vond met slechte gegevens. In mijn geval was het één record dat geen waarde had voor 2 DateTime-velden. Toen ik een bericht maakte dat alleen dit ene record bevatte en het stuurde, werd het breekpunt niet geraakt. Toen ik waarden opgaf voor die 2 DateTime-velden en hetzelfde (vaste) bericht in het breekpunt stuurde, zoals verwacht.
Ik had elke CLR-uitzondering ingeschakeld, er werd niets anders geactiveerd dan ontbrekende .pbd-bestanden, waar ik niet om gaf. WCF heeft het verzoek met een slechte staat van dienst graag doorgestuurd. Ik zeg niet dat WCF het niet had moeten doorsturen op basis van de contracten, alleen dat het slechte record ervoor zorgde dat het breekpunt niet werd bereikt.
Antwoord 14
Ik moest het bestand web.config wijzigen om foutopsporing in te schakelen. Wijzig dit:
<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"/>
naar:
<compilation debug="true"/>
Antwoord 15
Schoonde hele oplossing voordat u een van de andere oplossingen probeert. Na bijna al het andere te hebben geprobeerd dat in eerdere antwoorden is gezegd, en visual studio meerdere keren opnieuw te hebben opgestart, was het opschonen van de oplossing voldoende!
Antwoord 16
Ik heb alles geprobeerd wat hier wordt voorgesteld. Uiteindelijk heb ik de “Specifieke pagina” in Projecteigenschappen -> Web naar mijn lokale start-URL, pagina en queryparameter. Heb schoongemaakt en opnieuw opgebouwd in debug-modus en het raakte mijn breekpunt.
Antwoord 17
Hoewel dit een veel latere build is (VS2017), had ik dit probleem met C#-projecten. Geprobeerd op te schonen, opnieuw op te bouwen, visual studio opnieuw op te starten, enz.
Wat het probleem oploste, was het sluiten van Visual Studio en het verwijderen van de .vs-map, een verborgen map in de oplossingsmap. Het verwijderen van de .vs-map zou geen problemen moeten opleveren, hoewel je je opstartproject moet resetten.
Antwoord 18
In mijn geval was er een nieuw web.config-bestand gemaakt nadat ik Profiler
had gebruikt. Door web.config naar de vorige versie te herstellen, is dit probleem opgelost. Het was een VS2015 C#-webtoepassing.
Antwoord 19
Ik heb de vorige antwoorden bekeken en @Will’s answearloste het belangrijkste probleem op dat ik had, het andere kon bewerk en ga verder, maar toen ik het bestand AssemblyInfo.cs nader bekeek, ontdekte ik dat enkele foutopsporingsfuncties waren uitgeschakeld.
Toen heb ik uiteindelijk oude debug-attributen verwijderd en het volgende toegevoegd dat ik van een ander project had overgenomen
#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)]
#endif
Toch heb ik het gevoel dat dit niet de beste manier is om het te doen.