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. 
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 ??
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.
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.
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.
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.
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.
Das hört sich fast an wie die Manifest Katastrophe, die mit VS-2005 kam… Wenn ich mich nicht verrechne würde Microsoft dann mit VS-2020 wieder zurück rudern… 🙁