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

513

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

David
źródło
36
rekompiluj / skompiluj projekt przed dodaniem punktu przerwania
lexu
otwierasz projekt napisany w innej wersji studia wizualnego?
Mahesh Velaga
2
To projekt strony internetowej. Nie powinno być potrzeby jawnego budowania go. Powinien się kompilować po użyciu. Podejrzewam, że VS nie może zbudować strony, ale to mi nie mówi! Mahesh - nie, ta sama wersja VS.
David
W moim przypadku mam różne wydania tego samego kodu (na przykład test.cs w wersji Live i wersja devolopment .. kiedy otworzyłem wersję devolopment i umieściłem punkt przerwania na test.cs dałem ten sam błąd, ale zorientowałem się, że umieściłem test punktu przerwania .cs klasa, która związana żywo wersja SLN nie rozwiązania w tak sprawdzić cs już pod budowę rozwiązanie)
dankyy1
5
Usuwanie katalogów bin i obj niż przebudowywanie działało dla mnie.
Aycan Yaşıt

Odpowiedzi:

277

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

Veedrac
źródło
120
Korzystanie z czyszczenia nie zawsze działa. Musiałem ręcznie usunąć wszystko z folderu bin, aby ponownie uruchomić.
Carra
3
Przez pomyłkę miałem odniesienie do biblioteki DLL w folderze bin. Poprawiona ścieżka odniesienia.
Brad Urani, 12.12.12
39
Dla mnie nawet usuwanie folderów bin i obj nie działało. Musiałem również zrestartować Visual Studio.
d512
1
Spędziłem prawie dzień na znalezieniu rozwiązania. Dzięki za tonę za dostarczenie rozwiązania.
Racs
8
Zamknąłem VS, usunąłem wszystkie foldery bin i obj, odbudowałem wszystko, podwójnie sprawdziłem konfiguracje kompilacji, kompilacja powiodła się. Nie ma kości. Proste rzeczy nie powinny być tak skomplikowane. >: |
snarf
129

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.

