VS 2015 Update 1 - twierdzenie, że debuguję kompilację wydania

Po aktualizacji do VS 2015 Update 1, jeśli uruchomię projekt sieciowy (MVC), zatrzymam aplikację, a następnie spróbuję ją ponownie uruchomić, VS zatrzymuje się i wyświetla okno dialogowe z żądaniem

Debugujesz kompilację wydania <myproject.dll>.

Używanie Just My Code z kompilacjami wydań przy użyciu optymalizacji kompilatora skutkuje pogorszeniem działania debugowania (np. Punkty przerwania nie zostaną trafione).

Problem polega na tym, że nie uruchamiam kompilacji wydania. Wyraźnie korzystam z (tej samej) kompilacji debugowania, którą właśnie uruchomiłem! Dlaczego VS myśli, że używam kompilacji wydania?

Czyszczenie roztworu i ponowne uruchomienie kasuje komunikat o błędzie, więc coś jest gdzieś wężem.

Firma Microsoft informuje, że jest to znany problem (pierwotnie trafił do zespołu ds. Debugera, ale ustalono, że był to problem z kompilacją, a teraz jest w rękach zespołu ds. Systemu projektu. Istnieją inne otwarte błędy w tym problemie, oceniono jako priorytet 1, więc powinno być na dobrej drodze do następnej aktualizacji. Chociaż zgodnie z oczekiwaniami, nie można składać żadnych obietnic, kiedy zostanie wydana (lub co faktycznie jest w aktualizacji).

Więc. Jest znany i jest w trakcie opracowywania. Przynajmniej wyłączenie opcji „Włącz tylko mój kod” w ogólnych opcjach debugowania wydaje się na razie obejść.

Jak wspomniał @romanoza, Microsoft zaktualizował (obecnie brakujący) raport o błędzie Microsoft Connect (znajdujący się wcześniej tutaj , na wypadek, gdybyś mógł gdzieś znaleźć archiwum) 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.

Aktualizacja : Na podstawie uwag, wydaje się, że skrzynka jest teraz un domyślnie zaznaczone dla niektórych deweloperów, a sprawdzenie go można naprawić identyczny problem w niektórych przypadkach. Bardzo dziwny.

Zauważyłem, że odpowiedzi tutaj są niekompletne, miałem ten sam problem i został on rozwiązany przez otwarcie właściwości projektu i na karcie kompilacji i konfiguracji debugowania odznaczając opcję „optymalizuj kod” . Powinieneś także sprawdzić menedżera konfiguracji, jak wspomniano powyżej, aby upewnić się, że to również działa. Odpowiedź przyszła z tego postu i powinni otrzymać kredyt: Projekt VS2015 nie działa już w trybie debugowania

Dzięki,

Rozwiązałem problem ustawiając konfigurację na Debugowanie w oknie Menedżera konfiguracji, zgodnie z sugestią w tej odpowiedzi .

Czyszczenie (i odbudowa) rozwiązanie działa dla mnie jako tymczasowe obejście. Możesz także wybrać Debuguj> Opcje i odznaczyć pole Suppress JIT optimizationwyboru.

Mam ten sam problem od czasu aktualizacji do VS2015 Update 1.

Znalazłem podobny raport na forach Microsoft Visual Studio, który wskazuje na zgłoszony tutaj raport o błędzie

Istnieją różne obejścia, ale myślę, że podstawowym problemem jest to, że IIS Express nie wyłącza się po zakończeniu debugowania - i nie jest to spowodowane odznaczeniem opcji Edytuj i kontynuuj. Najszybsze obejście, jakie mogę znaleźć, dopóki błąd nie zostanie naprawiony:

• Kliknij prawym przyciskiem myszy ikonę IIS Express w zasobniku i zamknij ją po debugowaniu (Podziękowania dla Davida Totzke, który dostarczył obejście w raporcie o błędzie)

Niezbyt dobre, ale nie sądzę, aby w tej chwili dostępne było odpowiednie rozwiązanie.

Napotkałem ten sam problem. Rozwiązałem problem, ręcznie usuwając wszystkie pliki z folderu „bin”, a następnie odbudowałem rozwiązanie. Nie widzę już tego okna dialogowego.

W moim przypadku zmieniłem „Platformę aktywnych rozwiązań” dla całego rozwiązania w „Menedżerze konfiguracji” z x86 na Dowolny procesor, naprawiłem problem

Sprawdź właściwości konfiguracyjne rozwiązania. Napotkałem ten sam problem i odkryłem, że moja konfiguracja debugowania faktycznie budowała niektóre projekty z konfiguracją wydania.

Zauważyłem, że Visual Studio nie zabijał procesu iisexpress po zatrzymaniu debugera. Wydawało się, że ręczne zabijanie tego procesu rozwiązało problem.

Wygląda na to, że zostało to naprawione w aktualizacji 2.

Wydaje się, że rozwiązań jest tyle, ile osób ma problem, ale w moim przypadku musiałem usunąć i ponownie dodać odniesienie do projektu. Odniesienie do projektu znajdowało się w projekcie testu jednostkowego w tym samym rozwiązaniu.

W moim przypadku komunikat o błędzie był poprawny. Uruchomiłem aplikację, która załadowała wydaną wersję. Więc poprawiłem to, ładując zamiast tego wersję debugowania.

Wiem, że jestem elementarny i zdaję sobie sprawę, że wyglądam na idiotę. Ale czasami problem dotyczy dokładnie tego, co zostało zgłoszone.

Sprawdź, czy adres URL projektu IIS faktycznie wskazuje miejsce, które Twoim zdaniem wskazuje. W razie wątpliwości kliknij przycisk „Utwórz katalog wirtualny”.

Niedawno miałem ten problem, gdy korzystałem z tymczasowej wersji produkcyjnej bazy kodu i ponownie przypisałem folder w usługach IIS do wersji tymczasowej, która faktycznie była uruchomiona kompilacją produkcyjną, a nie wersją debugowania, którą próbowałem debugować.

Dla mnie znalazłem odniesienia do folderu 3 \ Release \ w tym pliku FileListAbsolute.txt:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csproj.FileListAbsolute.txt

Byli tacy:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csprojResolveAssemblyReference.cache

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.dll

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.pdb

Usunięcie tych 3 linii poza VS, a następnie ponowne otwarcie rozwiązania rozwiązało problem. Mam nadzieję, że to pomoże.

Wypróbowałem wszystkie odpowiedzi, a jedna działała dla mnie, to usunięcie pakietu NuGet, a nie tylko odwołania, ale usunięcie pakietu, w moim przypadku PostSharp. Na początku próbowałem usunąć odniesienie ze wszystkich projektów i to nie działa, po czym po prostu usunąłem pakiety z menedżera. Nie wiem, jaki jest dokładnie powód, ale właśnie to rozwiązało moje problemy, mam nadzieję, że mogłoby to komuś pomóc.

Uruchom ponownie program Visual Studio. To rozwiązało problem w 2017 Professional.

Oto, co zadziałało dla mnie.

Jeśli jest to projekt sieci Web, przejdź do właściwości projektu i

1. Jeśli wybrano Lokalne usługi IIS, uruchom ponownie serwer IIS.
2. Jeśli wybrano IIS Express, zamknij IIS Express z ikony na pasku zadań.

Wygląda na to, że niektóre biblioteki DLL są buforowane, więc powyższe kroki unieważnią pamięć podręczną.

Stało się to w programie Visual Studio 2019 w aplikacji platformy UWP. Usunięcie zaznaczenia kodu Optimize w ustawieniach csproj / build rozwiązało problem.

Jestem pewien, że zostało to naprawione w programie Visual Studio 2015 Update 2.

Widziałem to cały czas (wiele razy dziennie) i ani razu nie widziałem tego od czasu aktualizacji do Aktualizacji 2.