Débogage / chargement de Visual Studio très lent

Je suis à bout de souffle. Visual Studio est généralement très lent à déboguer ou à charger simplement ("démarrer sans déboguer") mes sites ASP.NET MVC. Pas toujours: au début, les projets se chargeront bien et rapidement, mais une fois qu'ils se chargeront lentement, ils se chargeront toujours lentement après cela. Je pourrais attendre 1-2 minutes ou plus.

Ma configuration:

J'utilise Visual Studio 2012 Express , actuellement, mais j'ai également rencontré le même problème dans Visual Studio 2010 Express. Ma solution est stockée sur un lecteur réseau; en particulier, il s'agit de Mes documents redirigés vers un lecteur réseau, si cela est important. (Cela ne devrait pas. Parfois, mon site se charge très rapidement avec cette configuration.)

Je charge généralement dans Internet Explorer 9, mais le même problème se produit dans Firefox.

Cela peut se produire dans n'importe quel projet ASP.NET MVC sur lequel je travaille, et cela semble tourner autour de l'affichage de modèles, ce que font tous mes projets ASP.NET MVC. Et c'est tout C # et Razor, si cela importait.

Symptômes:

Le système chargera mes symboles des centaines de fois. Fondamentalement, ce qui suit, mais il existe au moins 300 lignes de ce type, chacune avec des fichiers DLL toujours très différents pour les mêmes CSHTML:

'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.xighmhow.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.cv5hktkf.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.1o77hs8i.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.jja-77mw.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.l_e9ev_s.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.b4n59gom.dll', Symbols loaded.

Dans ce qui précède, j'ai trois modèles d'affichage: "Contact", "Emplacement" et "StatusCode". Il semble que IIS charge deux fois les symboles pour chaque appel du modèle d'affichage. Ainsi, si j'affiche un tableau de 100 entrées qui appelle ces trois modèles d'affichage, c'est 600 symboles distincts chargés.

Ce n'est pas non plus une opération rapide. Dans les fichiers journaux générés par IIS, il faut environ 200 ms pour charger chaque symbole. Ainsi, des retards super longs.

Ce que j'ai essayé:

• Version de débogage ou de version, cela n'a pas d'importance.
• Mettre mon projet sur une implémentation complète d'IIS sur un serveur Web l'exécute très rapidement sans aucun problème.
• Cassini, IIS Express 7.5 et IIS Express 8.0 ont tous le problème.
• Supprimer tous les points d'arrêt ne fait rien.
• Nettoyer la solution ou supprimer le .suo ne fait rien non plus.
• Si je répare IIS Express, ou supprime le My Docs\IISExpressdossier, ou répare / réinstalle Visual Studio → le problème PEUT disparaître, mais seulement pendant un certain temps, avant qu'il ne revienne immédiatement.

Tout conseil est apprécié.

Pour répondre à plus de questions, oui ma machine a définitivement la puissance. La chose exaspérante est que le même projet, avec RIEN modifié, peut parfois se charger très très rapidement, généralement après avoir réparé IIS Express et supprimé le My Docs\IISExpressdossier. Finalement, "quelque chose" se produit et il ne reste plus que 2 minutes pour charger à nouveau. Ce sur quoi je travaille n'est pas un projet compliqué. Pas de bibliothèques externes ou de dépendances, et mon VS.NET n'a aucun add-on.