Oliver
źródło
Dzięki za sugestię Oliver. Zdecydowanie tak się nie dzieje, zauważyłem dość szybko, gdyby jeden z moich projektów nie budował.
David
3
Miałem dokładnie ten sam problem, tylko niczego nie zaznaczyłem. w tym oknie dialogowym został właśnie zbudowany dla x86, podczas gdy moją maszyną lokalną jest x64! Więc wybrałem tę Any CPUopcję i znów działa.
JP Hellemons,
3
Usunięcie projektów z konfiguracji debugowania bez ważnego powodu powinno być głównym grzechem, ponieważ taka konfiguracja może z powodzeniem zostać użyta przez maszynę do budowania CI (wiem, że jest tutaj), więc ostatecznie może się zdarzyć, że w przypadku niepowodzenia. Wiem, że może to być jeden z wielu etapów kompilacji, ale nadal ... @Oliver Mam nadzieję, że członek zespołu kupił ci ciastka! :)
Fetchez la vache
Miałem ten problem, kiedy przełączyłem się na kompilację dla x86 zamiast AnyCPU. Usunęło projekty z nieznanego powodu.
Adam Pedley,
Projekt znajduje się na liście Menedżera konfiguracji wbudowanej, więc nie pomogło mi to, obawiam się :(
Ortund
43

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.

AnthonyVO
źródło
2
Opróżnianie plików tymczasowych z katalogu Windows zadziałało, na zdrowie!
ChrisFletcher
7
Chciałem tylko dodać podobną odpowiedź - upewnij się, że żadna stara kopia dll twojego projektu nie znajduje się w żadnym folderze tymczasowym używanym przez ASP.NET, takim jak C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowe pliki ASP.NET - jak wspomniano - ale także C: \ Windows \ Microsoft.NET \ Framework_64_ \ v4.0.30319 \ Tymczasowe pliki ASP.NET . Używam Wszystko do szybkiego wyszukiwania tych kopii .
Oliver,
12
%localappdata%C:\Documents and Settings\%username%\AppData\Local
Krótka
1
Potwierdzam, że zadziałało to w Visual Studio 2013 w projekcie usługi internetowej.
Moeri
Zrobiłem to wszystko, ale chyba nie pomogło. Byłem też bardzo podekscytowany tym widokiem.
Ortund
40

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
Codesleuth
źródło
Nie sądzę, żebym to zrobił. Dzięki za link. Dało mi to wgląd w to, co oznacza ta podpowiedź!
David
11
Visual Studio ma tę opcję już od dziesięcioleci (przynajmniej VS98 ją miała). Nigdy nie zrozumiałem, dlaczego ktoś chciałby uruchomić ostatnią udaną kompilację. W końcu, jeśli tego właśnie chciałem, uruchomiłbym go bezpośrednio, ponieważ i tak nie mogłem debugować. Opcja Nie uruchamiaj byłaby bardziej sensownym domyślnym.
OregonGhost,
6
Użyłem go kilka razy, aby uruchomić projekt (z dowolnego powodu, na przykład po to, aby pokazać komuś innemu), podczas gdy wciąż jestem w trakcie pisania kodu, który się nie skompiluje. Czasami jest to przydatne. Osobiście zostawiam to wyłączone.
Codesleuth,
3
Może gdyby musieli pokazać swojego przełożonego, kiedy nagle przyszedł. Mogłyby nacisnąć F5 i wyglądać jak „widzisz, to działa!”
Gigala,
33

Iść do

  • Przybory
    • Opcje
      • Debugowanie
        • Generał

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

Rachmad
źródło
17
@Rachmad To rozwiązanie działa. Ale wydaje się, że nie jest to kompletne rozwiązanie, ponieważ oznacza, że ​​nasze pliki źródłowe nie są dokładnie zgodne z oryginalną wersją
onmyway133
Właśnie tego szukałem @entropy ma rację. Chociaż pozwala to na ustawienie punktów przerwania, faktem jest, że używane źródło nie pasuje do używanego pdb. Najlepszym rozwiązaniem jest to naprawić. W czasach, których nie można tego zrobić, działa to świetnie.
JamesG
Nawet przy tym niezaznaczonym, wykonanie nie osiąga punktu przerwania, a błąd nadal występuje
Ortund
12
To NIE jest rozwiązanie tego problemu, ale obejście. Oczywiście nie chcę pracować z nieaktualnymi plikami w debuggerze.
Obi Wan
2
@ObiWan Nie oczywiste. Lubię wprowadzać drobne zmiany i kontynuować debugowanie, nawet wiedząc, że źródło i kompilacja są różne.
Alan Baljeu,
30

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

zrzut ekranu menu

AdiKonstantin
źródło
1
To był mój problem. Skompilowałem w trybie debugowania, zmieniłem kod, a potem uruchomiłem go w trybie wydania. Nic dziwnego, że debugger myślał, że kod jest inny - symbole debugowania były różne. Gdy usunąłem folder bin, jak sugerowali inni, pojawia się błąd „nie załadowano żadnych symboli dla tego dokumentu”. Dopiero wtedy nawiązałem połączenie i doszedłem do tej odpowiedzi. Potrzebuje więcej głosów!
indot_brad
Możliwe jest wyłączenie projektu podczas kompilacji nawet w konfiguracji kompilacji debugowania. Wymagane jest sprawdzenie konfiguracji kompilacji, przerzucanie między konfiguracją debugowania / wydania jest bezcelowe.
Asad Saeeduddin
To też było dla mnie. próbowałem wyczyścić, odbudowując inne referencyjne rozwiązania bezskutecznie. Nie zauważyłem, że rozwiązanie wpatrywało się we mnie w twarz
Adam Hej
Tak się ze mną stało - budowałem swój projekt i ciągle zastępowałem moje biblioteki DLL, ale problem po prostu nie zniknie. Zdałem sobie sprawę, że kod jest budowany w trybie Release, podczas gdy zastępowałem biblioteki DLL z folderu / bin / debugowania. Głupi ja.
displayName
Chciałem dołączyć do procesu zbudowanego w trybie wydania. Przejście na debugowanie rozwiązało mój problem.
fivef
27

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.

Tormod
źródło
1
Warto również pamiętać, ale nie sądzę, że jest to problem, ponieważ próbuję włamać się do projektu witryny, a nie biblioteki klasowej.
David
24

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.

Luke Whyte
źródło
4
Zamykanie Visual Studio też dla mnie działało. Ponadto dzięki akcji Wyczyść / Odbuduj.
danielB
3
To naprawiło rozwiązanie w VS 2015
TaintedLemon
3
Naprawiono błąd w VS 2017
Daniel Fisher Lennybacon
Naprawiono problem w VS 2012
seebiscuit
19

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.

John Hatton
źródło
Status ma teraz status „Naprawiono - oczekuje na wydanie” od dwóch dni temu (9 października 2017 r.). To dobra wiadomość, ponieważ UTF-8 jest obecnie jedynym rozsądnym domyślnym kodowaniem tekstu. :-)
rmunn
Zauważam również, że ostateczną przyczyną tego problemu była najwyraźniej ta inna poprawka , która charset=utf8była interpretowana jako „UTF-8 z BOM”. Zmiana tej interpretacji na „bez BOM” złamała niektóre pliki UTF-8, które zawierały BOM. Jeśli więc napotkasz ten problem, a poprawka Visual Studio nie została jeszcze wydana, spróbuj usunąć BOM z początku plików tekstowych, co może rozwiązać problem. (Ten komentarz prosi o odniesienie do Zero Wing ... :-))
rmunn
To był również problem dla mnie. Obecnie nie jest to jeszcze naprawione lub przynajmniej wydane lub błąd został ponownie wprowadzony (wersja 15.4.2)
avidenic
12

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.

