Powiązanie punktu przerwania nie powiodło się - Visual Studio 2015

158

Właśnie zaktualizowałem program Visual Studio 2013 do 2015 i teraz mam problem z punktami przerwania.

To trafienie lub chybienie, w którym punkty przerwania faktycznie zadziałają i jeśli ustawię je podczas debugowania, otrzymuję błąd:

Powiązanie punktu przerwania nie powiodło się.

Każda pomoc będzie mile widziana. Jestem gotów zrezygnować z 2015 roku i wrócić.

Sealer_05
źródło

Odpowiedzi:

226

Miałem ten sam problem, ale inne rozwiązanie. Pamiętaj, że zaktualizowałem do VS 2015 Update 1 i problem nadal występuje.

W poprzedniej edycji VS rozpoczęcie debugowania automatycznie wyzwalało kompilację w trybie debugowania. Ale w przypadku VS2015 tak nie jest.

Więc jeśli ostatnia kompilacja była w trybie wydania i spróbujesz debugować, punkt przerwania nie zadziała.

Najpierw musisz ręcznie zbudować w trybie debugowania, a następnie rozpocząć debugowanie.

Max Favilli
źródło
3
Czy to nie dziwne zachowanie? Czy można to uznać za błąd?
Tolga Evcimen
Zainstalowanie aktualizacji dla programu Microsoft Visual Studio 2015 Update 3 (KB3165756) rozwiązało problem z debugowaniem, w którym poprzednio wyświetlany był komunikat „Nie udało się powiązać punktu przerwania”. błąd w
hem
2
To było naprawdę dobre :) Zapomniałem o aktywnej kompilacji wydania i miałem bardzo dziwną sesję debugowania, dopóki tego nie przeczytałem. Pamiętam, żebym ponownie aktywował debugowanie i wszystko jest „normalne”.
Powtórz Spacer
1
Miałem dziwne doświadczenie. Musiałem ustawić kompilację na „Release”, build, następnie „Debug” i ponownie budować.
samneric
@TolgaEvcimen Biorąc pod uwagę, że po ponad 2 latach od VS 15.5.6 zachowanie jest nadal takie samo, powiedziałbym, że MS nie uważa tego za błąd. Osobiście uważam, że bardziej logiczne byłoby przywrócenie starego zachowania automatycznego wyzwalania kompilacji debugowania. Albo przynajmniej daj ostrzeżenie.
Max Favilli
82

Miałem ten sam problem.

Rozwiązałem to wyłączając opcję „Optymalizuj kod” we właściwościach projektu na karcie Build.

Edu_LG
źródło
Problem nadal kończył się powrotem na jednym z moich projektów. W każdym razie, aktualizacja 1 jest już dostępna, więc mam nadzieję, że wszystko wyczyści visualstudio.com/en-us/news/vs2015-update1-vs.aspx
Sealer_05
2
Czy nie o to chodzi w kompilacji debugowania? Odradzałbym kompilację wydania z wyłączoną opcją „Optymalizuj kod”.
Bart Friederichs
Kiedy spojrzałem na Menedżera konfiguracji, przełączyłem się na debugowanie w celu rozwiązania i odkryłem, że niektóre projekty były nieprawidłowo ustawione na wydanie. Oznacza to, że wybranie debugowania z listy rozwijanej spowoduje, że te projekty będą używać konfiguracji wydania, co oznacza optymalizację.
AaronLS
39

Może się to wydawać trywialne, ale po wielu problemach z tymi samymi problemami, o których wspomniałeś, dowiedziałem się, że moja kompilacja została ustawiona na „wydanie” zamiast „debugowania”, kiedy próbowałem debugować .. przebudować rozwiązanie dla „debugowania” „naprawiłem to i mogłem normalnie ustawić punkty przerwania

Kenneth Møller
źródło
2
To pozwoliło mi ustawić punkty przerwania, ale nie trwało wiecznie. Nadal mam problemy z debugowaniem, wciąż pomijam losowe wiersze kodu
Sealer_05
Ten problem utrzymuje się pomimo wszystkich jednorazowych, tymczasowych raportów o sukcesach dla bardzo różnych rozwiązań. Jednak ta konkretna „poprawka” musi być umieszczona obok siebie, „jeśli komputer jest podłączony”. To naprawdę nie jest rozwiązanie. Tak, potrzebujesz mocy i tak, nie możesz ustawić punktów przerwania w kompilacji wydania - rany.
Rick O'Shea
@Kenneth Møller Jak wspomniałeś, może wydawać się to banalne, ale rozwiązało również mój problem.
Ben Junior
36

