Projekt programu Visual Studio 2015 nie działa już w trybie debugowania

Oto, co otrzymuję nawet po uruchomieniu w konfiguracji debugowania:

Sposób, w jaki to pokazałem, polegał na włączeniu „Tylko mój kod” i ostrzeżeniu, jeśli podczas uruchamiania nie ma żadnego kodu użytkownika. To coś, co ostatnio przydarzyło się naszemu projektowi i nie jestem pewien, co zrobiliśmy, aby to spowodować. Ale nie udało mi się tego naprawić. Punkty przerwania nie odpalają, a szybki zegarek daje dziwne wyniki.

Próbowałem googlować, ale żadne ze standardowych rozwiązań typu „punkty przerwania nie zadziałają” nie zadziałało. Brakuje mi pomysłów.

Sprawdziłem menedżera konfiguracji i każdy projekt jest tam również ustawiony na debugowanie.

Wyłączyłem opcję „Włącz optymalizacje” i nie pojawia się już okno dialogowe „debugujesz kompilację wydania”. Znowu działa i zatrzymuje się na punktach przerwania! Jednak okno danych wyjściowych wyświetla to podczas uruchamiania:

Nie załadowano symboli modułu „Navigo.exe”.

1. Użyj konfiguracji kompilacji do debugowania lub wyłącz opcję debugowania „Włącz tylko mój kod”.
2. Sprawdź ustawienia „Symbole” w opcjach debugowania.

Więc to rozwiązuje mój główny problem polegający na tym, że nie mogę już używać punktów przerwania i wyskakującego okienka. Co jest dziwne, ponieważ myślałem, że potrzebujesz symboli do załadowania, aby punkty przerwania działały. Jak więc mogą działać punkty przerwania, jeśli symbole nie są załadowane? Może to po prostu zła wiadomość?

Użyj Configuration Manager, aby sprawdzić, jakie są rzeczywiste ustawienia konfiguracji debugowania - jest to w menu Build → Configuration Manager ... - w przypadku, gdy są ustawione do używania wersji :

Upewnij się również, że projekt poprawnie definiuje DEBUG i że opcja „Optymalizuj kod” nie jest zaznaczona:

Przydarzyło mi się to również w kilku projektach. Sprawdziłem ustawienia kompilacji, zgodnie z sugestią stuartd . Jednak opcja „Optymalizuj kod” nie została włączona w moich ustawieniach kompilacji. Więc włączyłem to i zapisałem projekt. Następnie odznaczyłem to i ponownie zapisałem. Problem rozwiązany.

Jest jakiś błąd, który powoduje, że --optimize+flaga jest przekazywana do debugera. Włączenie go, a następnie wyłączenie jest łatwym obejściem, dopóki błąd nie zostanie naprawiony.

Zaczęło się to dziać po zastosowaniu Aktualizacji 1. Istniejące projekty zaczęły to pokazywać i mogę to powtórzyć za pomocą zupełnie nowego projektu. Cała konfiguracja jest ustawiona na DEBUG, a Optymalizacja nie jest zaznaczona.

Kicker polega na tym, że uruchomienie projektu po raz pierwszy (lub po wyczyszczeniu) działa dobrze, bez żadnego komunikatu. Zatrzymanie, a następnie ponowne uruchomienie projektu (uwaga - projekt nie jest odbudowywany ) spowoduje wyświetlenie okna dialogowego.

Jedynym rozwiązaniem jest wyłączenie opcji Just My Code - co wydaje się hackem, tak jak miało to miejsce w poprzedniej aktualizacji 1 bez żadnych problemów.

Jeśli żadne z wymienionych rozwiązań nie pomogło, sprawdź plik AssemblyInfo.cs projektu pod kątem jawnej aplikacji DebuggableAttribute. Wygląda na to, że przesłania opcje debugowania / wydania kompilatora.

Miałem tę linię w pliku w moim przypadku (starszy projekt, nie mam pojęcia, jak się tam dostał). Usunięcie go rozwiązało problem:

