Visual Studio se bloque constamment pendant la construction

Probablement entre 25 et 50% des fois où je construis ma solution, je vois ceci:

” L’opération que vous avez demandée prend plus de temps que prévu. Cette boîte de dialog se fermera à la fin de l’action. ”

Je déteste cette fenêtre d’une manière que je ne peux pas décrire. Il ne se résout jamais, le bouton Annuler n’est jamais activé, et le seul moyen d’y remédier est de tuer le processus devenv et de recharger toute ma solution, sachant très bien que je n’ai rien résolu et que je suis également susceptible de voir le Même chose quand je tente ma construction.

Ma solution comprend au total environ 60 projets, principalement des bibliothèques de classes C #, avec quelques applications Web, services Web et applications de console. Cependant, le problème persiste même lors de la construction d’une tranche du code avec la majorité (50) des projets déchargés.

Mon problème est que les fenêtres de sortie ne me disent rien au moment où elles gèlent, et je ne sais pas comment déterminer la cause de ce blocage. Si je devais deviner, je suppose que c’est une impasse dans le système de fichiers ou quelque chose, mais je ne sais pas comment faire pour le prouver – encore moins comment le prévenir.

Que puis-je faire pour diagnostiquer et éliminer ceci de ma solution afin que je ne le revoie plus jamais? En général, comment puis-je diagnostiquer les problèmes qui surviennent lors d’une génération?

Si le problème était similaire, VS restait suspendu pendant environ 45 secondes, puis construit pendant 4 secondes et terminé. Les 45 secondes de blocage ne produiraient aucune sortie vers l’interface graphique et VS se bloquerait.

En utilisant ProcMon, je pouvais voir plus de 3 millions d’opérations sur le dossier / packages / via devenv.exe lorsque je construirais ce projet (et continuerait encore quelques temps) !! Les premières étapes de la construction vous permettent de vérifier qu’il vérifiait CHAQUE PACKAGE pour voir s’il devait faire une restauration de paquet (ce n’était pas le cas)

Comme j’ai tendance à blâmer NuGet pour tout, j’ai désactivé la case à cocher Nuget Package Restore “permettre à NuGet de télécharger les paquets manquants” sous Visual Studio -> Options -> Gestionnaire de paquets Nuget -> Général . Pour ma plus grande joie, la construction a été très rapide. 5 secondes au total!

Il s’avère que nous avons activé la restauration du package sur la compilation activée (je pense que cela est activé par défaut maintenant dans VS) ET que les packages ont également été vérifiés dans le contrôle de code source. Il semble que cela provoque une certaine faille de TFS … La vérification de la restauration du package doit déclencher la vérification par TFS de certaines opérations de contrôle de code source.

Pour info, il s’agissait de VS2013 UPDATE 4 – Nuget version: 2.8.50926.663 .. sur un sln avec NumberOfProjects = 38, mais je pourrais recréer ce blocage en construisant un simple csproj avec 2 dépendances.

Mettre à jour:

Localhost “Rebuild All” sur Sln avec SccNumberOfProjects = 53 prenait 7h05 avec 2 minutes de studio visuel figé / sans réponse

  • vers le bas à 4:14 sur un 2 Core i5 sans gel
  • vers le bas à 2:44 sur un 4 Core i7

En outre: Ceci était sur une machine avec divers outils de sécurité de l’observateur de fichiers, probablement sans append de vitesse à tout ce processus … et peut-être à blâmer.

J’ai vu cela se produire sur les grands projets lorsque MSBuild est en cours d’exécution avec le commutateur de diagnostic activé. Dans Visual Studio, accédez à Outils / Options / Projets et solutions / Créer et exécuter, puis vérifiez la valeur de verbosité de sortie du projet MSBuild. Si ce n’est pas défini sur Minimal, essayez de définir à minimal et voir si vos builds sont en mesure de terminer.

Il semblerait que Visual Studio ait été résolu en tant qu’administrateur pour résoudre le problème! (Pour toujours exécuter un programme en tant qu’administrateur, voir Exécution de Visual Studio en tant qu’administrateur par défaut )

J’ai trouvé que Visual Studio était très impliqué dans la création de projets plus importants. Il s’avère que c’était ReSharper. Après l’avoir éteint: Outils -> Options -> ReSharper -> Suspendre maintenant, tout fonctionne correctement sans problèmes (même sur les très grandes solutions, plus de 100 projets)

Il y avait une suggestion sur Microsoft Connect que le projet de modélisation était responsable des gels. J’ai retiré un projet de modélisation de notre solution et je n’ai plus eu de gel depuis (environ une semaine).

Dans mon cas, la définition du “nombre maximum de projets parallèles” à 1 (c.-à-d. Créer un projet à partir de l’état propre provoque un gel de 1 min suivi d’une construction normale et chaque construction ultérieure fonctionne correctement).

Les parameters susmentionnés peuvent être définis dans Tool -> Options -> Projects and Solutions -> Build and Run .

Pour moi, le problème était une extension qui exécute automatiquement les modèles T4 lors de la génération (AutoT4). La désactivation lors de l’utilisation de solutions avec EF a résolu le problème.

Essayez simplement la commande ci-dessous avec le mode admin. Avant d’exécuter cette commande, assurez-vous de fermer toutes les instances de VS.

 devenv /resetuserdata 

Remarque: devenv est situé dans C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE

En plus de la réponse de felickz qui résout (ou résout presque) ce problème pour les builds:

Excepté le problème lors d’une construction, j’ai également rencontré un problème avec la console de gestion des packages. Il a fallu environ une minute pour l’attendre. En utilisant procmon, j’ai trouvé que le dossier du référentiel NuGet était analysé à chaque ouverture de cette fenêtre (très intelligent, Microsoft!). Il y avait environ 1000 paquets dans ce dossier. Après avoir tout enlevé du dossier ci-dessus, le problème de performance s’est dissipé.

Notez que ma réponse concerne le VS 2015 (et peut-être ci-dessous). Je n’ai pas testé, mais suspect dans VS 2017 ça devrait aller.

Pour moi, c’était quelque chose à faire avec l’installation du paquet npm qui s’exécutait automatiquement. Je suis allé dans Outils> Options> Projet et solutions> Outils Web externes et décoché tous les outils externes et redémarré VS. Après cela, j’ai pu le reconstruire. Je sais que j’ai besoin de les vérifier, mais je dois comprendre ce qui les déclenche et ce qui ne va pas avec ce fichier de solution.

J’ai déplacé ma plate-forme de développement VS 2008 de Windows 7 vers Windows 10 et je me suis retrouvé dans une situation où Visual Studio raccrochait à chaque fois que je tentais de créer un grand projet. J’ai dû construire le projet, puis utiliser le gestionnaire de tâches pour tuer VS et ensuite redémarrer. Inutile de dire que cela a rendu le débogage vraiment difficile! Quoi qu’il en soit, le problème était que, en passant à Win 10, VS ne fonctionnait plus en tant qu’administrateur (et peut-être que Win 10 est plus particulier en ce qui concerne les privilèges). Modification des propriétés pour que le programme s’exécute en tant qu’administrateur a résolu le problème. (IngoB – Je n’ai pas assez de statut pour commenter votre message, mais merci de le signaler!)