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

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

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.

Miałem ten sam problem.

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

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

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.

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

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

rozwiązaniem jest wyłączenie optymalizacji projektu.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

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

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

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.

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.

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.

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.

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.

Nowa aktualizacja dla programu Microsoft Visual Studio 2015 Update 3 (KB3165756) rozwiązała problem z punktem przerwania, w którym próbuję sprawdzić zmienne lokalne w kodzie C # osadzone w plikach cshtml w aplikacjach ASP.NET Core.

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

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.

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

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

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.

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.

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

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

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.