Miałem podobny problem z punktami przerwania, które nie wiązały się, a także z niektórymi zmiennymi lokalnymi, które nie były oceniane w oknie Lokalne. Ostatecznie naprawiło to włączenie opcji „Wstrzymaj optymalizację JIT przy ładowaniu modułu (tylko zarządzany)” w zakładce Opcje-> Debugowanie-> Ogólne. Kiedyś ustawiłem, że był w stanie związać się bez problemu.

Będzie
źródło
Próbowałem, ale nadal nie trafiałem w punkty przerwania w moich kontrolerach API.
Sealer_05
Istnieje dobre wyjaśnienie debugowania za pomocą zoptymalizowanego kodu tutaj
Nathan
Nie, to nie jest rozwiązanie. To, co otrzymujemy, to ludzie losowo poprawiający przełączanie, które nie ma wpływu na problem, który wydaje się znikać samoczynnie
Rick O'Shea,
Wreszcie. Pozwoliło mi to również przejść przez kod, nad którym wcześniej przeskakiwano.
Jeff Davis,
To dla mnie rozwiązało problem w VS 2019, bardzo dziękuję!
EM0
14

Miałem ten problem. Przeprowadziłem sesję profilowania wydajności, w której zmodyfikowałem Web.configplik z ustawieniami monitora wydajności:

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

To zepsuło moją zdolność do zatrzymywania się w punktach przerwania. Kiedy wróciłem do oryginalnego Web.config (usunąłem ustawienia Performance Profiler), punkty przerwania zaczęły ponownie działać.

Allbite
źródło
1
To było dla mnie rozwiązanie po profilowaniu w VS 2017. Wielkie dzięki.
Lee Taylor
1
Wygląda na to, że istnieje wiele przyczyn niepowodzenia wiązania punktów przerwania, ale to jest ten, który widzieliśmy.
BJury
2
To było to dla mnie. <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>
Usunąłem
5

Wczoraj miałem ten sam problem. Użyłem funkcji „Czyste rozwiązanie” i pomogło.

kerneldebugger
źródło
3
To prawie jak centrum komedii. Czekam na „Machnąłem gumowym kurczakiem nad maszyną i to zadziałało”. Mamy pół tuzina programistów, którzy doświadczyli tego problemu i żadne z tych magicznych, pozbawionych wyjaśnień rozwiązań ad hoc nie działa.
Rick O'Shea
5

rozwiązaniem jest wyłączenie optymalizacji projektu.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

Julio Chiuchi
źródło
4

Uruchomiłem wydajność na moim rozwiązaniu i dodałem to do mojego pliku web.config

<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"/> 

To assemblyPostProcessorTypejest problem, usunąłem go i to rozwiązało mój problem

xszaboj
źródło
4

Zmień tryb wydania na debugowanie, w moim przypadku to rozwiązało mój problem.

wprowadź opis obrazu tutaj

Irshad Ahmed Akhonzada
źródło
1

Nie zmieniłem ustawienia „optymalizacji”, ale w oparciu o inne odpowiedzi tutaj, ja

  1. Ustaw Eksplorator rozwiązań, aby wyświetlić wszystkie pliki projektu
  2. Usunięto ukryty kosz i foldery debugowania
  3. Wykonano „czyszczenie” projektu
  4. Wykonano „Przebuduj” w projekcie

Jak dotąd to rozwiązało problem. Wygląda na to, że aktualizacja do VS2015 Update 2 zepsuła kilka rzeczy w moim systemie.

louisik1
źródło
1

Wiem, że to stary post, ale jeśli wszystkie inne sztuczki powyżej nie działają, upewnij się, że obraz, który próbujesz debugować, jest aktualny. Z jakiegoś powodu po opublikowaniu i przesłaniu projektu .NET Core do mojego Raspberry Pi 'unzip' na RPi nie kopiował i nie nadpisywał niektórych bibliotek DLL w katalogu roboczym. Kiedy podłączyłem debugger, myśląc, że wszystko jest w porządku, niektóre punkty przerwania zostały trafione, inne nie, a inne dawały mi błąd „nie można związać”. Po rozwiązaniu problemu z rozpakowaniem wróciły wszystkie moje punkty przerwania i symbole. Mam nadzieję, że to pomoże.

Brian Clever
źródło
0

Napotkałem dziś błędy punktu przerwania wiązania. I rozwiązałem swój problem, robiąc poniżej.

Jeśli wszystkie konfiguracje debugowania nie są poprawne, nie możesz rozwiązać problemu, wykonując poniższe czynności.

  1. Czysty projekt
  2. Jeśli ścieżka wyjściowa różni się od folderu bin, zamień ją na folder bin (jest to najważniejsza zasada)
  3. Odbudować

Może to rozwiązanie komuś pomoże.

RockOnGom
źródło
0