Il convient de noter que cette machine dispose de Symantec Endpoint Protection, qui a toujours causé des ravages. Mais sa désactivation pure et simple (il est bon d'être administrateur) n'a pas résolu le problème.

J'ai une théorie à ce stade. Je pense que c'est tout parce que je travaille sur un dossier redirigé sur un partage réseau. Pendant que le débogueur parcourait ses centaines de lignes de "symboles chargés", je m'arrêtai pour voir ce qu'il faisait. C'était dans mon code, chargeant le DisplayTemplate que j'avais. Entrer dans le modèle affiche ceci:

Step into: Stepping over non-user code 'System.Threading.WaitHandle.InternalWaitOne'
Step into: Stepping over non-user code 'System.Threading.WaitHandle.WaitOne'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCapture'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromFileBatch'
Step into: Stepping over non-user code 'System.Web.Compilation.AssemblyBuilder.Compile'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.bciuyg14.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.CompileWebFile'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultInternal'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerWrapper.System.Web.Mvc.IBuildManager.FileExists'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.GetPathFromGeneralName'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.Find'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.Html.TemplateHelpers.ActionCacheViewItem.Execute'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.kwj3uqan.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.RuntimeType.CreateInstanceSlow'
Step into: Stepping over non-user code 'System.Web.Mvc.DependencyResolver.DefaultDependencyResolver.GetService'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerViewEngine.DefaultViewPageActivator.Create'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerCompiledView.Render'

Il semble que Visual Studio recompile mon modèle d'affichage à chaque fois qu'il est appelé, ce qui est à nouveau des centaines de fois. Ma théorie est que Visual Studio compile le fichier, l'enregistre sur le partage réseau, le partage réseau marque alors une nouvelle heure dessus, et Visual Studio pense alors que le fichier a changé et donc Visual Studio le recompile à nouveau. Mais seulement une théorie; Je n'ai vraiment aucune idée.

D'une part, j'ai apparemment des fichiers hors ligne (c'est un ordinateur de bureau dans un bureau; je m'en fiche). Je vais désactiver, redémarrer et réessayer demain.

De plus, le déplacement de mon projet, tel quel, vers le C local: le corrige. Il se charge très rapidement. Mais ce n'est pas idéal dans un environnement de travail. Je perds les versions précédentes, mon code n'est pas sauvegardé du tout, sauf si je le copie manuellement, et il n'est plus partagé avec personne.

Je peux me contenter de le copier d'avant en arrière de C vers le partage réseau, si cela se produit. Il est beaucoup plus ennuyeux d'attendre deux minutes pour chaque chargement de page.

Voici comment j'ai résolu le problème de «chargement lent des symboles» dans Visual Studio 2012:

• Allez dans Outils -> Options -> Débogage -> Général

• Cochez la case à côté de "Activer juste mon code".

• Allez dans Outils -> Options -> Débogage -> Symboles

• Cliquez sur le bouton "..." et créez / sélectionnez un nouveau dossier quelque part sur votre ordinateur local pour stocker les symboles mis en cache. J'ai nommé le mien "Mise en cache des symboles" et l'ai mis dans Documents -> Visual Studio 2012.

• Cliquez sur "Charger tous les symboles" et attendez que les symboles soient téléchargés à partir des serveurs de Microsoft, ce qui peut prendre un certain temps. Notez que le bouton Charger tous les symboles n'est disponible que lors du débogage.

• DÉCOCHEZ la coche à côté de "Microsoft Symbol Servers" pour empêcher Visual Studio d'interroger à distance les serveurs Microsoft.

• Cliquez sur OK".

Désormais, le chargement des symboles devrait être beaucoup plus rapide.

Notez que si vous apportez des modifications / téléchargements aux assemblys Microsoft, vous devrez peut-être revenir dans la boîte de dialogue Symboles et "Charger tous les symboles" à nouveau.

Désactiver intelliTrace a résolu ce problème pour moi.

Dans Visual Studio, Outils -> Options -> IntelliTrace

Décochez ensuite la case "Activer IntelliTrace".

Rien de tout cela n'a fonctionné pour moi mais j'ai trouvé un point d'arrêt sur un symbole qui a été supprimé. Il semble que 2010 était suspendu. Pour voir si c'est votre problème, déboguez-> windows-> points d'arrêt.

Saunders, a mentionné qu'il avait vérifié cela, mais cela n'était pas mentionné dans les solutions à ce problème. Peut-être une connaissance commune pour certains, mais pas pour nous tous.

J'ai supprimé le dossier "Fichiers ASP.NET temporaires" et la charge de ma page localhost s'est considérablement améliorée. Voici le chemin ...% temp% \ Fichiers ASP.NET temporaires \

Avez-vous activé FusionLog?

Mon VisualStudio a été très lent à démarrer, à ouvrir la solution et à charger les symboles lors du démarrage du débogage. C'était lent seulement sur ma machine, mais pas sur d'autres machines.

FusionLog écrit des tonnes de fichiers journaux sur le disque. Le désactiver simplement sur RegEdit a tout résolu, dans mon cas.

Il s'agit de la clé FusionLog sur le registre:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Vérifiez la valeur ForceLog (1 activé, 0 désactivé).

J'ai rencontré le même problème et essayé la plupart des résolutions ci-dessus. La simple suppression des fichiers cache et temp finit par fonctionner pour moi.

Essayez de supprimer le contenu de ces deux dossiers:

C:\Users\\{UserName}\AppData\Local\Microsoft\WebsiteCache

et

C:\Users\\{UserName}\AppData\Local\Temp (en particulier les dossiers iisexpress et Temporary ASP.NET Files).

Cela peut être configuré pour se produire automatiquement lors de la connexion à Windows en ajoutant un fichier cmd au C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startupdossier avec le contenu suivant:

rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q

rmdir C:\Users\\{username}\AppData\Local\Temp /s /q

Je pense que je peux enfin au moins connaître la cause, mais pas la raison. Lorsque le problème a recommencé à se produire, j'ai remarqué une tonne de processus "conhost.exe" devenus orphelins. Je fermerais Visual Studio et ils resteraient ouverts. La fin de la tâche sur chacun d'eux a finalement résolu le problème de manière fiable. [j'espère]

(Notez simplement que conhost.exe n'est pas un processus Visual Studio bien que Visual Studio l'utilise. Par conséquent, d'autres utilisateurs peuvent avoir d'autres applications qui exécutent conhost.exe. Je sais que ma machine ne fonctionne pas, c'est pourquoi je peux terminer la tâche en toute sécurité, sauf YMMV.)

Quant à savoir pourquoi cela se produit? Cela semble se produire lorsque j'ouvre plusieurs projets à la fois, ce que j'ai tendance à faire souvent, même si je n'en crée et ne débogue que l'un à tout moment.

Edit # 1 - Ce n'est pas une "solution miracle" malheureusement. Ça ne marche pas toujours pour moi. En règle générale, lorsque les choses deviennent lentes, je ferme simplement toutes mes sessions Visual Studio, puis je vais dans le gestionnaire de tâches et j'arrête toute instance de celui-ci, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe et MSBuild.exe Je peux trouver.

En règle générale, après cela, lorsque je redémarre mon projet, il se charge rapidement. Mais pas toujours.

Vraiment, je pense que la meilleure solution consiste probablement à ne pas créer et déboguer du code à partir d'un dossier / partage réseau redirigé.

Edit # 2 - Deux ans plus tard, et c'est toujours un problème pour moi dans Visual Studio Community 2013, mais j'ai semblé au moins trouver la tâche coupable: Explorer.exe . Ouais, qui savait. Au moment où je termine cette tâche, bam, le chargement des pages en une seconde.

Si j'ai un navigateur de fichiers de l'Explorateur Windows ouvert sur mon lecteur réseau redirigé (qui est souvent car c'est là que se trouve mon code), ce problème semble se produire. Fermer la fenêtre ne suffit pas, je dois tuer toute la tâche Explorer.exe. Je ne pouvais que deviner ce que ça faisait ... devenir fou avec des poignées de fichier?

Je peux généralement utiliser le gestionnaire de tâches pour démarrer une nouvelle tâche explorer.exe (je ne peux prendre que beaucoup de tabulations alt), et Visual Studio continuera à charger correctement et rapidement. Mais si j'ouvre à nouveau l'Explorateur Windows, il revient presque toujours à super-slow-mo.

Donc, si vous avez un partage réseau redirigé, essayez-le. C'est bien mieux que de travailler localement.

Ce qui précède sont toutes de bonnes solutions et j'ai essayé toutes, mais j'ai obtenu la solution ici , qui est de

Debug -> Delete All Breakpoints

Pour moi, c'était IE 9.08.8112.16241. Dès que j'ai utilisé Firefox ou Chrome, il n'y a pas eu de débogage lent avec F10 ou F11. Je ne sais pas quel est le problème avec IE mais je méprise officiellement son utilisation pour les tests maintenant.

Mise à jour: j'ai désactivé tous les modules complémentaires du programme IE et il est de retour à pleine vitesse. Les allumer un par un a révélé que LastPass (dans mon cas) était le coupable. Je suppose que je ne blâme pas la SEP après tout.

Pour moi, j'ai implémenté cette astuce qui a fondamentalement considérablement amélioré les performances en ajoutant les deux attributs suivants à la balise de compilation dans web.config

<compilation ... batch="false" optimizeCompilations="true"> ... </compilation>

Que fait batch = "false"?

Il rend la pré-compilation plus sélective en ne compilant que les pages qui ont changé et nécessitent une recompilation

Que font exactement les optimisationCompilations? La source

ASP.NET utilise un code de hachage par application qui inclut l'état d'un certain nombre de choses, y compris le dossier bin et App_Code et global.asax. Chaque fois qu'un domaine d'application ASP.NET démarre, il vérifie si ce code de hachage a changé par rapport à ce qu'il avait précédemment calculé. Si c'est le cas, le dossier codegen entier (où vivent les assemblys compilés et copiés en ombre) est effacé.

Lorsque cette optimisation est activée (via OptimizeCompilations = "true"), le hachage ne prend plus en compte bin, App_Code et global.asax. Par conséquent, si ceux-ci changent, nous n'effacerons pas le dossier codegen.

Référence: élément de compilation sur msdn

J'ai également eu des problèmes de performances d'exécution avec le débogage et j'ai essayé de nombreuses options de débogueur. Dans mon cas, d'énormes performances ont été obtenues lorsque je modifie ces options:

Outils - Options - Débogage - Fenêtre de sortie - (Paramètres de sortie généraux - Toutes les sorties de débogage) - OFF

Dans mon cas, c'était l'extension .NET Reflector Visual Studio (version 8.3.0.93) avec VS 2012. Le débogage prenait 10 secondes pour chaque étape (F10).

Dans Visual Studio, accédez à Outils / Extensions et mises à jour ... et désactivez l' extension .NET Reflector Visual Studio . N'oubliez pas de redémarrer Visual Studio.

J'ai eu des problèmes avec le débogage lent de Visual Studio lorsque le débogueur "Native Code" était activé. Essayez de le désactiver.

Sur "Visual Studio 2012", allez sur:

1. Propriétés du projet ->
2. Web ->
3. Débogueurs (bas de page). ->
4. Désactiver tout sauf ASP.NET

J'espère que cela aide.

Questions similaires: 1 , 2

Dans mon cas, c'était

Tools/Options/Debugging/General/Enable JavaScript debugging for ASP.NET (Chrome and IE)

Une fois que j'ai décoché cela, mon début de débogage est passé de 45-60 secondes à 0-5 secondes.

Une fois, après une panne de courant, j'ai dû faire face au même problème de lenteur chaque fois qu'un point d'arrêt était atteint ou qu'une exception était levée.

J'ai eu le vague souvenir que le fichier "suo" (dans le même répertoire que le fichier de solution "sln") peut être corrompu et ralentir tout.

J'ai supprimé mes fichiers "suo" et tout allait bien. La suppression des fichiers .suo est inoffensive et implique uniquement de recréer la disposition de mes fenêtres ainsi que le projet de démarrage et quelques autres personnalisations non critiques.

J'étais également confronté à ce problème, voici les étapes que j'effectue et cela fonctionne pour moi toujours:

• Suppression du fichier .suo de la solution.
• Suppression des fichiers ASP.NET temporaires (vous pouvez les trouver à le trouver dans % WINDOW% \ Microsoft.NET \ Framework \\ Fichiers ASP.NET temporaires )
• Suppression de tous les points d'arrêt dans l'application.

Je ne sais pas si vous rencontrez toujours ce problème, mais je débogue des sites dans Visual Studio en attachant le débogueur au processus lui-même plutôt que de laisser VS le faire pour moi et je l'ai trouvé pour améliorer considérablement les temps. J'utilise une extension pour VS appelée AttachTo et j'ai un petit article sur la façon dont je l'utilise ici .

J'espère que ça aide.

Mon problème VS lent a été résolu en désactivant le lien du navigateur

Si quelqu'un remarque que ce comportement sort du champ de gauche, assurez-vous qu'aucun point d'arrêt n'est défini dans web.config. J'ai dû en définir un avec un clic de souris errant, et cela a vraiment ralenti toutes les opérations de débogage.

Après avoir passé toute la journée à attendre que les symboles se chargent aussi lentement que la vitesse de la tortue, à mélanger et à basculer entre toutes les combinaisons possibles: Just My Code, Caching symboles , Intellitrace , Just-In-Time, processus de mise à mort , etc.

Ma solution était en fait de désactiver l'antivirus . Ouais, Windows Defender ralentissait le lancement de mon projet! Il vérifierait toutes les dlls comme Visual Studio les avait demandées et ralentissait tout le processus de chargement des symboles.

Je dois dire que nos machines ont d'excellentes spécifications pour compiler la solution très rapidement, donc cela n'a jamais été un problème. Nous codons dans VS 2013 Ultimate.

Vider le cache de symboles a fonctionné pour moi.

Voir: barre de menus / Outils / Options / Débogage / Symboles / Vider le cache de symboles

Un problème similaire a perdu mieux la moitié de ma journée!

Étant donné que la solution à mon problème était différente de ce qui est dit ici, je vais le poster afin qu'il puisse aider quelqu'un d'autre.

Le mien était un point d'arrêt. J'avais un point d'arrêt "Break at function" (c'est-à-dire qu'au lieu d'appuyer sur F9 sur une ligne de code, nous les créons en utilisant la fenêtre des points d'arrêt) qui est censé s'arrêter dans une fonction de bibliothèque en dehors de mon projet.

Et j'avais "Utiliser Intellisense pour vérifier le nom de la fonction " VÉRIFIÉ. (Infos ici .)

Cela a ralenti vs comme l'enfer (démarrage du projet de 2 secondes à 5 minutes).

La suppression du point de rupture l'a résolu pour de bon.

Une chose qui a fonctionné pour moi après avoir fait tout ce qui précède était:
Dans la fenêtre Threads (Debug-> Windows-> Threads), définissez Group by sur None. Cela ne peut être fait que lors du débogage.

Cela avait un impact même après la fermeture de cette fenêtre.

Dans Visual Studio:

Outils -> Options -> Débogage -> Symboles

Choisissez "Seuls les modules spécifiés". Cliquez sur le lien "spécifier les modules" et ajoutez un module vierge (cliquez sur le bouton du nouveau document et appuyez sur OK).

Ouvrez le dossier de la solution dans l'explorateur Windows, fermez Visual Studio, supprimez le fichier .suo de l'explorateur Windows.

Maintenant, ouvrez le projet dans Visual Studio, espérons que le débogueur sera attaché / détaché rapidement.

Pour moi, c'était des points d'arrêt conditionnels. Cela semble vraiment ralentir les choses.

Accédez à vos variables d'environnement et recherchez la clé _NT_SYMBOL_PATH.

Supprime-le.

Voila, a fonctionné comme un charme.

Le problème pour moi était la fonctionnalité "Browser Link" qui est très lourde lorsque plusieurs onglets sont ouverts pour le même projet!

Parce que chaque fois que nous lançons le projet, il ouvre un nouvel onglet avec les communications des liens du navigateur.

Fermez simplement tous les onglets associés au projet et n'en gardez qu'un seul ouvert!

Ce studio visuel instantanément gratuit! C'est magique ! ;-)

«Browser Link est une fonctionnalité depuis Visual Studio 2013 qui crée un canal de communication entre l'environnement de développement et un ou plusieurs navigateurs Web. Vous pouvez utiliser Browser Link pour actualiser votre application Web dans plusieurs navigateurs à la fois, ce qui est utile pour les tests entre navigateurs. »

Une solution rapide et facile pour ceux qui ne s'écartent pas beaucoup des paramètres VS par défaut.

Outils -> Paramètres d'importation et d'exportation -> Oui, enregistrez mes paramètres actuels -> Visual C #

Je suis sûr que la solution ci-dessus fonctionnerait également avec d'autres paramètres par défaut. Dans mon cas, quelque chose a gâché mes paramètres de chargement des symboles, mais je n'ai pas pu le corriger même si j'ai essayé pas mal de solutions suggérées.

Veuillez vous assurer que vous n'avez pas ouvert Visual Studio en mode administrateur

J'ai rencontré ce problème et j'ai dû exécuter en mode normal.