„Punkt przerwania nie zostanie obecnie trafiony. Kod źródłowy różni się od oryginalnej wersji. ” Co to znaczy?

Podczas debugowania w Visual Studio czasami dodaję punkt przerwania, ale jest pusty, a VS mówi „Punkt przerwania nie zostanie obecnie trafiony. Kod źródłowy różni się od oryginalnej wersji”. Oczywiście uniemożliwia mi to debugowanie.

Co u licha oznacza to przesłanie? Jaka oryginalna wersja? Jeśli właśnie otworzyłem rozwiązanie i nie wprowadziłem żadnych zmian w kodzie, jak może istnieć „oryginalna wersja”?

Jak mówi „kod źródłowy różni się od oryginalnej wersji”.

Kliknij prawym przyciskiem myszy folder projektu w eksploratorze rozwiązań i wybierz Clean. Zbuduj nową wersję projektu, a punkt przerwania znów będzie działał!

Jeśli odznaczyłeś projekt DLL w konfiguracji kompilacji debugowania , twój nowy kod nigdy nie zostanie skompilowany!

Przejdź do Build --> Configuration Manager ...(w VS2010) i sprawdź, czy projekt z kodem, który próbujesz debugować, jest sprawdzony pod kątem bieżącej konfiguracji kompilacji.

Dla mnie było to podczas pracy nad projektem WebSite. Po wyczyszczeniu tych folderów tymczasowych otrzymałem prawidłowe błędy kompilatora:

• C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
• C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

W końcu rozwiązałem problem, gdy odkryłem, że plik klasy, który celowo przeniosłem do podfolderu, w jakiś sposób pojawił się ponownie w folderze głównym. VS używał tego, gdy ja edytowałem drugi.

Czy kiedykolwiek to zrobiłeś?

Czy chcesz kontynuować i uruchomić ostatnią udaną kompilację?

Jeśli zaznaczysz to pole i naciśniesz „Tak”, uruchomiona zostanie ostatnia udana kompilacja, nawet jeśli projekt się nie skompiluje. Oznacza to, że za każdym razem, gdy ustawisz punkt przerwania, pojawi się ten błąd.

Spróbuj zmienić tę wartość:

• Przybory
  • Opcje
    • Projekty i rozwiązania
      • Kompiluj i uruchamiaj
        • Podczas uruchamiania, gdy wystąpią błędy kompilacji lub wdrażania: Nie uruchamiaj

Iść do

• Przybory
  • Opcje
    • Debugowanie
      • Generał

Odznacz Wymagaj plików źródłowych, aby dokładnie pasowały do ​​oryginalnej wersji

Wybierz opcję Debuguj w konfiguracjach rozwiązań zamiast wersji

Zwróć uwagę na okno „Wyjście” w VS. Powie ci, jakie zestawy są ładowane i kiedy. Możesz zobaczyć, że ładowana jest starsza wersja zestawu gdzieś w folderze.

Na przykład, jeśli masz wiele zestawów i obecnie próbujesz włamać się do jednego z zestawów pomocniczych, CLR zajmie się rozstrzyganiem zestawu, co może spowodować załadowanie innego pliku zestawu niż ten, do którego odwołujesz się w projekcie.

Zamknięcie programu Visual Studio i ponowne otwarcie rozwiązania może rozwiązać problem, tzn. Jest to błąd w samym środowisku IDE (korzystam z VS2010).

Jeśli masz więcej niż jedną instancję programu Visual Studio, wystarczy zamknąć instancję z rozwiązaniem problemu.

Pojawił się nowy sposób rozwiązania tego problemu od wersji Visual Studio 2017 od 15.3.1 do 15.3.5. Jeśli używasz EditorConfig , charset=utf8opcja powoduje te objawy. Zespół VS powtórzył to i powiedział, że nad tym pracuje .

Tak więc jedną poprawką jest skomentowanie charset=utf8linii w pliku .editorconfig.

Edycja: Należy to naprawić od wersji VS 15.5.

Dzieje się tak często również wtedy, gdy używasz odwołań do plików binarnych (zamiast odwołań do projektu do kodu w projekcie), a skompilowany plik binarny, do którego się odwołujesz, nie jest zsynchronizowany z odpowiednim kodem źródłowym na komputerze. Może się to zdarzyć, ponieważ pobrałeś nową wersję pliku binarnego z kontroli źródła bez nowego kodu źródłowego, który był z nim związany, lub masz kilka wersji pliku binarnego na swoim komputerze i odwołujesz się do starej kopii itp. Jeśli tak jest rzeczywiście problem, to dobry powód, aby używać referencji do projektu tak bardzo, jak to praktyczne.

