Stark verzögertes Öffnen von Projekten in Visual Studio 2013

In der letzten Zeit hatte ich immer mal wieder so einen komischen Effekt, dass ich VS-2013 gestartet habe und beim Öffnen einer Solution auf einmal nur noch die Eieruhr (Blue Circle of Death) zu sehen war. In der Anzeige stand meisten das irgend ein Projekt N vom M zu laden wäre. 🙁
Als mir das das erste mal passierte habe ich oft den Visual Studio Prozess brachial beendet, neu gestartet und dann ging es oft. Aber nicht immer. Wenn ich lang genug gewartet hatte wurde letzten Endes die Projekte immer geladen.

Weil mich das irgendwann nervte habe ich mal versucht Visual Studio selbst zu debuggen. Die Threads die aktiv waren, hatten immer was mit dem Team Foundation Server zu tun. Bald merkte ich, dass lokale Projekte nie betroffen waren sondern immer nur Solutions, die auch auf unserem zentralen TFS Server lagen.

Der nächste Schritt 💡 war dann beim nächsten Hänger mal die Firewall und den Netzwerkschutz abzuschalten. Wir verwenden hier seit Jahren Symantec Endpoint Protection (aktuell 12.1 RU5). Bingo !!! 🙂 Kaum, dass ich die Firewall abgeschaltet hatte lief, das Laden des Projektes sofort durch.

Entsprechend haben wir in den Firewall Einstellungen für Visual Studio jetzt eine Ausnahme Regel definiert und seit dem keine Probleme mehr. :mrgreen:

 

8 Gedanken zu „Stark verzögertes Öffnen von Projekten in Visual Studio 2013“

  1. Debugging ist sehr langsam in VS2013, Einzelschritt-Debugging mit F10 und F11 ist wesentlich langsamer als in VS2010, in meinem MFC/C++-Quellcode, gibts da ähnliche Erfahrungen oder einen Fix für ?? Es war glaube ich ein Fehler, das VS zu wechseln. Kann man ein VS2013-Projekt wieder mit VS2010 öffnen, ich habe es nie ausprobiert ??

  2. Debuggen finde ich auch langsam. Besonders wenn man die erste Session am Tag startet. Dann dauert es irrsinnig lange bis alle PDB Dateien fremder Module zusammengesucht wurden. Das der Einzelschritt lange dauert ist mir so nicht aufgefallen. Ich verwende extrem oft Run-To-Cursorposition.

    Das mit dem Einzelschritt ist mir so nicht aufgefallen.

    Und ja man kann auch VS-2013 und in VS-2010 öffnen, wenn dieses installiert ist. Dort sieht man dann das Toolset für vs120.
    Debuggen habe ich so nicht probiert.

  3. Es ist IMMER die Firewall oder der Virenprotector! 🙂
    Ich muss die Onlineverbindung deaktivieren, sonst brauch der Debugger 2 Minuten bis er das Projekt startet, weil der VP erst alles untersuchen muss was da gerade im Netzwerk passiert. Oder ich schalte die Verhaltenserkennung ab, aber das will ja keiner. Darum Debuggen nur Offline.

  4. Danke für das Feedback !

    Ich habe VS2010 und VS2013 side-by-side installiert, und Kaspersky als Virenscanner, ich habe mehrere Projekte in der einen und in der anderen Version von Visual Studio. Wenn ich von VS2013 zurück auf VS2010 wechsle, dann bin ich richtig froh, dass plötzlich alles sehr viel schneller läuft. Also, selber PC, gleiches Antiviren-Programm, und ich meine, ich hätte das auch schon mit ausgeschaltetem Antiviren-Programm ausprobiert.
    Vielleicht ist das Einzelschritt-Debuggin mit F10, F11 in .NET schneller, keine Ahnung, auf jeden Fall ein deutlicher Zeitunterschied beim Debuggen.
    Irgendwann kam ne Anfrage vom Visual Studio Team und ich habe alles ausgefüllt, und vor allem darauf hingewiesen, dass VS2015 doch bitteschön wieder etwas schneller sein sollte. Möglicherweise liegt es daran, dass ich mehrere Updates nachinstalliert habe, die mir seitlich in der Benachrichtungszentrale von VS2013 angeboten wurden.
    Der Release-Termin von VS2015 rückt ja langsam näher, vielleicht ist ja da alles wieder schneller. Ich hoffe auch, dass das Kompilieren von MFC-Programmen für WindowsXP noch geht. Wir haben in unserer Firma nicht mit dem Internet verbundene Rechner auf Messwagen, die wir erst nach und nach updaten, wenn sie ausfallen. Daher benötige ich unbedingt noch das Kompilieren unter WinXP, kannst Du da bitte mal nachfragen, Martin, wenn Du zur ADC fährst, ob man mit VS2015 noch MFC-Programme für WinXP erzeugen kann ? Danke.

  5. Visual Studio 2015 RC ist da und kann als
    Community Edition auch kostenlos installiert
    werden. Nach der „typischen“ Installation
    fehlte der MFC Quellcode, nach Rückfrage
    beim VC Team, unter Umgehung der MSDN
    Foren :-), soll ich die die Installation nun reparieren
    und MFC mitauswählen. Also benutzerdefiniert installieren !
    Wenn man das Plattform Toolset vc140 in den
    Projekteinstellungen auswählt, kommt man dann nach
    10 überfälligen Jahren, auch in den Genuss, dass sich Kontrollelemente in
    Dialogen automatisch mitbewegen, wenn man den Dialog
    unten rechts aufzieht. Es gab dafür verschiedene andere
    Lösungen von Nanosoft oder codeproject CResizeDialog,
    die man jetzt wohl nicht mehr benötigt. Die IDE scheint
    auch schneller geworden zu sein. Alles weitere kann man im
    VCBlog nachlesen. Also hat man jetzt wieder ne Menge zum
    Herumexperimentieren.

  6. MFC-Programme, die mit VS2015RC erstellt werden, können ab jetzt nicht mehr lokal auf einem x-beliebigen Rechner installiert werden, sondern muss vcredist_x86.exe einmal vorher laufenlassen, da die Jungs von Microsoft die CRT in zig Teile aufgesplittet haben.

    Mit viel Mühe habe ich es heute dann doch geschafft, ohne die vcrdist_x86.exe auch nur 1x laufenzulassen, ein MFC-Programm lokal mit allen dazugehörigen DLL’s zu installieren. Das war ein Kampf !

    Allerdings benötigt man diesen Kampf nur dann, wenn man die MFC in einer gemeinsam verwendeten DLL benutzen will, wenn man MFC statisch einbindet, läuft die EXE wunderbar auch auf anderen Rechner ohne überhaupt irgendwelche Zusatz-DLL’s installieren zu müssen.

    In die Quere kam mir dann nur noch mein Antiviren-Programm, Symantec Endpoint Protection, was mir andauernd einen Virus im MFC-Exe vorgaukelt und es ständig in die Quarantäne isolieren wollte, bis ich dann eine Ausnahme-Regel verwendet habe.

    Perfekt ist das alles noch nicht, und das Aufsplitten der CRT in diverse Unter-CRT’s, eher ein Rück- als ein Fortschritt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.