Visual Studio 2013 zawiesza się podczas otwierania rozwiązania

Zainstalowałem VS2013 (v12.0.21005.1) i dodałem ReSharper 8 (v8.0.2000.2660) dzień lub dwa temu. Tego dnia było dobrze. Teraz mam szczęście, jeśli uda mi się otworzyć jedno rozwiązanie w ciągu całego dnia. Otwiera się samo z siebie, ale kiedy próbuję otworzyć rozwiązanie od wewnątrz - przez menu - zawiesza się, źle. Jeśli kliknę prawym przyciskiem myszy rozwiązanie w Eksploratorze Windows i „otwórz za pomocą VS 2013”, zostanie ono otwarte, a następnie zawieszone, dokładnie w ten sam sposób. Od czasu do czasu, godzinami, dostaję małą uwagę, że jest czymś zajęty.

Czy ktoś wie, co może być nie tak, zanim zniosę ponowną instalację, która nie rozwiąże problemu?

Czasami wystarczy po prostu usunąć plik „.v12.suo” i ponownie spróbować otworzyć rozwiązanie. Pomógł mi wiele razy, gdy VS2013 zawieszał się podczas ładowania projektu.

Usunięcie wszystkich plików „.suo” działało u mnie. Powstało kilka kopii z powodu otwarcia rozwiązania w wielu wersjach programu Visual Studio.

Edytować:

Możliwa ścieżka to:

PathToSolution \ .vs \ ProjectName \ v14 \

.vs może być folderem ukrytym.

.suo to nazwa pliku.

Zasadniczo może to być wszystko, ale możesz spróbować kilku rzeczy:

1. Wyłączam i włączam ponownie.
2. Wyczyść pamięć podręczną ReSharper, jest w %LOCALAPPDATA%\JetBrains\ReSharper\<CurrentVersion>\SolutionCaches, w której powinieneś znaleźć folder pasujący do rozwiązania, które próbujesz otworzyć. Po prostu zamknij wszystkie wystąpienia VS2013, usuń folder i spróbuj ponownie.
3. wyłącz ReSharper: Tools > Options > ReSharper > General > Suspend
4. całkowicie odinstaluj ReSharper i sprawdź, czy problem nadal występuje.
5. Napraw program Visual Studio za pośrednictwem Programs and Features.

Okazało się, że poniższe podejście jest lepszym podejściem do debugowania VS na podstawie instrukcji MS Connect

Proszę o pomoc w potwierdzeniu, czy przechwycony plik zrzutu jest 32-bitowym plikiem zrzutu. Jeśli jest to 64-bitowy plik zrzutu, wykonaj następujący krok, aby przechwycić nowy plik zrzutu.

1. Uruchom program Visual Studio.
2. Uruchom kolejną instancję VS.
3. W drugim przypadku kliknij Narzędzia | Dołącz do przetwarzania ...
4. Na liście procesów zlokalizuj devenv.exe.
5. Kliknij Wybierz ... i wyraźnie wybierz kod „Natywny” i „Zarządzany”.
6. Kliknij OK i OK, aby zamknąć okno dialogowe Wybierz i Dołącz do procesu.
7. Wróć do pierwszej instancji VS i powtórz zawieszenie.
8. Po zawieszeniu sterowanie powinno przejść do drugiej instancji VS. Jeśli nie, wróć ręcznie do drugiej instancji VS i naciśnij „Przerwij wszystko”.
9. W drugim przypadku kliknij Debuguj | Zapisz zrzut jako minidump ze stertą.

Jeśli używasz profilu VB, nie zobaczysz opcji menu Zapisz zrzut jako. Aby dodać tę pozycję menu:

1. Wybierz Narzędzia -> Dostosuj
2. Wybierz kartę Polecenia
3. Wybierz Debuguj z menu rozwijanego paska menu
4. Kliknij Dodaj polecenie ...
5. Wybierz Debuguj z listy Kategorie.
6. Znajdź pozycję Zapisz zrzut jako w oknie Polecenia.
7. Kliknij OK (polecenie Zapisz zrzut jako ... jest dodane na górze menu Debugowanie).
8. Kliknij Zamknij

Szczegółowe instrukcje dotyczące pobierania pliku zrzutu i stosu wywołań można znaleźć pod adresem http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do- i-create-one.aspx