Stijn
źródło
Rozumiem, co masz na myśli i warto o tym pamiętać w przyszłości, ale źródłem, o którym tu mowa, jest projekt strony internetowej, a nie biblioteka klasowa.
David
Jest to powszechny problem podczas pobierania starszego kodu, który sprawia, że ​​drapię się po głowie, zastanawiając się, który geniusz postanowił odwołać się do biblioteki dll z projektu w rozwiązaniu, z którego korzysta tylko inny projekt. westchnienie
Kell,
10

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

Mehrdad Babaki
źródło
7

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.

Tomi
źródło
Nie mogę dać +1 wystarczająco. Niedawno ponownie zainstalowałem system Windows i nie zauważyłem, że mój zegar systemowy jest wyłączony. Rzeczywiście, ta zmiana wszystko zepsuła, a przebudowanie całego rozwiązania / projektu magicznie to naprawiło.
Kyle Baran
7

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

JBSnorro
źródło
Napotkałem dokładnie ten sam problem. Twoja odpowiedź pomogła mi! Dziękuję Ci! +1
jweyrich,
5

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 )

FrankyHollywood
źródło
Build-> Clean Solution powinien również zakończyć usuwanie plików, które należy usunąć.
Dave
Po ogromnej stracie czasu straconej z powodu tego problemu rozwiązanie to załatwiło sprawę. Thx FrankyHollywood
AD
4

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.

Stijn
źródło
4

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.

baker.nole
źródło
3

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

mikeTheLiar
źródło
3

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.

Stijn
źródło
3

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.

wyświetlana nazwa
źródło
Warto również zauważyć, że jeśli twój punkt przerwania znajduje się w projekcie, który NIE jest twoim projektem startowym, i NIE MOŻESZ być twoim projektem startowym (ponieważ np. Musisz mieć inny projekt niż projekt startowy) możesz (po uruchomieniu głównego) kliknij prawym przyciskiem myszy i wybierz Debuguj >> Rozpocznij nowe wystąpienie projektu, w którym ma zostać przerwany punkt
Caius Jard
3

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

nurettin
źródło
3

Dla mnie rozwiązanie zostało ukryte we Advanced Build Settingswłaściwościach projektu: wprowadź opis zdjęcia tutaj

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.

riqitang
źródło
3

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

Priyankara
źródło
2

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.

cichy ton
źródło
W moim przypadku podłączałem się do w3wp.exe w celu debugowania kodu .NET, ale z jakiegoś powodu dołączałem do niego debuger skryptów, który nie mógł zobaczyć moich punktów przerwania w języku C #. Zmiana na debuger .NET pozwoliła na działanie moich punktów przerwania w języku C #.
Oran Dennison
2

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.

Julen
źródło
2

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

John
źródło
2
Być może wybór procesora wcale nie wpływa na problem, a jedynie na fakt, że wymusza on przebudowę?
jwg
Użyje innego folderu bin, prawdopodobnie na starej mapie procesora znajdowała się stara biblioteka DLL.
Carra
Miałem ten problem podczas aktywnej platformy x86 (której nigdy nie używałem), przełączenie z powrotem do Win32 rozwiązało problem. Komputer jest współdzielony, więc ktoś inny ustawił tę platformę z dowolnego powodu.
Zac
2

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

Pete
źródło
1
Może się zdarzyć, że konfiguracja wydania zmieni się z x32 na x64 po wyłączeniu trybu zgodności i może nie być wybranych wszystkich projektów do kompilacji w x32. Dlaczego niektóre projekty są wyłączone dla kompilacji w x32, musisz porozmawiać z członkami swojego zespołu.
Asad Saeeduddin
To był dokładnie mój problem. Dziękuję Ci!
Johan Holtby
2

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

Teoman Shipahi
źródło
2

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!

Sarah
źródło
2

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
Laurian
źródło
Dziękuję za to rozwiązanie! Żadne wcześniej nie działało, a to uratowało mi dzień :)
StefanaB
2

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

Wejdź
źródło