Visual Studio figeant à l’ouverture du projet

Mon Visual Studio semble être gelé / en retard lorsque j’ouvre un projet existant. J’ai ajouté le cadre NHibernate dans mon code et il semble que mon ordinateur soit à la traîne (du moins c’est ce que je pense). Lorsque j’ouvre d’autres projets, je ne gêne pas du tout. Le gel dure environ 3 secondes à une minute, puis mon projet est ouvert et il agit simplement très lentement. Cela peut prendre plus de 20 secondes pour changer de classe et plus de 20 secondes pour saisir un seul personnage dans Visual Studios.

Je me demandais si quelqu’un avait déjà eu ce problème auparavant. Si oui, comment l’avez-vous corrigé?

Je ne peux pas vraiment travailler sur mon code tant que ce problème n’est pas corrigé. Oh aussi, quand le code est sauvegardé, il se fige pendant une bonne minute ou deux.

Vous pouvez voir exactement ce que VS fait à tout moment, si vous attachez un débogueur au processus devenv.exe et cliquez sur Pause quand il se bloque. Chargez ensuite les symboles à partir du serveur Microsoft Symbols et affichez la stack d’appels pour le thread principal du VS.

J’ai écrit un article très détaillé sur la façon de déboguer les accidents et se bloque ici: http://blogs.msdn.com/kirillosenkov/archive/2008/12/07/how-to-debug-crashes-and-hangs.aspx

À partir de la stack d’appels, la cause du retard devrait être évidente.

Avait le même problème. Fermé Visual Studio 2010, ouvert à nouveau Exécuter en tant qu’administrateur, accédé à Extension Manager, désinstallé Nuget Package Manager, redémarré Visual Studio 2010 en tant qu’utilisateur normal, solution du problème ouverte, solution correctement ouverte.

Nuget Package Manager semble en être la cause. La solution à mon problème consiste à utiliser EF 4.3 Code First, qui interagit fortement avec la console du gestionnaire de packages, mais il se peut que ce soit juste une coïncidence.

Pour moi, la suppression du fichier suo (du sous-répertoire v14) a résolu le problème …

J’avais l’impression que quelque chose avait été corrompu avec l’un de mes paquets NuGet et j’ai complètement supprimé le sous-dossier \packages et son contenu. Lorsque j’ai rouvert la solution, tous les projets ont été chargés avec succès sans être suspendus.

À partir de là, j’ai restauré les packages précédemment supprimés à partir de la console NuGet Package Manager et j’étais de nouveau opérationnel.

Comme réponse de Visual Studio 2015, la solution de chargement en blanc .vs supprimer le .vs caché .vs résolu le problème pour moi.

J’utilise Visual Studio 2017 Community Edition.

Quoi, si des compléments avez-vous installés?

Modifier:

Une suggestion que je voudrais alors est de désactiver systématiquement chacun de vos compléments et de voir si les performances changent et si cela recherche le coupable et voir s’il existe des mises à jour disponibles.

Désinstallez tous les compléments MS Enterprise Framework que vous pourriez avoir .

Supprimez le répertoire temporaire VS (et celui Windows).

Utilisez-vous TFS? Le serveur est peut-être un peu endormi, cela le fera geler pendant quelques minutes, mais ça ira après.

Pour moi, un chkdsk /F /R (qui vous incitera à redémarrer) et environ 30 minutes de temps de la société a résolu ce problème.

Je pense que quelques instances mal fermées de Visual Studio ont peut-être été atsortingbuées au problème.

Mes fichiers locaux ont en quelque sorte été corrompus pour un projet. Heureusement, je n’avais aucune modification en attente. Plutôt que de lancer chkdsk, j’ai simplement supprimé le dossier et extrait à nouveau la solution du contrôle de code source.