Jeśli okaże się, że problem dotyczy dodatku Resharper, możesz zgłosić go za pośrednictwem - http://youtrack.jetbrains.com/issues/RSRP

Wstrzymywanie Resharpera pracowało dla mnie. Iść do

Narzędzia -> Opcje -> ReSharper -> Ogólne -> Wstrzymaj teraz

Twoje rozwiązanie będzie się teraz ładować bardzo szybko. Po pełnym załadowaniu rozwiązania możesz zmienić ustawienia Resharper na Resume Now .

Czy używasz w swoim projekcie jakichś modułów węzłów? A może możesz stwierdzić, że jest to problem związany z programem ReSharper?

Jeśli masz moduły NPM (np. Dla Grunt), oznacz folder „node_modules” jako „ukryty” (nie ma potrzeby ukrywania folderów podrzędnych) i spróbuj ponownie.

Visual Studio zawieszało się dla mnie jako otwarte, okazało się, że próbował przeskanować głęboko zagnieżdżone moduły węzłów ze ścieżkami plików dłuższymi niż maksymalne Windows (260 znaków), co uniemożliwiało mi otwarcie rozwiązania w VS, ale oznaczało folder jako ukryty rozwiązał problem.

Niedawno miałem ten problem i stwierdziłem, że odłączenie komputera od Internetu podczas ładowania projektu rozwiązało problem. Dzięki temu udało mi się skrócić czas ładowania z kilku godzin do kilku sekund. Ponieważ mój kabel sieciowy nie jest szczególnie dostępny, po prostu wyłączyłem kartę sieciową przed załadowaniem projektu (w Panelu sterowania).

Wkrótce jednak stało się to frustrujące i ostatnio ponownie przyjrzałem się temu problemowi. Wygląda na to, że zalogowanie się do mojego konta Microsoft w Visual Studio ostatecznie rozwiązało problem i nie mam już problemów z ładowaniem projektów.

To może zadziałać również dla Ciebie (jeśli jeszcze tego nie naprawiłeś - ale ponieważ nie ma tutaj zaakceptowanej odpowiedzi, zakładam, że problem nadal występuje), więc sugeruję przynajmniej spróbować rozłączyć się z Internetem, nawet jeśli wolisz nie wprowadzać swoich poświadczeń Microsoft.

Wszedłem do% LOCALAPPDATA% \ JetBrains \ ReSharper \ i otworzyłem wszystkie katalogi w poszukiwaniu SolutionCache i opróżniłem je wszystkie. Problem rozwiązany. Aplikacja była dość duża, więc to pomogło.

Sprawdź aktualizacje systemu Windows

Ja też miałem ten problem. Ponadto nie mogłem otworzyć ustawień zapory systemu Windows (próbowałem zablokować połączenie internetowe VS).

Podczas otwierania ustawień aktualizacji (Windows 8) zobaczyłem oczekującą aktualizację („znaleziono dzisiaj”), więc uruchomiłem ponownie komputer, pozwalając na aktualizację systemu Windows. Potem VS i firewall znów działały dobrze.

Sprawdź swój sprzęt

Miałem problem po raz drugi; nawet strona aktualizacji systemu Windows 8 będzie ładować się wiecznie. To był problem z moim dyskiem twardym (innym niż OS): /superuser/756261/various-parts-of-windows-8-and-visual-studio-2013-get-blocked-by- prawdopodobnie-comm? noredirect = 1 # comment978074_756261

Ten problem pojawia się od czasu do czasu - VS 2013 Update 2, Win 8.1, IE 11.

Spróbuj tego - otwórz menedżera zadań, wyłącz zawieszoną aplikację VS, a następnie zamknij wszystkie sesje IE, które są uruchomione na liście procesów w tle - może się tam znajdować co najmniej jedna.

Uruchom ponownie VS

Wydaje się, że to dla mnie wyczyściło, bez ponownego uruchamiania.

Problem, jaki miałem, to połączenie Perforce.

Podczas otwierania rozwiązania zapyta, czy chcę, aby łączyło się z Perforce. Zezwolenie na próbę spowodowałoby zawieszenie się i przydzielenie 1,5 GB pamięci RAM.

Brak zezwolenia na połączenie P4 pozwala na prawidłowe załadowanie (przydzielenie 1 GB RAM). Wtedy mógłbym powiedzieć mu, żeby połączył się później z P4 i teraz jest dobrze.