Dla mnie żaden z elementów nie rozwiązał problemu. Właśnie dodałem nową linię kodu wewnątrz tej funkcji, coś w stylu:

int a=0;

dodając to, myślę, że uruchomiłem Visual Studio, aby dodać tę funkcję do oryginalnej wersji

Może się to zdarzyć, gdy czas systemowy zmienia się podczas debugowania lub między sesjami debugowania, czy to programowo, ręcznie czy przez program zewnętrzny.

Jest prawie niedostrzegalne ustawienie, które naprawiło ten problem. Jeśli istnieje określony plik źródłowy, w którym punkt przerwania nie uderza, można go wymienić na liście

• Solution Explorer
  • Kliknij prawym przyciskiem myszy Rozwiązanie
    • Nieruchomości
      • Wspólne właściwości
        • Debuguj pliki źródłowe
          • „Nie szukaj tych plików źródłowych”.

Z nieznanego mi powodu VS 2013 postanowił umieścić tam plik źródłowy, a następnie nie mogłem już przekroczyć punktu przerwania w tym pliku. Może to być przyczyną „kodu źródłowego różni się od wersji oryginalnej”.

Problem polega na tym, że informacje debugowania nie są zsynchronizowane z zestawem. Rozwiązanie jest proste:

1. Przejdź do folderu bin
2. Usuń pliki .pdb
3. Odbudować

Powinien załatwić sprawę!

(dziwne jest to, że przebudowa bez wyrzucania plików .pdb nie zawsze działa. Widzę, że zmodyfikowana data jest aktualizowana, ale wciąż gdzieś w łańcuchu (debuger VS2013, IIS, pamięć podręczna zestawu) ta zmiana nie jest wykrywana )

Możesz otrzymać ten komunikat, gdy używasz aktywatora, a zestaw, w którym ustawiłeś punkt przerwania, nie został jeszcze załadowany.

Punkt przerwania zostanie rozwiązany, gdy aktywator załaduje zestaw (przy założeniu, że symbole zestawu i debugowania są aktualne). Dobrym miejscem do obejrzenia jest okno modułów w menu debugowania. Tam powinieneś poszukać zestawu, do którego należy również twój plik. Najpierw sprawdź, czy zestaw jest załadowany. Skąd to jest ładowane? Następnie ładowany jest plik symboli. Znowu, skąd ładowany jest plik symboli? Na koniec sprawdź wersje obu.

Ja też to spotkałem. Warunki, które spowodowały mój problem:

• Lokalnie uruchamiam pełną instancję IIS7
• Tworzę oprogramowanie w osobnych projektach

Powodowałem to, otwierając poprzednią wersję (VS zapytał, czy chcę wskazać to wystąpienie podczas debugowania IIS, odpowiedziałem „Tak”), a następnie otworzyłem bieżącą wersję (ponownie odpowiadając na monit IIS „Tak” ), a następnie próba debugowania w poprzedniej wersji.

Aby rozwiązać, po prostu zamknąłem i ponownie otworzyłem poprzednią i zamierzoną wersję, ponownie potwierdzając to jako źródło debugowania.

Spróbuj wyłączyć i ponownie ustawić punkt przerwania podczas uruchamiania w trybie debugowania zamiast robić to przed uruchomieniem trybu debugowania.

