Ich mache PHP-Entwicklung in Visual Studio, und meine Lösung enthält Projekte für PHP, SSRS und SQL Server (SSDT). Und ich verwende TFS für die Versionskontrolle. In meiner Entwicklungsumgebung passiert also eine Menge, die "schiefgehen" kann.
Ich habe zeitweilige Unterbrechungen, normalerweise etwa 5 Minuten pro Clip. Visual Studio gibt mir den Warte-Cursor, und wenn ich irgendwo in VS klicke, wird das Fenster abgeblendet. Und dann muss ich es einfach abwarten. Manchmal kann ich die devenv.exe-Task beenden, manchmal dauert es einige Minuten, um die Task zu beenden. Wenn ich geduldig bin, warte ich einfach und irgendwann (ca. 5 Minuten) kommt VS wieder zum Leben. Ich habe noch nie einen Datenverlust, Probleme mit der Quellcodeverwaltung usw. erlebt, selbst wenn ich den Prozess beende.
Manchmal passiert es, wenn ich speichere. Manchmal, wenn ich einchecke. Manchmal, wenn ich auschecke. Manchmal, wenn ich baue. Ich konnte kein Muster des Verhaltens erkennen.
Alle meine Workstation-Ressourcen sind in Ordnung - kein RAM oder I / O oder Netzwerk- oder CPU-Probleme.
Was kann ich tun, um dieses Problem zu beheben? Kann ich VS in einer Art Protokollierungsmodus ausführen, mit dem ich genau feststellen kann, was in diesen Sperrzeiten so lange dauert?
Um die Anmeldung im Visual Studio zu aktivieren, führen Sie den Befehl: devenv.exe / log
ausIch persönlich würde dies mit einer Abkürzung tun.
Ziehen Sie in Betracht, alte TFS-Workspace-Definitionen zu löschen, die von Continuous Integration Builds übrig geblieben sind.
Wir hatten das gleiche Problem mit einer großen Projektstruktur von Team Foundation Server. Manchmal, aber nicht immer, würde das Öffnen einer Lösung in Visual Studio 2010 oder Visual Studio 2012 exakt so erfolgen, wie oben beschrieben. VS 2010 war am verletzlichsten; VS 2012 schien weniger anfällig, aber es würde immer noch hängen.
Wir konnten einige Hinweise erhalten, indem wir die Serveraktivität auf dem TFS-Server-Computer und dem zugrunde liegenden SQL Server-Computer überwachen. Eine bestimmte gespeicherte Abfrageprozedur verwendete in SQL Server zu lange CPU-Zeit. Wir haben diesen Namen für eine gespeicherte Prozedur in einer TFS-Operation nachverfolgt, die beim Scannen von TFS-Arbeitsbereichdefinitionen für die Überprüfung von Dateien durch andere Benutzer verwendet wurde.
Unsere TFS-Umgebung wird seit über drei Jahren verwendet, und wir verwenden Continuous-Integration-Builddefinitionen mit einer "Zombie-Armee" von Entwicklerarbeitsstationen als TFS-Build-Agent-Hosts. Wir erstellen auch neue TFS-Zweige für Hauptversionen. Jeder Zweig enthält etwa 20 separate Visual Studio-Lösungen mit eigenen Build-Definitionen.
Im Laufe der Zeit hatten wir auf jeder Entwickler-Workstation ungefähr 2.000 TFS-Workspace-Definitionen gesammelt. Wir hatten ungefähr 10 Arbeitsplätze gleichzeitig mit ihren eigenen Definitionen.
Mit dem Visual Studio-Befehlsfenster und der Ausführung als TFS-Administrator haben wir diesen Befehl verwendet, um alle Arbeitsbereiche zu identifizieren, die von unserem "build user" erstellt wurden:
tf workspaces / sammlung: tfservername \ sammlungsname / eigentümer: unserbuilduser & gt; c: \ tf_ws_del.bat
Wir haben dann globale Substitute und den Notepad ++ Editormakro-Rekorder verwendet, um jede Ergebniszeile in diese Form zu konvertieren:
tf workspace / delete / collection: tfservername \ sammlungsname arbeitsbereichsname; unserbuilduser & lt; c: \ ja.txt
wobei C: \ yes.txt eine einzelne Zeile von "y" enthielt
Wir haben auch ein menschliches Urteilsvermögen verwendet, um Löschzeilen für Arbeitsbereiche zu entfernen, die für unseren letzten TFS-Zweig benannt sind.
Wir haben dann das c: \ tfs_ws_del.bat-Skript im selben Visual Studio-Befehlsfenster ausgeführt und geduldig gewartet, bis es beendet ist.
Endergebnis: Unsere Visual Studio-Lösungen öffnen sich sehr schnell. Selbst das Durchsuchen der Ordnerhierarchie im Quellcode-Explorer hat sich erheblich beschleunigt.
WARNUNG: Die Löschvorgänge für eine sehr große Anzahl von Arbeitsbereichen erweitern möglicherweise die TempDB auf dem zugrunde liegenden SQL Server um einen großen Betrag. Koordinieren Sie mit Ihren DBAs, um Speicherplatz auf dem SQL Server-Computer zu überwachen. Durch das Stoppen und Neustarten der TFS-Sammlung über das grafische TFS-Verwaltungskonsole-Tool können Sie einen Teil dieses TempDB-Bereichs zurückerhalten und in die interne Liste der "freien Blöcke" zurückversetzen.
Das kann auch passieren, wenn die in Ihren Debug-Optionen angegebenen Symbol-Server nicht erreichbar oder erreichbar sind ... es wird in diesem Fall nicht wirklich hängen bleiben, aber es scheint für jedes Dateizugriffsdatum eine Zeitüberschreitung zu haben.
Um dieses Problem vorübergehend zu umgehen, deaktivieren Sie die Symbolserver, die nicht aktiv sind.
Tags und Links visual-studio-2012 hang