Dla mnie, czy komputer zawiesza się z zanikiem zasilania, czy czasami z obowiązkowymi restartami w środku nocy. Co WORK for me

USUŃ WSZYSTKIE PLIKI W TYM KATALOGU:

C:\Users\yourusername\AppData\Local\Microsoft\WebsiteCache\

Dla każdego, kto nadal to polecił, pomogło mi:

Musiałem zawsze usuwać plik .vs12.suo, aby załadować projekt.

Natknąłem się na ten wątek od firmy Microsoft, a następnie utworzyłem wpis rejestru, który naprawił mój problem z ładowaniem rozwiązania.

https://connect.microsoft.com/VisualStudio/feedback/details/860685/visual-studio-hangs-after-10s-when-loading-solution-corrupt-suo

Miałem podobny problem, kiedy sprawdzałem plik rozwiązania, który został utworzony przez VS.Net 2012. Aby rozwiązać problem, utworzyłem fałszywy plik rozwiązania i przeładowałem projekty z vs.net 2012.

Zaobserwowano również, gdy aktualizacja pakietu NuGet została zepsuta, podczas ponownego ładowania rozwiązania program Visual Studio może się zawiesić.

Program Visual Studio może zawiesić się, gdy wystąpił problem podczas ładowania pakietów NuGet.

W moim przypadku VS 2013 Professional wisiał na każdym starcie, nawet bez otwierania rozwiązania, ponieważ licencja nie była już ważna.

Ostatnia pozycja w pliku dziennika:

<entry>
    <record>367</record>
    <time>2015/07/13 20:11:05.051</time>
    <type>Information</type>
    <source>UserConnection</source>
    <description>myemailaddrs@gmail.com signed in for IDE user</description>
</entry>

A na stronie subskrypcji msdn.microsoft.com: „Twoja subskrypcja nie jest już aktywna, skontaktuj się z administratorem”.

Musiałem uzyskać zaktualizowaną subskrypcję od mojego pracodawcy.

Usunięcie wyników testu z folderu TestResults faktycznie załatwiło sprawę. Kolejna rzecz do wypróbowania.

VS2012 zawiesza się na mnie, np. Podczas otwierania pliku csproj w udziale sieciowym (w rzeczywistości na udziale, który był na hoście VirtualBox, podłączony jako udział smb za pomocą funkcji VirtualBox).

Skopiowanie projektu na dysk lokalny naprawiło to za mnie.Nie jestem pewien, czy przypisanie litery dysku załatwi sprawę.

Nie jestem też pewien, dlaczego nie działa przez udział sieciowy, czy jest to ograniczenie VS, czy może jakaś wtyczka (oczywiście używam resharpera).

Wydaje mi się, że ma to coś wspólnego z projektem mającym guid ( E3E379DF-F4C6-4180-9B81-6769533ABE47) typu projektu MVC 4 . Usunięcie tego przewodnika z .csprojrozwiązania rozwiązało kwestię powieszenia dla mnie. ( .vsPo usunięciu guid wymagane było dodatkowe wyczyszczenie folderu).

Właśnie usunąłem folder „packages” z katalogu głównego rozwiązania i pomogło mi to (Visual Studio Express 2015)

Przepraszam, że muszę utworzyć nowy post zamiast komentować wybraną odpowiedź. W tej chwili nie mam wystarczającej liczby przedstawicieli, aby komentować.

Mój problem został tymczasowo rozwiązany przez rozwiązanie „... usuń plik .suo ...” i jak zauważyli inni ludzie, za każdym razem musiałem usuwać plik.

Ponieważ (najwyraźniej) nie można zatrzymać tworzenia pliku, zacząłem dokładniej analizować, co robi plik. Uważam, że oprócz zapisywania ustawień użytkownika zapisuje również ustawienia sesji, takie jak pliki, które otwierasz, gdy VS jest zamknięty. Podejrzewałem, że mój projekt próbuje otworzyć plik, który już nie istnieje i to jest przyczyną zawieszenia. Rozwiązaniem było usunięcie pliku .suo, otwarcie VS, otwarcie pliku w moim rozwiązaniu, skompilowanie i zamknięcie rozwiązania. Po zrobieniu tego nie miałem żadnych zawieszeń.