Dzieje się tak również podczas debugowania projektu C ++, który ładuje moduł, który został zaimplementowany z pewnym językiem CRL (Managed C ++, C # itp.). W tej sytuacji komunikat o błędzie rzeczywiście wprowadza w błąd.

Rozwiązaniem jest umieszczenie właściwości konfiguracji środowiska uruchomieniowego języka wspólnego (CLR) w projekcie startowym i ponowne skompilowanie.

Jeśli masz więcej niż jeden projekt w swoim rozwiązaniu , upewnij się, że poprawny projekt jest ustawiony jako StartUp Project. Aby ustawić konkretny projekt jako projekt startowy swojego rozwiązania, kliknij projekt prawym przyciskiem myszy i wybierz Set As StartUp Project.

Po prawidłowym ustawieniu projektu StartUp projekt wątek osiągnął pożądany punkt przerwania.

Doświadczyłem tego w 32-bitowej wersji vs2017.

Dokładnie żadne z rozwiązań nie działało dla mnie. Zrestartowałem, wyczyściłem pliki IDE, wyczyściłem wbudowane rozwiązanie, wyciągnąłem z repozytorium git i przebudowałem bezskutecznie.

Wciągałem 64-bitową zależność od nugetu i jak tylko użyłem zestawu, źródła nie były już wbudowane w końcowy plik wykonywalny, a zamiast tego budowane były źródła buforowane IDE.

Usunąłem konfigurację nugetu, usunąłem przywoływany zestaw, pobrałem źródło, ręcznie zbudowałem log4net, podpisałem go, dodałem do folderu w moim projekcie, dodałem odniesienie do niego i mogłem ponownie debugować.

To był ból, mam nadzieję, że pojawi się na liście odpowiedzi, aby wszyscy mogli to zobaczyć.

Edycja: Podczas kompilacji nie wystąpił błąd, mimo że w ustawieniach IDE była włączona opcja „monit o kompilację błędu”.

Dla mnie rozwiązanie zostało ukryte we Advanced Build Settingswłaściwościach projektu:

Z nieznanego powodu ustawiono na none: ustawienie nafull powodujące trafienie punktów przerwania.

Aby przejść do tego okna dialogowego, otwórz właściwości projektu, a następnie przejdź do Build, a następnie wybierz Advanced...przycisk u dołu strony.

Miałem ten sam problem w kilku projektach w projekcie architektury warstwowej i problem polegał na konfiguracji, że pole wyboru kompilacji dla wybranego projektu nie zostało zaznaczone. więc problem został rozwiązany dla jednego projektu.

W przypadku jednej innej warstwy powodował ten sam problem, nawet kompilacja jest możliwa w konfiguracjach. Zrobiłem wszystkie inne opcje, takie jak ponowne uruchomienie czyszczenia projektu, ale żadna z nich nie pomogła. Na koniec odznaczyłem pole wyboru kompilacji dla tego konkretnego projektu oraz wyczyściłem i odbudowałem. ponownie zaznaczył pole wyboru i zrobił to samo. wtedy problem został rozwiązany.

Mam nadzieję że to pomoże..

W moim przypadku podłączałem się do uruchomionego procesu w VS 2012. Podczas dołączania masz opcję debugowania w różnych trybach (natywny, skrypt, silverlight, zarządzany 2.0, zarządzany 4.0 itp.). Domyślnie debuger wybiera tryb automatycznie. Jednak Automatic nie zawsze dokonuje właściwego wyboru. Jeśli twój proces zawiera wiele rodzajów kodu, upewnij się, że debugger używa poprawnego.

W moim przypadku opracowywałem aplikację Windows CE, która testowała się na emulatorze. Problem polegał na tym, że plik wykonywalny nie został wdrożony w emulatorze, więc plik .pdb (w środowisku programistycznym) nie był zsynchronizowany z plikiem .exe (w emulatorze), ponieważ nowy plik .exe nigdy nie został skopiowany do emulatora. Musiałem usunąć plik .exe w emulatorze, aby wymusić nowe wdrożenie. Potem zadziałało.

To, co zadziałało, to zmiana platformy rozwiązania z x86 na dowolny procesor. Po zmianie na Any ustawiłem adres stop, uruchomiłem stronę, otworzyłem stronę, kliknąłem przycisk i zatrzymał się. Zamknąłem witrynę, zmieniłem z powrotem na x86 i pomyślnie wykonałem tę samą sekwencję.

W systemie Windows 7 Visual Studio Express 2010, jeśli aktywowano opcję Użyj trybu zgodności dla systemu Windows XP z dodatkiem SP3 , ten błąd może wystąpić.

Odznałem opcję i znów działała idealnie. Kliknij prawym przyciskiem myszy skrót do VS lub pliku wykonywalnego, wybierz właściwości, a następnie zgodność .

Najpierw próbowałem z linii poleceń;

usuwanie plików tymczasowych z wiersza poleceń działało.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Tymczasowe pliki ASP.NET> root rd / s

Kiedy wyłączam „Włącz tylko mój kod” opcję menu Narzędzia -> Opcje -> Debugowanie -> Ogólne

Problem został dla mnie rozwiązany . Jest to aplikacja WCF, próbowała debugować stronę Ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Stało się tak, ponieważ miałem inne projekty w rozwiązaniu, które nie budowały. Po zwolnieniu tych problematycznych projektów (kliknij prawym przyciskiem myszy projekt w eksploratorze rozwiązań -> Rozładuj projekt), przebudowałem rozwiązanie i uruchomiłem ponownie - punkt przerwania został trafiony!

Zdarzyło się tak w Visual Studio 2017 po dodaniu istniejących plików do projektu. To działało dla mnie:

1. zamknij rozwiązanie,
2. idź do SolutionFolder\.vs\SolutionName\v15\sqlite3i usuństorage.ide
3. otwórz rozwiązanie ponownie

Upewnij się, że nie jesteś w trybie zwolnienia podczas próby debugowania.