Punkty przerwania VS nie mogą wiązać się z metodami asynchronicznymi.

Miałem zainstalowanego agenta App Dynamics, który to spowodował. Usuń to i jesteś gotowy.

Dani
źródło
0

Miałem ten sam problem, ale nie zdawałem sobie sprawy, że na pasku narzędzi debugowania (zwykle bezpośrednio pod menu) zmieniono opcję „Debugowanie” na „Wersja”. Więc ustawiłem go na "Debugowanie", to zadziałało.

Jared McCracken
źródło
0

KROK 1, wyklucz oczywiste:

  • Kompiluj w trybie debugowania.
  • Spróbuj wyczyścić rozwiązanie przed ustawieniem punktu przerwania.
  • Przejdź do folderu Debug i usuń plik [Twoja aplikacja] .pdb.
  • Następnie wykonaj kompilację lub przebudowę aplikacji.
  • Przejdź do folderu Debug i potwierdź, że masz nowy plik .pdb [Twoja aplikacja].
  • Następnie spróbuj ustawić swój punkt przerwania.

KROK 2 Dla projektów C ++:

Sprawdź następujące właściwości projektu:

  • C ++ / General / Debug Information Format: Baza danych programów.
  • C ++ / Optimization: Disabled.
  • C ++ / generowanie kodu / biblioteka uruchomieniowa: debugowanie wielowątkowe.
  • Konsolidator / debugowanie / generowanie informacji debugowania: tak.
  • Konsolidator / debugowanie / generowanie bazy danych programu: $ (TargetDir) $ (TargetName) .pdb.
  • Linker / plik manifestu / wygeneruj manifest: Nie.
  • Linker / plik manifestu / zezwalaj na izolację: Nie.
  • Linker / Wbudowany IDL / Ignoruj ​​osadzony IDL: Tak.
  • Wykonaj ponownie krok 1

    Możesz spróbować dodać __debugbreak (). Ta instrukcja musi znaleźć się w pliku źródłowym, w którym chcesz przerwać.

KROK 2 Dla projektów C #:

  • We właściwościach projektu Build / General / Optimize należy wyłączyć kod.
  • W ustawieniach IDE Debug / Options and Settings / Debugging / General Suppress JIT Optimization at module load (Managed only): Enabled
  • Wykonaj ponownie krok 1

Spróbuj otworzyć swoje rozwiązanie na innym komputerze. Jeśli możesz powiązać punkt przerwania na innym komputerze, może to oznaczać, że wystąpił problem z twoim VS lub systemem operacyjnym.

KROK 3, upewnij się, że Twój VS jest aktualny:

Pojawiły się zgłoszenia takich problemów w VS2013 RTM, a także w VS2015 Update 1 i Update2.

W VS przejdź do Narzędzia / Rozszerzenia i aktualizacje / Aktualizacje / Aktualizacje produktów i zobacz, jakiej wersji używasz. Jeśli aktualizacja jest potrzebna, pojawi się tam.

KROK 4, upewnij się, że Twój system operacyjny jest aktualny:

Na koniec, jeśli korzystasz z systemu operacyjnego Win 10, zgłoszono błąd dotyczący tego problemu, który istniał w kompilacji 14251. Został on rozwiązany w kompilacji 14257 (i nowszych).

Merav Kochavi
źródło
0

Właśnie natknąłem się na podobny problem i żadna z odpowiedzi tutaj nie dotyczyła problemu, z którym miałem do czynienia. Jednak w przeciwieństwie do pytania, nigdy nie otrzymałem żadnej wiadomości z informacją, że nie udało się połączyć. Punkt przerwania po prostu nigdy nie trafia. Miejmy nadzieję, że przyda się to komuś w przyszłości waląc głową w ścianę WCF.

TL / DR:
W wiadomości SOAP był rekord z błędnymi danymi, który spowodował, że punkt przerwania nie został trafiony.

Pełna historia:

Mam usługę WCF opartą na WSDL z innego zespołu. Nie moja definicja, brak kontroli ... Otrzymuję wiadomości od innego zespołu za pośrednictwem tej usługi. W moim przypadku otrzymuję wiadomości, mogę zapisać wiadomość do tabeli dziennika komunikatów w bazie danych (co dzieje się przed wywołaniem mojej metody usługi), metoda usługi jest pozornie wywołana (może nie jest), a serwer odpowiada a 202 Zaakceptowano. Komunikacja działa, ale żadne dane nie są zapisywane w bazie danych podczas wywołania metody.

Ponieważ usługa zwraca odpowiedź o powodzeniu, wykluczyłem http i problemy z transportem.