tl: dr

W moim przypadku plik ustawień użytkownika (.suo) próbował otworzyć plik w moim rozwiązaniu, który już nie istnieje. Rozwiązałem problem, wykonując następujące czynności.

1. Usuń plik .suo (dla mnie to było w /[projectfolder]/.vs/[nazwaprojektu]/v14
2. Otwórz program Visual Studio
3. Otwórz swój projekt
4. Otwórz plik (po prostu otworzyłem losowy plik .cs)
5. Zbuduj i zapisz swoje rozwiązanie (samo oszczędzanie może załatwić sprawę, ja zbudowałem z przyzwyczajenia)
6. Zamknij program Visual Studio

Mam nadzieję, że to komuś pomoże ... spędziliśmy zbyt wiele godzin nad tym problemem :)

Spróbuj odinstalować rozszerzenia za pomocą „Panelu sterowania” lub wyłącz dowolny dodatek w [Narzędzia] => [Menedżer dodatków], a następnie spróbuj ponownie otworzyć rozwiązanie.

Mój problem został rozwiązany przez odinstalowanie programu „Visual Localizer”.

W moim przypadku dziennik Fusion został włączony. Pliki dziennika rosły od miesięcy, ponieważ zapomniałem go wyłączyć po dochodzeniu. W ten sposób oprogramowanie antywirusowe zaczęło kilkakrotnie sprawdzać te duże pliki dziennika podczas otwierania rozwiązania, a komunikat „Przygotowuję rozwiązanie…” jest widoczny przez długi czas. Kiedy to zauważyłem, wyłączyłem dziennik fuzji i problem został rozwiązany. Rozwiązanie ładuje się w 10 sekund zamiast 20 minut.

Miałem ten problem wiele razy, w prawie wszystkich wersjach VS. Jedynym rozwiązaniem, które wydaje się działać w większości przypadków, jest usunięcie folderu .vs znajdującego się w folderze rozwiązania. Czasami wystarczy usunąć plik .sou znajdujący się w .vs ///

Folder jest przy okazji ukryty, więc musisz włączyć opcję „Pokaż ukryte pliki i foldery”

Dla mnie rozwiązaniem było wyłączenie kontroli źródła (ustaw wtyczkę na None w Tools-> Source Countrol). Myślę, że z jakiegoś powodu próbowałem zsynchronizować ogromne repozytorium Git (mam kilka ogromnych repozytoriów, ale nie w drzewie, które próbowałem otworzyć).

Wiele sugestii tutaj i gdzie indziej, ale jedyna rzecz, która na stałe działała dla mnie, dotyczyła projektu startowego, który wyznaczyłem. Oto co zrobiłem:

1. Usuń plik .suo zgodnie z sugestią w innym miejscu.
2. Uruchom VS i otwórz rozwiązanie. W tym momencie wszystko powinno być dobrze.
3. Zostaw projekt startowy taki, jaki jest, nawet jeśli nie jest to tym, czego chcesz.
4. Zapisz rozwiązanie. (Prawdopodobnie zrób to, co sugeruje ktoś inny i otwórz plik, wyczyść, zbuduj / odbuduj itp., Ale nie musiałem tego robić).
5. Zamknij rozwiązanie i wyjdź z VS.
6. Uruchom ponownie VS i otwórz rozwiązanie.
7. Zmień projekt startowy na taki, jaki powinien być
8. Zapisz rozwiązanie. (Prawdopodobnie ponownie otwórz plik, wyczyść, zbuduj / przebuduj itp.)
9. Zamknij rozwiązanie i wyjdź z VS.
10. Uruchom ponownie VS i ponownie otwórz rozwiązanie i wszystko powinno być dobrze.

To może zadziałać lub nie, ale próbowałem wszystkiego, co mogłem znaleźć - zmian w rejestrze, debugowania VS z drugiej sesji VS, możesz to nazwać - ale nic innego nie działało przez więcej niż jeden start / otwarcie.

Rozwiązałem problem, odinstalowując te dwie wtyczki:

1. Wydajne elektronarzędzie
2. Podstawowe informacje o sieci

Przywróciłem poprzednią wersję pliku .vbproj i rozwiązałem to.

Nie wiem, co było w nowszej wersji, ale problem tkwił w samym pliku .bvproj.