Débogage/chargement de Visual Studio très lent
Je suis à bout. Visual Studio est généralement péniblement lent à déboguer ou à charger simplement ("démarrer sans déboguer") mes sites ASP.NET MVC. Pas toujours: au début, les projets chargeront Nice et rapidement, mais une fois qu'ils 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 le même problème dans Visual Studio 2010 Express. Ma solution est stockée sur un lecteur réseau. Plus précisément, il s'agit de Mes documents redirigés vers un lecteur réseau, si cela compte. (Cela ne devrait pas. Il y a des moments où mon site se charge très rapidement avec cette configuration.)
Je charge dans Internet Explorer 9 généralement, mais le même problème se produit dans Firefox.
Cela peut se produire dans tous les projets ASP.NET MVC sur lesquels je travaille et cela semble être lié à l'utilisation de DisplayTemplates, 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 centaines fois. Fondamentalement, voici ce qui suit, mais il existe au moins 300 lignes de ce type, chacune contenant des fichiers DLL très légèrement différents pour les mêmes fichiers 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 des symboles deux fois à chaque appel du modèle d'affichage. Ainsi, si j'affiche une table de 100 entrées appelant ces trois modèles d'affichage, c'est 600 symboles distincts chargés.
Ce n'est pas une opération rapide non plus. Dans les fichiers journaux générés par IIS, le chargement de chaque symbole nécessite environ 200 ms. Donc, des délais très longs.
Ce que j'ai essayé:
- Version de débogage ou de sortie, peu importe.
- Mettre mon projet sur une implémentation complète IIS sur un serveur Web l'exécute très rapidement et sans 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.
- Solution propre, ou supprimer le fichier .suo également ne fait rien.
- Si je répare IIS Express ou si je supprime le dossier
My Docs\IISExpress, ou si je répare/réinstalle Visual Studio → le problème PEUT disparaître, mais seulement pendant un certain temps avant de revenir immédiatement.
Tout conseil est apprécié.
Pour répondre à plus de questions, oui, ma machine a définitivement la puissance. Ce qui est exaspérant, c’est que le même projet, avec RIEN qui ait été modifié, puisse se charger très rapidement, généralement après avoir réparé IIS Express et supprimé le dossier My Docs\IISExpress. Finalement, "quelque chose" se produit et il faut 2 minutes pour recharger. Ce sur quoi je travaille n’est pas un projet compliqué. Pas de bibliothèques externes ou dépendances, et mon VS.NET n'a aucun addons quoi-ainsi-que-soit.
Il est à noter que cette machine est équipée de Symantec Endpoint Protection, qui a toujours provoqué des dégâts considérables. Mais le désactiver complètement (il est bon d’être administrateur) n’a pas résolu le problème.
J'ai une théorie à ce stade. Je pense que tout cela est dû au fait 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 me suis arrêté pour voir ce qu'il faisait. C'était dans mon code, en chargeant le DisplayTemplate que j'avais. Entrer dans le modèle en sortie 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 displaytemplate à chaque fois qu'il est appelé, ce qui est encore une fois des centaines de fois. Ma théorie est que Visual Studio compile le fichier, l’enregistre sur le partage réseau, lequel partage ensuite une nouvelle fois, et Visual Studio pense alors que le fichier a changé et le recompile à nouveau. Seulement une théorie cependant; Je n'ai vraiment aucune idée.
D'une part, apparemment, j'ai des fichiers hors connexion sur (c'est un ordinateur de bureau dans un bureau; je m'en fous). Je vais désactiver, redémarrer et réessayer demain.
De plus, déplacer mon projet, tel quel, vers le C local: le répare. Ca charge très vite. Mais ce n’est pas idéal dans un environnement de travail. Je perds les versions précédentes, mon code n'est sauvegardé que 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 du partage C au partage réseau, si cela se produit. Il est bien plus ennuyeux d'attendre deux minutes à chaque chargement de page.
Voici comment j'ai résolu le problème de "chargement de symbole lent" dans Visual Studio 2012:
Allez dans Outils -> Options -> Débogage -> Général
Cochez la case en regard de "Activer uniquement 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 de 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 est uniquement disponible lors du débogage.
Décochez la case en regard de "Serveurs Microsoft Symbol" pour empêcher Visual Studio d'interroger à distance les serveurs Microsoft.
Cliquez sur OK".
A partir de maintenant, 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
Ensuite, décochez 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 supprimé. Il semblerait que 2010 était en suspens. Pour voir si ceci est votre problème faites debug-> windows-> points d'arrêt S'il y en a, supprimez-les.
Saunders a mentionné qu'il avait vérifié cela, mais que cela n'était pas mentionné dans les solutions à ce problème. Peut-être connaissance commune pour certains, mais pas tous.
J'ai supprimé le dossier "Temporary ASP.NET Files" et le chargement de ma page localhost s'est amélioré de façon spectaculaire. Voici le chemin ...% temp%\Temporary ASP.NET Files \
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 journaux sur le disque. Le simple fait de le désactiver sur RegEdit a tout résolu, dans mon cas.
C'est la clé FusionLog sur le registre:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Vérifiez la valeur de ForceLog (1 activé, 0 désactivé).
Je pense enfin pouvoir au moins connaître la cause, mais pas la raison. Lorsque le problème a commencé à se reproduire, j'ai remarqué une tonne de processus "conhost.exe" orphelins. Je fermerais Visual Studio et ils resteraient ouverts. Terminer la tâche de chacun d’eux a finalement résolu le problème de manière fiable. [espérons-le]
(Remarque: conhost.exe n'est pas un processus Visual Studio bien que Visual Studio l'utilise. Ainsi, 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 finissez en toute sécurité, mais YMMV)
Pourquoi cela se produit-il? Cela semble se produire lorsque j'ouvre plusieurs projets à la fois, ce que j'ai tendance à faire souvent, même si je ne construis et débogue que l'un d'entre eux à la fois.
Edit # 1 - Ce n'est pas une "solution miracle" malheureusement. Ça ne marche pas toujours pour moi. En règle générale, lorsque la situation ralentit, je ferme simplement toutes mes sessions Visual Studio, puis je vais dans le gestionnaire de tâches et en termine l’instance, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe et MSBuild.exe Je peux trouver.
Généralement, après cela, lorsque je redémarre mon projet, il se charge rapidement. Mais pas toujours.
En réalité, je pense que la meilleure solution consiste probablement à ne pas créer ni déboguer de code à partir d'un dossier/partage réseau redirigé.
Éditer # 2 - Deux ans plus tard, et ceci reste un problème pour moi dans Visual Studio Community 2013, mais il semble que j'ai au moins trouvé la tâche coupable: Explorer.exe . Oui, qui savait. Au moment où je termine cette tâche, bam, la page se charge en une seconde.
Si un navigateur de fichiers de l'explorateur Windows est ouvert sur mon lecteur réseau redirigé (ce qui est souvent le cas depuis l'endroit où 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 ... de devenir dingue avec des poignées?
Je peux généralement utiliser le gestionnaire de tâches pour démarrer une nouvelle tâche Explorer.exe (je ne peux prendre qu'un nombre suffisant de touches de modification), et Visual Studio continuera à charger Nice et rapidement. Mais si j'ouvre à nouveau l'Explorateur Windows, il revient presque toujours en mode super lent.
Donc, si vous avez un partage réseau redirigé, essayez-le. Cela vaut certainement mieux que de travailler localement.
J'ai rencontré le même problème et essayé la plupart des solutions ci-dessus. Supprimer simplement le cache et les fichiers temporaires finissent 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 dossier C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup avec le contenu suivant:
rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q
rmdir C:\Users\\{username}\AppData\Local\Temp /s /q
Les solutions ci-dessus sont de bonnes solutions et je les ai toutes essayées, mais la solution here , qui consiste à
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 avait plus de débogage lent avec F10 ou F11. Je ne sais pas quel est le problème avec IE mais je déteste officiellement l’utiliser pour les tests maintenant.
Mise à jour: j'ai désactivé tous les add-ons de programme IE et la vitesse est rétablie. Les allumer les uns après les autres a révélé que LastPass (dans mon cas) était le coupable. Je suppose que je n’ai pas à blâmer la SP après tout.
En ce qui me concerne, j’ai mis en œuvre ce conseil qui a 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"?
Cela rend la pré-compilation plus sélective en ne compilant que les pages qui ont changé et nécessitent une nouvelle compilation
Que fait exactement les optimisations de compilations? La source
ASP.NET utilise un code de hachage par application qui inclut l'état d'un nombre d'éléments, y compris les dossiers bin et App_Code, et global.asax. Chaque fois qu'un domaine d'application ASP.NET démarre, il vérifie si cela Le code de hachage a changé par rapport à ce qu'il avait précédemment calculé. Si c'est le cas, alors tout le dossier codegen (où sont compilés et copiés les ombres assemblies en direct) est effacé.
Lorsque cette optimisation est activée (via optimCompilations = "true"), le hachage ne prend plus en compte bin, App_Code et global.asax. En conséquence, si ceux-ci changent, nous ne le ferons pas effacez le dossier codegen.
Référence: Elément de compilation sur msdn
J'ai eu aussi des problèmes de performances d'exécution avec le débogage et j'ai essayé de très nombreuses options de débogueur. Dans mon cas, les performances sont énormes lorsque je change d’options:
Outils - Options - Débogage - Fenêtre de sortie - (Paramètres de sortie généraux - Toutes les sorties de débogage) - DÉSACTIVÉ
Dans mon cas, il s’agissait de .NET Reflector Visual Studio Extension (version 8.3.0.93) et de VS 2012. Le débogage prenait 10 secondes pour chaque Step Over (F10).
Dans Visual Studio, accédez à Outils/Extensions et mises à jour ... et désactivez extension de Visual Studio .NET Reflector. N'oubliez pas de redémarrer Visual Studio.
Dans mon cas c'était
Tools/Options/Debugging/General/Enable JavaScript debugging for ASP.NET (Chrome and IE)
Une fois cette case décochée, 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 touché ou qu'une exception était lancée.
J'avais le vague souvenir que le fichier "suo" (dans le même répertoire que le fichier solution "sln") pouvait être corrompu et ralentir le tout.
J'ai supprimé mes fichiers "suo" et tout allait bien. La suppression des fichiers .suo est sans danger et implique uniquement de recréer la mise en page de Windows, ainsi que le projet de départ et quelques autres personnalisations non critiques.
Je faisais également face à ce problème, voici les étapes que j'effectue et cela fonctionne toujours pour moi:
- Suppression du fichier .suo de la solution.
- Suppression des fichiers ASP.NET temporaires .__ (vous pouvez les trouver à l'adresse suivante à l'adresse % 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 associant le débogueur au processus lui-même plutôt que de laisser VS le faire pour moi et je l’ai trouvé très utile. 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 de VS lent a été résolu en désactivant le lien de navigateur
Après avoir passé toute la journée à attendre que les symboles se chargent aussi lentement que la vitesse de la tortue, mélangez et basculez entre toutes les combinaisons possibles: Just My Code, Symboles de mise en cache , Intellitrace , Just-In-Time, kill processus , etc.
Ma solution consistait en fait à désactiver l'antivirus. Oui, Windows Defender a ralenti le lancement de mon projet! Il vérifierait toutes les dll que Visual Studio les demandait et ralentissait le processus de chargement des symboles.
Je dois dire que nos machines ont d'excellentes spécifications pour compiler la solution très rapidement, ce qui n'a donc jamais posé de problème. Nous codons dans VS 2013 Ultimate.
Si quelqu'un remarque que ce comportement sort du champ de gauche, vérifiez que vous n'avez aucun point d'arrêt défini dans web.config. Je dois avoir défini un avec un clic de souris errant, et cela a vraiment ralenti toutes les opérations de débogage.
Vider le cache des symboles a fonctionné pour moi.
Voir: barre de menus/Outils/Options/Débogage/Symboles/Cache de symboles vide
Assurez-vous de ne pas ouvrir Visual Studio en mode administrateur
J'ai fait face à ce problème et j'ai dû fonctionner en mode normal.
Accédez à vos variables d'environnement et recherchez la clé _NT_SYMBOL_PATH.
Supprime-le.
Voila, a travaillé comme un charme.
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 Regrouper par sur Aucune. Cela ne peut être fait que pendant le débogage.
Cela avait un impact même après la fermeture de cette fenêtre.
Un problème similaire gaspille mieux la moitié de ma journée!
Puisque la solution à mon problème était différente de ce qui est dit ici, je vais la poster afin que cela puisse aider quelqu'un d'autre.
Le mien était un point d'arrêt. J'avais un "Break at function" point d'arrêt (c'est-à-dire qu'au lieu d'appuyer sur F9 sur une ligne de code, nous les créons à l'aide de 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 "Utilise Intellisense pour vérifier le nom de la fonction" VÉRIFIÉ. (Info ici .)
Cela a ralenti vs comme un diable (démarrage du projet de 2 secondes à 5 minutes).
Supprimer le point de rupture a résolu le problème pour de bon.
Pour moi, c'était des points d'arrêt conditionnels. Ceux-ci semblent vraiment ralentir les choses.
Le problème pour moi était la fonctionnalité "Lien de navigateur" 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 par lien de navigateur.
Fermez tous les onglets associés au projet et gardez-en un seul!
Ce studio gratuit instantanément visuel! C'est magique ! ;-)
«Le lien de navigateur 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 Lien de navigateur pour actualiser votre application Web dans plusieurs navigateurs à la fois, ce qui est utile pour les tests entre navigateurs. "
Une solution simple et rapide pour ceux qui n’écartent pas beaucoup des paramètres par défaut du système virtuel.
Outils -> Paramètres d'importation et d'exportation -> Oui, enregistrer mes paramètres actuels -> Visual C #
Je suis sûr que la solution ci-dessus fonctionnerait aussi avec d'autres paramètres par défaut. Dans mon cas, quelque chose de foiré avec les paramètres de chargement des symboles, mais je ne pouvais pas le réparer, même si j’ai essayé plusieurs des solutions suggérées.
Dans mon cas, j'ai remarqué que la désactivation de ma connexion Internet la ferait fonctionner aussi rapidement qu'avec ctrl-f5, alors je suis allé à debug-> options-> symboles et décoché juste tous les emplacements .pdb.
On dirait que VS essayait de se connecter à ces serveurs chaque fois qu'une session de débogage était lancée.
Notez que la désactivation de Debug-> Options-> Debugging-> Général "Activer le support de source" ou "Exiger que les fichiers source correspondent exactement à la version d'origine" ne serait pas peut faire la différence.
Votre "Mes documents" dossier mappé sur un partage réseau?
Le démarrage de IIS Express peut prendre minutes au lieu de secondes si tel est le cas, même si votre solution est locale plutôt que sur le partage réseau. Dans regedit.exe, vérifiez que HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User ShellFolders\Personal pointe vers %USERPROFILE%\My Documents.
Si ce n'est pas le cas, modifiez-le ou demandez à votre administrateur réseau de créer une exception à votre politique.
Ouvrez le dossier de solution dans Windows Explorer, fermez Visual Studio, supprimez le fichier .suo de Windows Explorer.
Ouvrez maintenant le projet dans Visual Studio, espérons que le débogueur sera attaché/détaché rapidement.
J'avais accidentellement sélectionné l'option "Show Threads in Source". En désélectionnant, parcourir le code était normal.
Dans Visual Studio:
Outils -> Options -> Débogage -> Symboles
Choisissez "Uniquement 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 cliquez sur OK).
Il existe également des complications dans les vues partielles où il existe une erreur sur la page qui n'est pas reconnue immédiatement. Comme Model.SomeValue au lieu de Model.ThisValue. Cela risquerait de ne pas être souligné et de poser des problèmes de débogage. Cela peut être une vraie douleur à attraper.
Le débogage du noyau Asp.net était péniblement lent à cause de l'extension VS inconnue qui avait remplacé le débogueur Just in Time par défaut.
J'ai trouvé ce message dans l'onglet de configuration OPTIONS\DEBUGGING\Just-In-Time (en tant que texte d'avertissement) .Un autre débogueur s'est enregistré comme étant le débogueur Just-In-Time. Pour réparer, activez le débogage Just-In-Time ou exécutez la réparation de Visual Studio.
Description: https://msdn.Microsoft.com/en-us/library/ssc8234s.aspx?f=255&MSPPError=-2147217396
Le renvoi du débogueur JIT par défaut (juste cochée l'option gérée qui était décochée) résoudrait tous mes problèmes.
J'ai finalement résolu (ou au moins amélioré beaucoup) ce problème en modifiant la configuration locale IIS:
- Ouvrir la configuration IIS
- Cliquez dans les pools d'applications
- Faites un clic droit dans chaque pool et ouvrez la configuration avancée
- Assurez-vous que "Activer les applications 32 bits" est défini surTRUE Et Mode de démarrage est défini sur AlwaysRunning
J'espère que cela aide quelqu'un, parce que je commençais à devenir fou en essayant de résoudre le problème de débogage lent
Chaque fois que je recompilais sur l'hôte local pendant que je développais, cela prenait plusieurs minutes. C'était terriblement frustrant. Après avoir essayé plusieurs corrections, y compris tout mettre sur un SSD. J'ai trouvé ce qui a vraiment fonctionné. J'ai créé un disque mémoire et y ai mis tout le projet. Les recompilations sur l'hôte local durent maintenant moins de dix secondes. Peut-être pas élégant mais ça a vraiment fonctionné.
Cela pourrait aider quelqu'un, J'ai eu le même problème et j'ai découvert que j'avais une carte SD avec le lecteur e:\ Après avoir retiré ma carte SD, le problème a été résolu.
Accédez à IIS Express, effacez le cache et les sites.
cd "C:\Program Files (x86)\IIS Express\"
- lancer ce
appcmd.exe list site /xml | appcmd delete site /in - lancez ce
Del /S /F /Q %temp%- pour effacer le dossier Userprofile Temp. - lancez ce
Del /S /F /Q %Windir%\Temp- ceci efface le dossier temporaire Windows.
En outre, effacez vos fichiers temporaires dans %temp% et déconnectez-vous, ou redémarrez.
Cela supprimera tous les sites, profitez-en!
Dans mon cas,
J'ai réalisé que le débogage à distance s'exécute et consomme la plupart des ressources. Je n'avais pas vraiment besoin de rendre l'application 64 bits, donc après l'avoir forcée à utiliser 32 bits, le débogage distant ne s'est pas exécuté et l'exécution était plus rapide.
J'ai configuré mon Visual Studio dans un nouveau travail avec C # comme langue par défaut. Je ne m'étais pas encore rendu compte que j'étais condamné à programmer en VB.
J'ai oublié la valeur par défaut de C # car VB semblait bien fonctionner. Cependant, parcourir le code prenait une quantité de temps ridicule. Après avoir essayé plusieurs correctifs, j'ai désespérément changé le langage par défaut en VB ... bingo!
Si vous en êtes aussi loin, ça vaut le coup d'essayer.
Pour moi, c’était que je déboguaisais en mode de compatibilité gérée. Dans Outils -> Options -> Débogage -> Général en bas, décochez la case "Utiliser le mode de compatibilité géré". Le débogage est devenu instantané et nécessitait une minute pour parcourir une ligne. Je soupçonne que c'est ce que "géré" signifie dans les extraits de l'OP ci-dessus.
Plus de détails ici: https://blogs.msdn.Microsoft.com/visualstudioalm/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/
Ma solution consistait simplement à recharger une copie sauvegardée GOOD (copie de sauvegarde) de mes paramètres (effectuée il y a un an). La peine d'essayer avant de tout réinitialiser à blanc. Mon VS2010 prend 60 secondes pour commencer le débogage et env. 3 minutes pour arrêter le débogage. J'ai enregistré les paramètres corrompus et, à ma grande surprise, ils dépassaient 3 Mo au lieu de 260 Ko. J'ai chargé la bonne copie de sauvegarde et tout est à nouveau génial :-)
Dans mon cas, le problème était un fichier exe externe en cours d'exécution, à savoir:
WUDFCompanionHost.exe
sous le nom de
"Windows Driver Foundation - User-mode Driver Companion Framework Host Process".
Processus, qui a pris 10% du processeur. Le tuer a aidé directement et en une seconde la page a été chargée.
Une autre cause possible est la pré-compilation d'anciens projets existant dans le système de fichiers mais supprimés ou partiellement supprimés de Visual Studio.
J'avais une solution qui prenait 3,5 minutes à charger après une compilation, j’ai jeté un coup d’œil aux horodatages des fichiers temporaires ASP.NET et j’ai constaté que le délai de 3 minutes était dans un fichier d’un projet ancien. J'ai jeté un œil à VS et le projet était "indisponible". Supprimé de VS, supprimé du système de fichiers, et maintenant il ne reste plus que 8 secondes.
J'avais ce problème avec VS 2013. Cela faisait des mois que mes tests étaient corrects, mais tout à coup les messages redoutables Chargement des symboles apparaissaient et je ne savais rien de ce que j'avais fait pour le provoquer.
Rien de suggéré ici ni sur aucune autre page Internet ne m'a aidé. J'ai tout essayé au moins 10 fois. Supprimer le fichier .suo n'a pas aidé, mais au même endroit se trouvaient deux fichiers avec.testsettingsextension et un avec.vsmdiextension. Ces fichiers semblaient être obsolètes, peut-être une relique de VS 2010. Le membre de l'équipe qui les avait créés était parti depuis longtemps.
J'ai trouvé que je pouvais supprimer ces trois fichiers sans problème. J'ai compris qu'il suffisait de supprimer un fichier particulier des fichiers.testsettingspour arrêter les messages Loading symboles. Mon cauchemar est terminé.
Pour moi, le problème était Avast Antivirus. Je l'ai désinstallé et exécuté avec Windows Defender à la place et tout fonctionne correctement. Dans ma solution, je rencontrais ce problème uniquement lors de l'exécution d'applications Windows, WinForms ou WPF. Les applications Web n’ont jamais été lentes pour une raison quelconque.
Supprimez tout ce qui se trouve dans c:\Utilisateurs\nom_utilisateur\AppData\Local\Temp \, puis réessayez.
Mon problème était dû au projet en cours de construction chaque fois que j'ai commencé le débogage. Toutes les autres solutions de ce fil ont légèrement aidé, mais m'ont néanmoins obligé à attendre la fin du projet.
Ma solution pour éviter la construction à chaque démarrage du débogage:
- Allez à
Solution Explorer-> Clic droitYour Solution File-> CliquezProperties Dans le
Property Pages-> à gauche, choisissezConfiguration-> et décochezBuildCliquez sur
OKAssurez-vous que Visual Studio est ouvert en tant que Administrator
- Allez à
Debug->Attach to Process - CLIQUEZ sur la case à cocher
Show processes from all users-> Processus de recherche et de sélection appeléw3wp.exe-> Cliquez surAttach-> lorsque l'avertissement s'affiche, cliquez surAttach
Vous pouvez maintenant naviguer vers la page que vous souhaitez déboguer dans localhost et si des points de rupture sont définis dans votre fichier, vous pouvez immédiatement commencer le débogage sans attendre la construction de votre projet !!