Ok, co mam:
Visual Studio 2010 RC, W7 x64, uruchomił nowy typ aplikacji Silverlight. Hostowanie aplikacji Silverlight w projekcie aplikacji sieci Web ASP.NET. Wersja Silverlight 3.0. Dodano klasę LinqToSQL, usługę WCF, aplikację Winform Tester (projekt w rozwiązaniu) i kilka klas (również jako projekty w rozwiązaniu).
Wczoraj nagle otrzymałem „Punkt przerwania nie zostanie obecnie trafiony. Dla tego dokumentu nie załadowano żadnych symboli. ” wiadomość pojawiająca się w IDE, ale wpływa ona tylko na aplikację internetową, mogę debugować aplikację Silverlight i aplikację Winform.
Co próbowałem / zrobiłem, aby pozbyć się wiadomości:
- Zresetuj ustawienia programu Visual Studio
- usunięto wszystkie pliki w każdym \ Temporary Folderze plików ASP.NET (jeden jest dla każdego 32-bitowego / 64-bitowego i dla Framework 2.0 i 4.0)
- próbowałem debugować za pomocą zintegrowanego serwera sieci Web Visual Studio - zwykle używam IIS, w danych wyjściowych projektu rozwiązania usunąłem wszystkie foldery obj i bin w każdym folderze projektu
- utworzył nowe rozwiązanie i dodał wszystkie projekty do tego nowego rozwiązania
- usunął plik suo rozwiązania
- utworzył nową aplikację sieci Web ASP.NET w celu przetestowania, czy jest to problem z instalacją VS => Mogę debugować ten nowy projekt / rozwiązanie
- kilkakrotnie ponownie uruchomiłem maszynę
- naprawił instalację vs.net
- zrobił IISReset
- usunął aplikację sieci Web z IIS
- użył przycisku Utwórz katalog wirtualny w obszarze Właściwości projektu aplikacji sieci Web, aby utworzyć nową aplikację sieci Web w usługach IIS
- zmieniono wersję ramową każdego projektu z 3.5 na 4.0
- Otworzyłem rozwiązanie na moim drugim komputerze => to samo zachowanie
- przeszukano Microsoft Connect w poszukiwaniu błędów / podobnych problemów
- SPĘDZONE 7 GODZIN.
Tak dzieje się drugi raz w życiu. ostatnim razem rozwiązałem go, usuwając folder plików tymczasowych ASP.NET, ale tym razem potrzebuję twojej pomocy.
Odpowiedzi:
Kliknij prawym przyciskiem myszy rozwiązanie -> Właściwości
Zajrzyj do Wspólnych właściwości -> Projekt startowy
Wybierz wiele projektów startowych
wybierz Rozpocznij akcję dotyczącą projektów, które chcesz debugować.
źródło
Miałem ten sam problem i po googlowaniu znalazłem dwa typowe rozwiązania:
Upewnij się, że debuger Silverlight jest aktywowany w projekcie .Web. Otwórz właściwości projektu i wybierz debuger Silverlight na karcie „Internet”.
Uruchom ponownie program Visual Studio i usuń wszystkie foldery bin i obj.
Ale żaden z nich nie działał dla mnie . Następnie ktoś wspomniał o wątku, aby zamiast tego spróbować użyć IE jako przeglądarki. Dzięki temu debugowanie i punkty przerwania znów działają!
Edytować:
Później zmagałem się z niedziałaniem IE9, ponieważ wiąże się on z niewłaściwym procesem. Zamiast ręcznego dołączania do prawidłowego procesu IE za każdym razem znalazłem fajną sztuczkę :
Teraz Visual Studio uruchomi IE podczas uruchamiania projektu .Web i dołącza do prawidłowego procesu. Że należy to zrobić.
źródło
Ilekroć pojawiał się ten konkretny błąd, okazało się, że folder, z którego Visual Studio ładuje zestawy, jest inny niż folder, z którego działa aplikacja internetowa.
Oznacza to, że serwer aplikacji uruchamia aplikację
ale program Visual Studio debuguje
Uwaga - z różnych powodów debuguję za pomocą usług IIS jako hosta aplikacji zamiast fałszywego samodzielnego gadżetu, z którego korzysta większość osób. Może to wpłynąć na użyteczność mojej odpowiedzi!
Aktualizacja :
W przypadku IIS katalog serwera aplikacji (tj.
C:\dev\MyApplication
Powyżej) jest fizycznym katalogiem skonfigurowanym dla aplikacji sieci web - można to kontrolować, zmieniając podstawowe ustawienia aplikacji.W przypadku programu Visual Studio katalog debugowania (tj.
C:\dev\MyOtherApplication
Powyżej) to katalog, w którym znajdują sięsvc
pliki, zwykle ten sam katalog cocsproj
plik projektu.źródło
Problemem okazało się to, że pole wyboru Właściwości-> Buduj-> Optymalizuj kod zostało włączone w konfiguracji debugowania. Wyłączone, przebudowane i debugowanie działało normalnie.
źródło
Powodem, dla którego napotkałeś, jest to, że PDB („PDB oznacza bazę danych programu, zastrzeżony format pliku (opracowany przez Microsoft) do przechowywania informacji debugowania o programie) nie są aktualne, może to być z kilku powodów :
1- Jak powiedział Bevan, być może debugujesz inną aplikację!
2- Debugujesz inną wersję tej samej aplikacji. Na przykład dołączyłeś wcześniej zbudowaną aplikację z bieżącą wersją kodu do debugowania bez (ponownego) budowania go.
Czyszczenie lub przebudowa rozwiązania rozwiązuje dla mnie takie problemy.
Aby upewnić się, że problem nie jest twój, spróbuj debugować tę samą aplikację w VS 2008 (obawiam się, że może to być błąd w VS 2010 - wciąż jest wersja beta!).
źródło
Miałem ten sam problem, debugowałem mój projekt i musiałem kliknąć projekt prawym przyciskiem myszy i wybrać „nową instancję debugowania”. Musiałem to zrobić tylko raz, a potem działało to normalnie.
źródło
Ten błąd pojawia się od czasu do czasu dla mnie i zawsze mogę prześledzić go z powrotem do ustawień projektu dla danego zespołu. Nie musisz „czekać”, aż twój kod nie przestrzega punktu przerwania lub dopóki nie ustawisz punktu przerwania, aby wiedzieć, które zestawy mają załadowane symbole.
Kiedy uruchomisz projekt w trybie debugowania, w oknie Wyjście wyświetli listę, które zestawy mają załadowane symbole, jak poniżej (może być konieczne otwarcie obrazu w nowej karcie): T
Tak więc w tym przypadku plik BASD.Core.Data.dll NIE ma załadowanych symboli. Możesz więc porównać ustawienia projektu dla tego zestawu z ustawieniami innego zestawu, któremu udało się załadować symbole, aby dowiedzieć się, dlaczego niektóre robią, a niektóre nie ładują symboli.
„Dla mnie” jednak „za każdym razem” dzieje się tak, ponieważ informacje debugowania nie są tworzone. Więc otwieram Właściwości projektu> Kompilacja> Zaawansowane w projekcie (C #).
Tak więc dla Basd.Core.Data.dll powyżej tj. Bez symboli zaawansowane ustawienia kompilacji to:
Natomiast w przypadku Basd.Core.Configuration.dll, czyli zestawu, w którym mogłem ustawić i trafić punkt przerwania, ustawienia były następujące:
Więc wypisuję informacje debugowania w drugim projekcie, a nie w pierwszym, stąd moja zdolność do osiągnięcia punktu krytycznego w Basd.Core.Configuration.dll
Zauważ również, że nie wystarczy po prostu mieć plik .pdb w folderze bin projektu dla danego pliku .dll, ponieważ może on być nieaktualny i dlatego nie zostanie wybrany przez Visual Studio jako prawidłowy plik symboli dla pliku .dll próbujesz przejść.
Należy również pamiętać, że zmiana konfiguracji kompilacji może zmienić ustawienia informacji o kompilacji oraz miejsce, z którego pobierane są symbole.
(Zdaję sobie sprawę, że w tym przypadku jestem w trybie zwolnienia, ale metoda nadal obowiązuje)
źródło
Idź do Właściwości projektu -> Kompilacja -> Zaawansowane ...
W sekcji „Wyjście” wybierz opcję „pełna” w menu rozwijanym Informacje debugowania
źródło
Upewnij się, że program działa w trybie DEBUG, a nie w trybie RELEASE.
źródło
Debuguj -> Dołącz do procesu ->
wybierz Debuguj te typy kodów: opcja ->
wybierz Zarządzane v3.5, v3.0, v2.0 lub Zarządzane v4.5, v4.0
źródło
Właśnie rozwiązałem ten problem według Wdrażanie aplikacji Silverlight . (Ta odpowiedź jest duplikatem niektórych innych, ale postaram się ją dokładniej wyjaśnić).
Problem najprawdopodobniej polega na tym, że aplikacja Silverlight nie jest poprawnie wdrażana w aplikacji internetowej podczas kompilacji / uruchamiania. Jest to problem z odniesieniami - jest prosty do zrozumienia, ale nie jest oczywisty za pierwszym razem.
Podobnie jak w przypadku innych odniesień do projektu, dane wyjściowe projektu, do którego należy odwołanie , należy skopiować do folderu bin projektu odniesienia w celu debugowania. W przypadku bibliotek klas dzieje się to po kliknięciu prawym przyciskiem myszy i wybraniu opcji „Dodaj odniesienie ...”. W przypadku Silverlight należy dodać odwołanie za pośrednictwem Właściwości projektu.
Dodaje to odwołanie do aplikacji Silverlight z aplikacji hostingowej i zapewnia, że
xap
plik zostanie skopiowany do aplikacji internetowej podczas kompilacji lub wdrażania. Oznacza to, że bieżąca aplikacja Silverlight i jej pliki debugowania znajdują się w debugowanej aplikacji, a Ty będziesz mógł przejść przez kod.źródło
Jeśli debugujesz projekt WWW, upewnij się, że atrybut debug = "true" został ustawiony w pliku web.config:
źródło
Miałem ten sam problem na Windows 7 i próbowałem wszystkiego : wyczyściłem biblioteki DLL, sprawdziłem listę modułów, wyłączyłem „Just My Code” i tak dalej.
Problem został rozwiązany po uruchomieniu programu Visual Studio „jako administrator”. Szczerze. Dlaczego Microsoft nie może mnie po prostu ostrzec, że nie działa jako „administrator”? Zaoszczędzi mi to kilka godzin pracy.
źródło
Dla mnie problem polegał na tym, że miałem włączoną opcję „Optymalizuj kod” w zakładce Kompilacja w ustawieniach mojego projektu.
źródło
Miałem ten sam problem
Z jakiegoś powodu jedna z bibliotek DLL została zarejestrowana w GAC, dlatego zawsze miała inną wersję niż kod.
Po usunięciu go z GAC problem został rozwiązany
źródło
Dla tych, którzy używają Visual Studio 2008, a nie Visual Studio 2010 i otrzymują ten błąd. Powyższe odpowiedzi nie pomogły mi w tej sytuacji, dlatego dzielę się swoim doświadczeniem.
Jeśli debugujesz aplikację sieci Web IIS w programie Visual Studio 2008, dołączając się do procesu w3wp.exe zamiast używać serwera programistycznego ASP.NET do debugowania (zacznij od debugowania), może to być twój problem:
Program Visual Studio może nadal odwoływać się do pliku symboli (pliku używanego podczas debugowania) z biblioteki DLL z nieaktualnego procesu IIS. Ten plik symboli został odtworzony przez rekompilację kodu źródłowego .NET, ale proces IIS nadal odwołuje się do starego pliku symboli.
Naprawić:
Po prostu przestań debugować w Visual Studio, uruchom ponownie aplikację internetową i ponownie dołącz do procesu. Następnie punkty przerwania powinny zmienić kolor z żółtego (gdy zobaczysz ten błąd) na czerwony.
========================
Więcej rzeczy do wypróbowania (dzisiaj znalazłem nową sytuację):
Zrób każdą kulę w linku poniżej JEDEN RAZ, ale powtórz moje kroki poniżej z każdym, którego spróbujesz.
http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same
1.) Zatrzymaj debugowanie (naciśnij czerwoną ikonę kwadratu) w Visual Studio
2.) Wyczyść rozwiązanie
3.) Kompiluj rozwiązanie
4.) [INSERT BULLET INSTRUKCJA TUTAJ]
5.) Narzędzia> Dołącz do procesu (lub zacznij od debugowania)
6.) Uruchom program, do którego dołączasz, i uruchom go w taki sposób, aby kod został trafiony
6 wyjaśnił:
Jeśli dołączasz do nunit.exe, otwórz NUnit i uruchom test, aby twój punkt przerwania został trafiony
Jeśli dołączasz do w3wp.exe (witryna IIS), otwórz swoją witrynę w przeglądarce i przejdź do strony, która uderzy w punkt przerwania
EDYTOWAĆ:
Dzisiaj zauważyłem, że jeśli spróbujesz debugować projekt, który nie jest ustawiony jako projekt początkowy, pokaże to. Po dołączeniu do procesu w3wp.exe myśli o debugowaniu projektu, który jest ustawiony jako projekt początkowy. Aby rozwiązać problem, kliknij prawym przyciskiem myszy projekt aplikacji internetowej i wybierz „Ustaw jako projekt początkowy”. Następnie spróbuj ponownie dołączyć do procesu.
źródło
Scenariusz jest następujący: konkretny projekt to projekt początkowy (np. Ma metodę Main). Ten projekt odwołuje się do innych projektów w twoim rozwiązaniu. Punkty przerwania w innych projektach nie są trafiane.
Szybkie rozwiązanie: kiedy budujesz swoje rozwiązanie, poszukaj ścieżki startowej kompilacji (zwykle bin \ Debug). Spójrz na pliki DLL i PDB dla projektów, do których się odwołujesz. Upewnij się, że ich ostatnia modyfikowana data jest datą ostatniej budowy rozwiązania. Jeśli nie są, skopiuj je ze ścieżki wyjściowej kompilacji każdego projektu do projektów początkowych. Na przykład:
Projekt A ma Główny. Odwołuje się do projektu B. Twoje punkty przerwania nie są trafiane w projekcie B. Skopiuj plik DLL i plik PDB ze ścieżki wyjściowej kompilacji projektu B do ścieżki wyjściowej kompilacji projektu A. Następnie uruchom swoje rozwiązanie. Punkt przerwania zostanie teraz trafiony.
Teraz musisz dowiedzieć się, dlaczego Projekt A nie kopiuje plików DLL i PDB Projektu B. Odpowiedzi tutaj obejmują większość scenariuszy. Jednym ze scenariuszy, których nie dotknięto, jest prawidłowe powiązanie projektów i rozwiązania z TFS. Niektóre projekty zostały powiązane, a niektóre niepoprawnie. To spowodowało problem. Gdy to naprawiłem, problem zniknął i nie musiałem już kopiować plików DLL i PDB.
źródło
Rozwiązaniami tego samego problemu w moim przypadku była następująca kombinacja kroków:
źródło
Aby naprawić ten problem w Web.config, po prostu musiałem dodać
debug="true"
Pomogłem mi znaleźć to rozwiązanie, kiedy patrzyłem na okna modułów podczas debugowania i zobaczyłem, że dla załadowanych bibliotek DLL ASP.NET miałem: Binary nie został zbudowany z informacjami debugowania.
źródło
Miałem ten sam problem, ale w VS2013 dla aplikacji sieci Web. Dla mnie odpowiedzią była aktualizacja konfiguracji kompilacji dla rozwiązania: -
Gdy to zrobiłem, wszystkie moje punkty przerwania zaczęły działać.
źródło
Okej - zaczynamy:
(W „aplikacji silverlight”: najpierw sprawdź, czy silverlight jest zaznaczony w „sieci” we właściwościach projektu serwera - jeśli to nie rozwiązało, spróbuj tego poniżej)
Za pierwszym razem: uruchom najpierw: devenv.exe / ResetSettings i 1: w górnym menu kliknij znacznik debugowania 2: kliknij opcje i ustawienia 3: W „debugowaniu” i pod „ogólnym” znajdź „włącz krok po kroku źródła .NET Framework” 4: Zaznacz pole. 5: A teraz wszystkie symbole zostaną pobrane i ponownie skonfigurowane :)
Jeśli to powtórzy się po powyższym, po prostu wyczyść folder, w którym znajdują się symbole:
1: W górnym menu kliknij tag debugowania 2: kliknij opcje i ustawienia 3: W „debugowaniu” i pod „symbolami” znajdź przycisk „opróżnij pamięć podręczną symboli” i kliknij go.
źródło
Otwórz adres URL aplikacji sieci Web z przeglądarki, a następnie w VS.Net IDE użyj Narzędzia -> AttachtoProcess
następnie dołącz do aspnet_wp.exe.
Debuger zacznie działać
źródło
Musiałem ręcznie odinstalować wszystkie wystąpienia .dll z rejestru i wszystkie wystąpienia .dll z mojego dysku lokalnego. Odinstalowałem / ponownie zainstalowałem moją aplikację i teraz uderzam w punkty przerwania! Zmarnowałem pół dnia, robiąc to :(.
źródło
Próbowałem zmienić nazwę
.pdb
pliku wobj\debug
folderze, zrobiłem czyste rozwiązanie i przebudowałem.Utworzył nowy
.pdb
plik i byłem w stanie poprawnie trafić punkty przerwania.źródło
Miałem ten sam problem - straciłem dużo czasu na próby debugowania w Visual Studio.
Ostatecznie stał się Nuget - miałem 3 wersje Newtonsoft.Json (w 7 projektach C #). Rozwiązanie kompiluje się, ale nie można go debugować.
Rozwiązałem ten problem, uruchamiając następujące polecenie w konsoli Menedżera pakietów Nugeta:
PM> Pakiet aktualizacji Newtonsoft.Json
źródło
W przypadku mojej aplikacji WPF usunąłem folder aplikacji, ponownie „Pobierz najnowsze” z kontroli źródła i ponownie go przebudowałem. Wszystkie punkty przerwania działają teraz świetnie.
źródło
Spróbuj ustawić projekt aplikacji Silverlight jako projekt startowy: kliknij prawym przyciskiem myszy projekt -> 'Ustaw jako projekt startowy. Następnie naciśnij klawisz F5 i sprawdź, czy możesz złapać punkty przerwania ...
Spróbuj usunąć dane przeglądania / temp w przeglądarce za każdym razem, gdy wprowadzasz zmiany w aplikacji silverlight
źródło
Kolejna anegdota, która może być przydatna
Napotkałem ten problem, gdy jeden z moich projektów używał odniesień do plików z folderu wyjściowego wydania. Gdy wyniki kompilacji zostały umieszczone w folderze Towary, te biblioteki dll wydania zastąpiły dll debugowania.
Rozwiązaniem było upewnienie się, że w pliku csproj moja referencja to HintPath
<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>
i nie
<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>
źródło
Miałem ten problem, gdy na kliencie, gdzie - dla każdego rozwiązania aplikacji - skopiowali większość udostępnionych zestawów do folderu „ References ”, a następnie dodali je do rozwiązania jako „ przedmioty Rozwiązanie ” i jako „ projektu ” w roztworze.
Nie wiem jeszcze dlaczego, ale niektóre z nich były debugowalne, inne nie, mimo że w ustawieniach Odniesień dla zestawów podano prawidłowe pełne ścieżki.
To nieprzewidywalne zachowanie doprowadziło mnie do szału :)
Rozwiązałem ten problem, usuwając wszystkie zestawy z folderu „ References ”, dla których były projekty z kodem źródłowym, i bardzo dobrze śledząc informacje o wersji dla udostępnionych zestawów.
źródło
Miałem podobny problem, z tym że mój problem był głupi - miałem 2 instancje wbudowanego serwera WWW działającego pod 2 różnymi portami ORAZ mój projekt -> właściwości -> web -> „Start URL” wskazywał na stały port, ale aplikacja internetowa nie działała pod tym portem. Tak więc moja przeglądarka została przekierowana na „Początkowy adres URL”, który odwoływał się do 1539, ale instancja kodu / debugowania działała pod portem 50803.
Zmieniłem wbudowany serwer internetowy, aby działał pod stałym portem i dostosowałem swój „Start URL”, aby również z niego korzystać. project -> właściwości -> web -> sekcja „Serwery” -> „Użyj programu Visual Studio Development Server” -> określony port
źródło