[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Wybierz menu Debuguj → Opcje i odznacz opcję Wyłącz optymalizację JIT . Mi to pasuje.

Źródło: https://connect.microsoft.com/VisualStudio/feedback/details/2116788/flag-optimize-is-passed-to-the-debugger-even-while-the-build-settings-optimize-code-is- not-enabled-on-mvc-c-web-projects-when-using-just-my-code

Napotkałem również ten problem. Rozwiązaniem, które działało, było po prostu wyczyszczenie ( Build > Clean Solution) i odbudowanie ( Build > Rebuild Solution) moich projektów.

Żadna z poprzednich odpowiedzi nie działała dla mnie. Ponowne uruchomienie usług IIS rozwiązało problem.

Dodam tylko dodatkową notatkę do odpowiedzi Stuartda :

Pamiętaj, aby sprawdzić wszystkie projekty zależne dla tych samych ustawień kompilacji. Ten sam komunikat zostanie wyświetlony, jeśli projekt główny ma odpowiednie ustawienia, ale projekty zależne nie. Z perspektywy czasu ma to oczywiście sens, ale nie była to pierwsza rzecz, jaka przyszła mi do głowy.

W moim przypadku problem polegał na tym, że adres URL projektu IIS na karcie sieci Web właściwości projektu ASP.NET został ustawiony na nieprawidłowy adres URL.

Wskazał na http: // localhost, którego używałem z inną kopią projektu. Adres rozwiązania, które otworzyłem, został faktycznie skonfigurowany w moich lokalnych usługach IIS jako http: // localhost: 90 .

Zmiana na właściwy adres rozwiązała problem.

Wypróbowałem prawie wszystko z tej listy, ale w końcu naprawiłem to, otwierając właściwości rozwiązania i przełączając się z „Wiele projektów startowych” na „Pojedynczy projekt startowy” iz powrotem.

1. Kliknij rozwiązanie prawym przyciskiem myszy i wybierz „Właściwości”
2. W sekcji „Wspólne właściwości” zmień wybór „Wiele projektów startowych” na „Pojedynczy projekt startowy”
3. Kliknij OK
4. Uruchom debugowanie
5. Zakończ debugowanie i powtórz kroki 1–3, ale przełącz się z powrotem na „Wiele projektów startowych”
6. Uruchom ponownie debugowanie z wieloma projektami

Miałem ten sam problem ... Nieważne co zrobiłem - nic nie działało.

Problemem był nowy, pusty projekt. Skończyło się na usunięciu projektu i dodaniu nowego projektu - nowy projekt musiał mieć inną nazwę ; jeśli użyłem tej samej nazwy, błąd po prostu pojawił się ponownie - nawet po ponownym uruchomieniu, wyczyszczeniu i odbudowaniu ... To musi być błąd w Visual Studio 2015.

Dla mnie była to referencja NuGet z prywatnego serwera NuGet. Nie wiem, jak to zostało skompilowane, ale zmiana odniesienia do referencji projektu pomogła mi rozwiązać problem.

Otworzyłem projekt Visual Studio 2012 Pro w Visual Studio 2015 Express i miałem ten sam problem.

Sprawdziłem właściwości mojego rozwiązania → Właściwości konfiguracyjne i odkryłem, że projekt został ustawiony na Release & x86.

Zmieniłem go z powrotem na debugowanie i dowolny procesor , a monit zniknął.

W moim przypadku opracowywałem wtyczkę VSTO dla Outlooka i Outlook przypadkowo ładował wersję Release pliku DLL, który niedawno zainstalowałem podczas testowania mojego instalatora.

Wygląda na to, że program Visual Studio próbował użyć tej biblioteki DLL zamiast tej, której oczekiwałem debugowania. Naprawienie tego, który plik DLL jest ładowany przez Outlooka, rozwiązało ten problem.

Kopiowanie mojej drugiej odpowiedzi stąd .

Jak wspomniał @romanoza, Microsoft zaktualizował raport o błędzie o następujące informacje:

Odznacz ustawienie Debuguj -> Opcje -> Wstrzymaj optymalizację JIT przy ładowaniu modułu (tylko zarządzane)

To jest obejście. Później mówią:

Zalecamy pozostawienie go niezaznaczonego, ponieważ odznaczenie go poprawi zarówno wydajność, jak i zachowanie tylko mojego kodu w określonych scenariuszach.

Na koniec podziękowanie:

Jest to błąd polegający na tym, że nie działa przy włączonym tym ustawieniu i pracujemy nad rozwiązaniem tej sytuacji, na wypadek gdyby niektórzy klienci nadal chcieli debugować przy włączonym tym ustawieniu.

Napotkałem ten sam problem i ostatecznie rozwiązałem go, wybierając opcję „Wyłącz tylko mój kod i kontynuuj” .

Tylko ustawienie mojego kodu

Kroki rozwiązania:

• Przejdź do ustawień kompilacji właściwości projektu powodującego naruszenie stronie .

• Przewiń w prawo do „Zaawansowane ...” .

• Upewnij się, że „Informacje debugowania:” nie jest  ustawione na „brak” .

  Zalecam skorzystanie z pełnej opcji.

Po wyświetleniu linku Patryka jako komentarza do pytania , ktoś zauważył obejście polegające na zatrzymaniu witryny w IIS Express . Udało mi się zapobiec temu samemu problemowi, robiąc to po zatrzymaniu debugera w programie Visual Studio.

Jednak przyglądałem się temu bardziej i uważam, że może to być również związane z ustawieniem „Edytuj i kontynuuj” dla debugera. Kiedy wyłączyłem to w menu Narzędzia → Opcje ... programu Visual Studio, nie miałem już problemu. Ale wtedy uniemożliwiłoby ci to korzystanie z opcji Edytuj i kontynuuj , więc nie jestem pewien, czy to jest tego warte.

Menu Narzędzia → Opcje → Debuger → Edytuj i kontynuuj (przewiń do dołu listy Ogólne) → usuń zaznaczenie opcji Edytuj i kontynuuj .

Doświadczyłem tego również nagle po zainstalowaniu aktualizacji 1, ale mogło tak być, że od razu miałem to ustawienie ... Nie jestem jednak pewien.

W przypadku, gdy chcesz kontynuować bez dalszych opóźnień, wybierz ostatnią opcję z wyskakującego okienka i wszystko będzie działać tak samo jak poprzednio.

To był dziwny alert.

Odbudowanie rozwiązania niekoniecznie spowoduje wyczyszczenie wszystkich plików DLL (zwłaszcza skopiowanych z projektów zależnych).

Jednak odbudowanie projektu zależności spowodowało, że ten alert zniknął.

Zmierzyłem się z tym w Visual Studio 2015 Update 3.

Moje rozwiązanie różniło się nieco od wszystkich innych i jest nieco wyjątkowe.

Pracuję z witryną, która zawiera mieszankę kodu zarządzanego i klasycznego ASP , odwołując się do tego samego zestawu. Program Visual Studio skarżył się, że zarządzany plik DLL jest kompilacją wydania.

Problem był nieprzechwyconym wyjątkiem w moim zestawie, ale został wyrzucony przez stronę ASP Classic przez interop. Program Visual Studio nie był w stanie obsłużyć debugowania tego i wyświetlił komunikat o błędzie. Ten sam wyjątek zgłoszony z kodu zarządzanego spowodowałby uruchomienie debugera zgodnie z oczekiwaniami.

Naprawienie problemu w konstruktorze mojego zestawu zarządzanego naprawiło wszystko.

Teraz, kiedy spoglądam wstecz na szerszą perspektywę, wszystko ma sens, ale wtedy komunikat o błędzie poprowadził mnie bardzo głęboką ścieżką i próbowałem wszystkiego w odpowiedzi, dopóki nie otrzymałem odpowiedzi „Ah-ha!”. za chwilę.

Spędziłem dwa dni i wygląda na to, że pomogło mi Resetowanie wystąpienia eksperymentalnego programu Visual Studio 2017 .