it-swarm.com.de

Warum dauert das Laden meiner Lösung in Visual Studio so lange?

Wir haben eine wirklich große Lösung mit mehr als 200 Projekten und Tausenden von Dateien. Trotzdem wurde die Lösung in Visual Studio 2010 und 2012 ziemlich schnell geladen. Nachdem jedoch das gesamte SVN-Repository an einen anderen Speicherort kopiert wurde, dauerte das Laden und Schließen der Lösung plötzlich sehr lange. (Ich rede hier von 30-60 Minuten!)

37
gehho

Ich habe selbst eine Lösung gefunden und wollte sie hier teilen, in der Hoffnung, dass dadurch einige Stunden Recherche erspart und der Dialog "Lösung vorbereiten ..." angestarrt wird.

Bei der Überprüfung des Prozesses devenv.exe mit Process Monitor habe ich herausgefunden, dass der Zugriff auf das Verzeichnis .svn ziemlich voll ist. Folgendes habe ich getan (und das Problem wurde irgendwie gelöst):

  1. Töte Visual Studio
  2. Öffnen Sie Visual Studio, ohne eine Lösung zu laden
  3. AnkhSvn als Source Control-Plugin deaktivieren (Extras-> Optionen-> Source Control-> Plug-In-Auswahl-> Keine)
  4. Deaktivieren Sie "Document Well 2010 Plus" (VS2010) oder "Custom Document Well" (VS2012) in Productivity Power Tools (Extras-> Optionen-> Productivity Power Tools) - Ich habe das irgendwo gelesen und es könnte auch geholfen haben.
  5. Schließen Sie Visual Studio
  6. Löschen Sie die *.suo-Datei der Lösung. Dieser befindet sich im selben Ordner wie die Lösung selbst. HINWEIS: Sie verlieren einige Einstellungen für Ihre Lösung, wie aktuell geöffnete Dateien, Haltepunkte, Lesezeichen, aktuelle Lösungskonfiguration und -plattform (z. B. Debug x86) usw.
  7. Starten Sie Visual Studio neu
  8. Laden Sie die Lösung - jetzt war es viel schneller!
  9. Schließen Sie Visual Studio
  10. Öffnen Sie Visual Studio, ohne eine Lösung zu laden
  11. AnkhSvn und das "Document Well" erneut aktivieren
  12. Starten Sie Visual Studio neu
  13. Öffnen Sie die Lösung - sie wurde noch in Sekunden geladen!

Ich weiß nicht, welcher dieser Schritte das Problem tatsächlich gelöst hat. Wahrscheinlich sind nicht alle diese Schritte erforderlich, aber ich wollte das Problem nicht reproduzieren, um herauszufinden, welche Schritte möglicherweise ausgelassen werden. :)

65
gehho

Keines von denen hat mir geholfen, was ich getan habe ... Ich schaue mit ProcMon von sysinternals nach Devenv, und ich habe eine Menge Einträge von fussionlog gesehen. Ich hatte vor ein paar Wochen das Fussionlog zu Debugging-Zwecken aktiviert und dachte nicht daran, es zu deaktivieren. Ich musste nur Fussionlog deaktivieren und die Lösung wurde schneller geöffnet.

5
xisket

Sie können das Visual Studio im abgesicherten Modus öffnen und nach dem Öffnen des Projekts die Einstellungen für das Plugin und die Quellcodeverwaltung überprüfen. Der abgesicherte Modus bedeutet "Startet Visual Studio und lädt nur die Standardumgebung und die Standarddienste."

Wie :

devenv /SafeMode 

Oder nach deinem Weg

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode

quelle: https://msdn.Microsoft.com/en-us/library/ms241278.aspx

3
Tarek El-Mallah

In meinem Fall funktionierte Folgendes ohne die vorgeschlagenen dazwischenliegenden Schritte:

  1. Töte Visual Studio.
  2. Starten Sie Visual Studio direkt (d. H. nicht aus der .sln-Datei ).
  3. Öffnen Sie dann in Visual Studio die Lösung.

In meinem Fall war dies alles, um die Problemlösung schnell laden zu können, ohne dass ich Einstellungen ändern oder Dateien löschen musste.

1
Reg Edit

fwiw, mir ist klar, dass dies ein verspäteter Eintrag ist, aber ich habe festgestellt, dass das Entfernen (Löschen) meiner großen Anzahl von Haltepunkten die übermäßige Ladezeit und die Kompilierzeit behoben hat. Diese Aktion reduzierte die Größe der .suo-Datei von 214 MB auf 977 KB. Lassen Sie VS die .suo-Datei selbst handhaben. Das Übersetzen und Laden dauert bei einer Lösung mit 35 Projekten jetzt <1 Minute anstelle von 5-10 Minuten. Visual Studio 2012 Pro, Update 4.

1
jafo

Ich habe es ausprobiert, aber mein Problem wurde dadurch nicht gelöst.

So habe ich dieses Problem gelöst, hoffentlich wird es auch für einige von Ihnen funktionieren:

  1. Öffnen Sie Visual Studio 2013 ohne Lösung. 
  2. Erstellen Sie eine neue C # -Konsolenanwendung und speichern Sie sie. 
  3. Schließen Sie Visual Studio.
  4. Öffnen Sie die in Schritt 2 erstellte Console-Lösung erneut.
  5. Schließen Sie Visual Studio.
  6. Öffnen Sie die zuvor geöffnete Lösung erneut im Dialogfeld "Lösung wird vorbereitet". Meines öffnete sich sofort, kein Hängen mehr.
0
Yves Rochon

Keine der anderen Antworten funktionierte für mich. CI-Kompilierungszeiten waren in Ordnung, aber das Laden meiner Lösung in Visual Studio dauerte fast zwei Minuten. VS funktioniert dann einwandfrei, bis ich beim nächsten Mal die Lösung geschlossen und geöffnet habe. Verschiedene Versionen von VS zeigten das gleiche Problem und sowohl der abgesicherte Modus als auch das Löschen des suo haben nicht geholfen.

Ich folgte dem Rat in http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx , um Windows Performance Recorder zu verwenden, um VS zu instrumentieren und das Problem zu finden. Durch einen Blick in Windows Performance Analyzer im Abschnitt "CPU Usage (Sampled)" und Hinzufügen der Spalte "Stack (Frame Tags)" konnte ich in die Verwendung von devenv.exe eintauchen.

Stellt sich heraus, dass der Hot-Pfad durch die Anzahl der Aufrufe von Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 heruntergefahren wurde, und darunter schließlich Microsoft.VisualStudio.ServerExplorer.dll und Microsoft.VisualStudio.Data.Package.dll. Das hat mich dazu gebracht, im Server-Explorer in der Benutzeroberfläche nachzusehen und die Registerkarte Datenverbindungen zu öffnen. Dort habe ich hunderte von fälschlicherweise hinzugefügten Verbindungen gefunden, die aus dem ConnectionString-Abschnitt des Debug web.config stammen. Wenn Sie diese aus web.config entfernen, wurde die Last dieses einzelnen Projekts von 90 Sekunden auf fast sofort reduziert.

0
Jeremy Murray

Mit Visual Studio 2015 erstellte ich eine neue Lösung und fügte die vorhandenen Projekte hinzu. 

Das Löschen des * .suo aus der Antwort von gehho hat in der Vergangenheit geholfen, hat mir aber in diesem Fall nicht geholfen. Es gibt auch eine andere .suo-Datei in einem versteckten .vs-Ordner im Stammverzeichnis der Lösung.

Hier gibt es andere Antworten für Visual Studio 2015 Visual Studio 2015 ist extrem langsam

0
goodeye