Visual Studio se bloque constamment pendant la construction
Probablement entre 25 et 50% des fois où je construis ma solution, je vois ceci:
Je déteste cette fenêtre d'une manière que je ne peux pas décrire. Cela ne 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 charger à nouveau toute la solution, sachant pertinemment que je n'ai rien corrigé et que je suis tout aussi susceptible de voir la même chose quand j'essaye de construire.
Ma solution concerne environ 60 projets au total, qui sont pour la plupart des bibliothèques de classe 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 de la base de 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 point de geler, et je ne sais pas comment déterminer la cause de ce blocage. Si je devais deviner, je supposerais que c'est une impasse dans le système de fichiers ou quelque chose du genre, mais je ne sais pas comment le prouver, encore moins comment le prévenir.
Que puis-je faire pour diagnostiquer et éliminer cela de ma solution afin de ne plus jamais la revoir? En général, comment puis-je diagnostiquer les problèmes survenant lors d'une construction?
En cas de problème similaire, VS resterait suspendu pendant environ 45 secondes, puis durerait 4 secondes et serait 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 de fichiers sur le dossier/packages/via devenv.exe lorsque je construirais ce projet (et continuerais pendant un certain temps après) !! Les premières étapes de la construction, vous pouvez voir qu’elle vérifiait CHAQUE PAQUET pour voir s’il fallait effectuer une restauration de paquet (ce n’était pas le cas).
Puisque j'ai tendance à blâmer NuGet pour tout, j'ai désactivé la case à cocher Nuget Package Restore "autoriser NuGet à télécharger les packages manquants" sous Visual Studio -> Options -> Nuget Package Manager -> Général . À ma grande joie, la construction a été très rapide. 5 secondes au total!
Il s'avère que nous avions activé la restauration de paquet lors de la construction (je pense que cela est activé par défaut maintenant dans VS) ET nous avons également fait vérifier les paquets dans le contrôle de source. Il semble que cela provoque le blocage de TFS d'une manière ou d'une autre ... la vérification de la restauration d'un paquet doit obliger TFS à effectuer certaines vérifications d'opération de contrôle de source.
Pour info c'était VS2013 UPDATE 4 - Version Nuget: 2.8.50926.663 .. sur un sln avec NumberOfProjects = 38, mais je pourrais recréer ce blocage en construisant un seul csproj avec 2 dépendances.
Mettre à jour:
Localhost “Rebuild All” sur Sln avec SccNumberOfProjects = 53 prenait 07h05 avec 2 minutes de Visual Studio figé/ne répond pas
- jusqu'à 4:14 sur un i5 à 2 cœurs sans gel
- jusqu'à 2:44 sur un i7 à 4 cœurs
En outre: il s’agissait d’une machine dotée de divers outils de sécurité pour l’observateur de fichiers, ce qui n’ajouterait probablement pas de la vitesse à tout ce processus… et pourrait même être blâmé.
J'ai vu cela se produire sur de 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. S'il n'est pas défini sur Minimal, essayez de définir la valeur minimale et vérifiez si vos versions sont en mesure de se terminer.
J'ai l'impression que l'exécution de Visual Studio en tant qu'administrateur a résolu le problème pour moi! (Pour toujours exécuter un programme en tant qu'administrateur, voir Comment exécuter Visual Studio en tant qu'administrateur par défaut )
J'ai trouvé Visual Studio qui s'acharnait beaucoup sur la construction de grands projets. Il s'avère que c'était ReSharper. Après l'avoir désactivée: Outils -> Options -> ReSharper -> Suspendre Maintenant, tout est construit sans problèmes (même sur de très grandes solutions, plus de 100 projets)
Il a été suggéré sur Microsoft Connect que le projet de modélisation était responsable du gel. J'ai retiré un projet de modélisation de notre solution et n'ai subi aucun gel depuis (environ une semaine).
Dans mon cas, la définition du nombre maximal de constructions de projets parallèles sur 1 aidait un peu (par exemple, la construction d’un projet à partir de l’état propre provoque un gel de 1 minute suivi d’une construction normale et chaque nouvelle construction fonctionnant correctement).
Le paramètre susmentionné peut être défini dans Tool -> Options -> Projects and Solutions -> Build and Run.
Essayez juste en dessous de la commande avec le mode administrateur. Avant d'exécuter cette commande, assurez-vous de fermer toutes les instances de VS.
devenv /resetuserdata
Remarque: devenv se trouve dans C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE.
Pour moi, c’était quelque chose à voir 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 qu'ils soient vérifiés, mais je dois comprendre ce qui les déclenche et ce qui ne va pas avec ce fichier de solution.
Visual Studio 2017
Supprimer Anaconda3 de l’installation a résolu le problème. Dans Procmon, j'ai vu des centaines de milliers d'appels rechercher des fichiers dans le dossier Anaconda3 à partir de centaines d'instances de powershell générées par msbuild.
En plus de la réponse de felickz qui résout (ou presque) ce problème pour les constructions:
Sauf le problème lors d'une construction, j'ai également eu un problème avec la console de gestion de package. Cela a pris environ une minute à attendre. En utilisant Procmon, j'ai découvert 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 supprimé du dossier ci-dessus, le problème de performances s'est dégradé.
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, le problème était une extension qui exécute automatiquement les modèles T4 lors de la construction (AutoT4). La désactivation lorsque vous travaillez avec des solutions avec EF a résolu le problème.
J'ai déplacé ma plate-forme de développement VS 2008 de Windows 7 à Windows 10 et je me suis heurté à une situation dans laquelle Visual Studio raccrochait chaque fois que j'essayais de construire un grand projet. Je devais construire le projet, puis utiliser le gestionnaire de tâches pour tuer VS puis redémarrer. Inutile de dire que cela a rendu le débogage très difficile! Quoi qu'il en soit, le problème était que lors du passage à Win 10, VS ne fonctionnait plus en tant qu'administrateur (et peut-être que Win 10 est plus spécifique en matière de privilèges). La modification des propriétés afin 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 l'avoir signalé!)