web-dev-qa-db-fra.com

Pourquoi le chargement de ma solution dans Visual Studio est-il si long?

Nous avons une très grosse solution avec plus de 200 projets et des milliers de fichiers. Malgré cela, la solution se chargeait assez rapidement dans Visual Studio 2010 et 2012. Cependant, après avoir copié le référentiel SVN complet vers un autre emplacement, le chargement et la fermeture de la solution ont pris un temps extrêmement long. (Je parle de 30 à 60 minutes ici!)

37
gehho

J'ai moi-même trouvé une solution et je voulais la partager ici, en espérant que cela pourrait faire économiser quelques heures de recherche à quelqu'un et en fixant le dialogue "Préparation de la solution ...".

Lors de l'inspection du processus devenv.exe avec Process Monitor, j'ai découvert qu'il était très occupé avec l'accès au répertoire .svn. Voici ce que j'ai fait (et cela a en quelque sorte résolu le problème):

  1. Tuer Visual Studio
  2. Ouvrez Visual Studio sans charger de solution
  3. Désactiver AnkhSvn en tant que plug-in de contrôle de code source (Outils-> Options-> Contrôle de code source-> Sélection de plug-in-> Aucun)
  4. Désactivez "Document Well 2010 Plus" (VS2010) ou "Document personnalisé" (VS2012) dans Productivity Power Tools (Outils-> Options-> Productivity Power Tools) - J'ai lu cela quelque part et cela aurait peut-être aussi aidé. .
  5. Fermer Visual Studio
  6. Supprimez le fichier *.suo de la solution. Cela se trouve dans le même dossier que la solution elle-même. REMARQUE: Vous perdrez plusieurs paramètres pour votre solution, tels que les fichiers actuellement ouverts, les points d'arrêt, les signets, la configuration actuelle de la solution et la plate-forme (par exemple, Debug x86), etc.
  7. Redémarrer Visual Studio
  8. Chargez la solution - c'était beaucoup plus rapide maintenant!
  9. Fermer Visual Studio
  10. Ouvrez Visual Studio sans charger de solution
  11. Réactiver AnkhSvn et le "document bien"
  12. Redémarrer Visual Studio
  13. Ouvrez la solution - elle était encore chargée en quelques secondes!

Je ne sais pas laquelle de ces étapes a réellement résolu le problème. Toutes ces étapes ne sont probablement pas obligatoires, mais je ne voulais pas reproduire le problème pour savoir quelles étapes peuvent être omises. :)

65
gehho

Aucun de ceux qui m'a aidé, ce que j'ai fait ... Je regarde avec ProcMon de sysinternals, filtrant pour devenv, et j'ai vu beaucoup d'entrées de fussionlog. J'avais activé fussionlog quelques semaines auparavant pour le débogage et je n'avais pas pensé à le désactiver. Il me suffisait de désactiver fussionlog et la solution a été ouverte plus rapidement.

5
xisket

Vous pouvez ouvrir Visual Studio en mode sans échec, puis vérifier les paramètres de votre plug-in et de votre contrôle de code source après avoir ouvert le projet.

Comment :

devenv /SafeMode 

Ou selon votre chemin

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode

source: https://msdn.Microsoft.com/en-us/library/ms241278.aspx

3
Tarek El-Mallah

Dans mon cas, les opérations suivantes ont fonctionné sans les étapes intermédiaires suggérées:

  1. Tuez Visual Studio.
  2. Démarrez Visual Studio directement (c'est-à-dire pas à partir du fichier .sln ).
  3. Ensuite, à partir de Visual Studio, ouvrez la solution.

Dans mon cas, c’était tout ce qu’il fallait pour que la solution au problème se charge assez rapidement, sans qu'il soit nécessaire de modifier les paramètres ou de supprimer des fichiers.

1
Reg Edit

fwiw, je me rends compte que c’est une entrée tardive, mais j’ai trouvé que le simple fait de supprimer (supprimer) mon grand nombre de points de rupture a résolu le temps de chargement et le temps de compilation excessifs. Cette action a réduit la taille du fichier .suo de 214 Mo à 977 Ko. Laissez VS gérer le fichier .suo lui-même. La compilation et le chargement prennent maintenant <1 minute au lieu de 5 à 10 minutes pour une solution de 35 projets. Visual Studio 2012 Pro, mise à jour 4.

1
jafo

J'ai essayé ce qui précède, mais cela n'a pas résolu mon problème.

Voici comment j'ai résolu ce problème. J'espère que cela fonctionnera aussi pour certains d'entre vous:

  1. Ouvrez Visual Studio 2013 sans solution. 
  2. Créez une nouvelle application console C # et enregistrez-la. 
  3. Fermez Visual Studio.
  4. Rouvrez la solution de console créée à l'étape 2.
  5. Fermez Visual Studio.
  6. Rouvrez la solution suspendue précédemment à la boîte de dialogue Préparation de la solution. Le mien s'est ouvert tout de suite, plus accroché.
0
Yves Rochon

Aucune des autres réponses n'a fonctionné pour moi. Les temps de compilation de CI étaient bons, mais le chargement de ma solution dans Visual Studio prenait presque deux minutes. VS fonctionnerait alors parfaitement jusqu'à ce que je ferme et ouvre la solution la prochaine fois. Différentes versions de VS ont toutes présenté le même problème et les deux modes sans échec et la suppression du suo n'ont pas aidé.

J'ai fini par suivre les conseils donnés dans http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx pour utiliser Windows Performance Recorder pour instrumenter VS et trouver le problème. En recherchant dans l'Analyseur de performances Windows sous la section "Utilisation du processeur (échantillonnée)" et en ajoutant la colonne "Empiler (Balises d'images)", j'ai pu accéder à l'utilisation de devenv.exe.

Il s'avère que le raccourci chaud par nombre avait Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 appels en baisse, et en dessous de cela Microsoft.VisualStudio.ServerExplorer.dll et Microsoft.VisualStudio.Data.Package.dll. Cela m'a amené à regarder dans l'Explorateur de serveurs dans l'interface utilisateur et à ouvrir l'onglet Connexions de données. Là, j’ai trouvé des centaines de connexions ajoutées par erreur provenant de la section ConnectionString du debug web.config. Le retrait de ceux-ci de web.config a réduit la charge de ce projet individuel de plus de 90 secondes à presque instantanément.

0
Jeremy Murray

En utilisant Visual Studio 2015, j'ai fini par créer une nouvelle solution, en ajoutant les projets existants. 

Supprimer la réponse * .suo de la réponse de gehho m'a aidé par le passé, mais ne m'a pas aidé dans ce cas. Il existe également un autre fichier .suo dans un dossier caché .vs à la racine de la solution.

Il existe d’autres réponses ici pour Visual Studio 2015 Visual Studio 2015 est extrêmement lent

0
goodeye