Więc odpaliłem VS2015, aby debugować usługę. Komunikat, o którym mowa, jest duży, ale mieści się w granicach tego, czego bym się spodziewał. Położyłem punkt przerwania w pierwszym wierszu metody usługi i wysłałem duży komunikat, ale punkt przerwania nigdy nie trafił. Wypróbowałem mniejszą wiadomość, o której wiedziałem, że działa na tej samej instancji uruchamiania i punkt przerwania został trafiony w porządku. Więc wszystko w konfiguracji wydawało się w porządku. Pomyślałem, że może coś jest w rozmiarze wiadomości.

Wypróbowałem wszystko, co mogłem znaleźć - upewniając się, że jestem w konfiguracji debugowania, wyczyść i odbuduj, ręcznie dołączając debuger do procesu w3wp (którym już był VS), używając Debugger.Break()zamiast punktu przerwania, ustawiając wiele projektów startowych, zwalniając mój projekt testowy tak, aby projekt usługi był jedyny, aktualizacja .NET, ponowne uruchomienie VS2015, ponowne uruchomienie, przełączenie z lokalnych usług IIS na IIS Express iz powrotem, odtworzenie usługi z gwarantowanym najnowszym WSDL. Nic się nie liczyło. Punkt przerwania nigdy nie został osiągnięty.

Skończyło się na tym, że musiałem usuwać rekordy w dużej wiadomości jeden po drugim, aż znalazłem pojedynczy rekord, który zawierał złe dane. W moim przypadku był to jeden rekord, który nie miał wartości dla 2 pól DateTime. Kiedy utworzyłem wiadomość zawierającą tylko ten jeden rekord i wysłałem ją, punkt przerwania nie został trafiony. Kiedy podałem wartości dla tych 2 pól DateTime i wysłałem tę samą (ustaloną) wiadomość w punkcie przerwania uruchomioną zgodnie z oczekiwaniami.

Miałem włączony każdy wyjątek CLR, nic nie zostało uruchomione poza brakującymi plikami .pbd, o które nie dbałem. Usługa WCF szczęśliwie wysłała żądanie z złym rekordem. Nie mówię, że WCF nie powinno było go przesyłać na podstawie kontraktów, tylko że zły rekord spowodował, że punkt przerwania nie został osiągnięty.

squillman
źródło
0

Musiałem zmodyfikować plik web.config, aby włączyć debugowanie. Zmień to:

<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"/>

do:

<compilation debug="true"/>
sereschkin
źródło
0

Wyczyść całe rozwiązanie przed wypróbowaniem innych rozwiązań. Po wypróbowaniu prawie wszystkiego, co zostało powiedziane we wcześniejszych odpowiedziach, i kilkukrotnym ponownym uruchomieniu Visual Studio, samo wyczyszczenie rozwiązania załatwiło sprawę!

chaosifier
źródło
0

Wypróbowałem wszystko, co tutaj zasugerowałem. Ostatecznie ustawiłem „Określoną stronę” we właściwościach projektu -> Sieć na mój lokalny początkowy adres URL, parametr strony i zapytania. Czyściłem i przebudowywałem w trybie debugowania i trafiło w mój punkt przerwania.

IrishChieftain
źródło
0

Chociaż jest to znacznie późniejsza kompilacja (VS2017), miałem ten problem z projektami C #. Próbowałem wyczyścić, odbudować, ponownie uruchomić Visual Studio itp.

Rozwiązaniem było zamknięcie programu Visual Studio i usunięcie folderu .vs, który jest ukrytym folderem znajdującym się w katalogu rozwiązania. Usunięcie folderu .vs nie powinno spowodować żadnych problemów, chociaż będziesz musiał zresetować projekt startowy.

ChrisBeamond
źródło
0

W moim przypadku po użyciu utworzono nowy plik web.config Profiler. Przywrócenie pliku web.config do poprzedniej wersji rozwiązało ten problem. Była to aplikacja internetowa w języku VS2015 w języku C #.

orła
źródło
0

W przypadku, gdy publikujesz swoją aplikację internetową, sprawdzenie, które Configurationjest ustawione na Debug(domyślnie w konfiguracji debugowania jest ustawione tak, że kod nie jest zoptymalizowany, a tablica symboli jest w pełni utworzona).wprowadź opis obrazu tutaj

VSB
źródło
-1

Spojrzałem w poprzednich odpowiedziach i @ Willa answear stałe główny problem miałem, drugi jest w stanie edytować i kontynuować ale biorąc bliżej przyjrzeć się plik AssemblyInfo.cs znalazłem niektóre debugowanie wyposażony gdzie wyłączona.

Następnie usunąłem stare atrybuty debugowania i dodałem następujące, które wziąłem z innego projektu

#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

Jednak czuję, że nie jest to najlepszy sposób na zrobienie tego.

Raldo94
źródło