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ć.
Odpowiedzi:
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ć.
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>
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
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.
Może to rozwiązanie komuś pomoże.
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:
KROK 2 Dla projektów C ++:
Sprawdź następujące właściwości projektu:
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 #:
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.
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)]
#endifJednak czuję, że nie jest to najlepszy sposób na zrobienie tego.