asp.net mvc - slow - Débogage/chargement de Visual Studio très lent




visual studio 2017 slow (20)

Je suis à bout de nerfs. Visual Studio est généralement très lent à déboguer ou simplement charger ("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 chargent 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; Plus précisément, c'est Mes documents redirigés vers un lecteur réseau, si cela est important. (Il ne devrait pas, il y a des moments où mon site se charge très rapidement sous 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 il semble tourner autour de DisplayTemplates, ce que font tous mes projets ASP.NET MVC. Et tout est C # et Razor, si cela importait.

Symptômes:

Le système chargera mes symboles des centaines de fois. Fondamentalement, ce qui suit, mais il y a au moins 300 de ces lignes, chacune avec des fichiers DLL un peu 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 DisplayTemplates: "Contact", "Location", et "StatusCode". Il semble que IIS charge deux fois les symboles à chaque fois que le modèle d'affichage est appelé. Ainsi, si j'affiche une table de 100 entrées qui appelle les trois modèles d'affichage, 600 symboles distincts sont chargés.

Ce n'est pas une opération rapide non plus. En regardant dans les fichiers journaux que IIS génère, il faut environ 200 ms pour chaque symbole à charger. Ainsi, des retards super-longs.

Ce que j'ai essayé:

  • Version de débogage ou de version, peu importe.
  • Mettre mon projet sur une implémentation complète de IIS sur un serveur web fonctionne très rapidement 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.
  • Nettoyer la solution ou supprimer le fichier .suo ne fait rien non plus.
  • Si je répare IIS Express, ou supprime le dossier My Docs\IISExpress , ou répare / réinstalle Visual Studio → le problème PEUT disparaître, mais seulement pendant un moment, avant qu'il ne revienne.

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 NOTHING modifié, peut charger très très rapidement parfois, généralement après que je répare IIS Express et supprime le dossier My Docs\IISExpress . Finalement "quelque chose" arrive et il ne reste plus que 2 minutes à charger. 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 pas d'addons quoi-que-jamais.

Il est à noter que cette machine est équipée de Symantec Endpoint Protection, qui a causé des ravages dans le passé. Mais le désactiver purement et simplement (c'est bien 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 traversait ses centaines de lignes de «symboles chargés», j'ai fait une pause pour voir ce qu'il faisait. C'était dans mon code, en chargeant le DisplayTemplate que j'avais. Entrer dans le modèle de 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, le partage réseau puis imprime une nouvelle fois dessus, et Visual Studio pense alors que le fichier a changé et que Visual Studio le recompile encore une fois. Seulement une théorie cependant; Je n'ai vraiment aucune idée.

Pour un, apparemment j'ai des fichiers hors connexion (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 corrige. Il 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 qu'il n'est plus partagé avec personne.

Je peux me contenter de le copier de C vers le partage réseau, s'il y en a. Il est beaucoup plus ennuyeux d'attendre deux minutes pour chaque chargement de page.


Éteindre intelliTrace a résolu cela pour moi.

Dans Visual Studio, Outils -> Options -> IntelliTrace

Ensuite, décochez la case "Activer IntelliTrace".


Après avoir passé toute la journée à attendre que les symboles se chargent aussi lentement que la vitesse des tortues, mélangez et basculez entre toutes les combinaisons possibles: Just My Code, Symboles de mise en cache , 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 a demandés et ralentirait le processus entier de chargement de symbole.

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


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

Debug -> Delete All Breakpoints

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 vide (cliquez sur le nouveau bouton de document et cliquez sur OK).


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 Step Over (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.


Dans mon cas, j'ai remarqué que la désactivation de ma connexion Internet la rendrait aussi rapide qu'avec ctrl-f5, donc je suis passé à debug-> options-> symboles et j'ai simplement décoché 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 désactiver Debug-> Options-> Debugging-> General "Activer le support source" ou "Exiger que les fichiers sources correspondent exactement à la version originale" ne ferait aucune différence.


J'étais également confronté à ce problème, ci-dessous sont les étapes que je réalise et cela fonctionne pour moi toujours:

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

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

Sur "Visual Studio 2012", allez à:

  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


J'ai rencontré le même problème et j'ai essayé la plupart des résolutions ci-dessus. Simplement la suppression du cache et des fichiers temporaires 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 Fichiers iisexpress et Temporary ASP.NET).

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

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


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

(Notez simplement que 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, mais je ne connais pas ma machine. terminer en toute sécurité la tâche tous sauf YMMV.)

En ce qui concerne pourquoi cela arrive? Cela semble se produire lorsque j'ouvre plus d'un projet à la fois, ce que j'ai tendance à faire souvent, même si je ne fais que construire et déboguer l'un d'entre eux à n'importe quel moment.

Edit # 1 - Ce n'est pas une "balle d'argent" 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 j'entre dans le gestionnaire de tâches et j'en termine une 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.

Vraiment je pense que le meilleur plan d'action est probablement de ne pas construire et déboguer le code d'un dossier / partage réseau redirigé.

Édition # 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 . Oui, qui savait. Au moment où je termine cette tâche, bam, la page se charge en une seconde.

Si j'ai un explorateur de fichiers Windows Explorer ouvert sur mon lecteur réseau redirigé (ce qui est souvent le cas où mon code est), 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 qu'il faisait ... devenir fou avec des poignées de fichiers?

Je peux habituellement utiliser le gestionnaire de tâches pour démarrer une nouvelle tâche explorer.exe (je ne peux prendre que beaucoup d'alt-tabulation), et Visual Studio continuera de se charger de manière agréable et rapide. Mais si j'ouvre à nouveau Windows Explorer, cela revient presque toujours à un super slow-mo.

Donc, si vous avez un partage réseau redirigé, essayez-le. Il vaut mieux travailler localement.


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


Pour ma part, j'ai implémenté cette astuce 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"?

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

Qu'est-ce que les OptimizeCompilations font exactement? 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, alors le dossier complet de codegen (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 ces modifications ne suppriment pas le dossier codegen.

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


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

Mise à jour: j'ai éteint tous les add-ons du programme IE et il est de retour à pleine vitesse. Les allumer un à la fois a révélé que LastPass (dans mon cas) était le coupable. Je suppose que je ne vais pas blâmer MS après tout.


Problème similaire gaspillé la moitié de ma journée!

Puisque la solution à mon problème était différente de ce qui est dit ici, je vais l'afficher pour que cela puisse aider quelqu'un d'autre.

Le mien était un point d'arrêt. J'ai eu un point d'arrêt "Break at function" (ie au lieu d'appuyer sur F9 sur une ligne de code, on les crée en utilisant la fenêtre breakpoints) qui est censé s'arrêter dans une fonction de bibliothèque en dehors de mon projet.

Et j'ai eu "Utiliser Intellisense pour vérifier le nom de la fonction " VÉRIFIÉ. (Info here .)

Ce ralentissement vs comme l'enfer (démarrage du projet de 2 secondes à 5 minutes).

Supprimer le point de rupture l'a résolu pour de bon.


Rien de tout cela n'a fonctionné pour moi mais j'ai trouvé un Breakpoint sur un symbole qui a été effacé. Il semble que 2010 était suspendu. Pour voir si c'est votre problème, debug-> windows-> breakpoints S'il y en a, supprimez-les.

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


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 peut seulement être fait pendant le débogage.

Cela avait un impact même après avoir fermé cette fenêtre.


Une fois, après une coupure de courant, j'ai dû faire face au même problème de lenteur chaque fois qu'un point de rupture était touché ou qu'une exception était lancé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 faire ralentir tout.

J'ai supprimé mes fichiers "suo" et tout allait bien. La suppression de fichiers .suo est inoffensive et implique seulement de recréer ma mise en page Windows plus le projet de démarrage et quelques autres personnalisations non critiques.


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

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

  • VÉRIFIEZ la coche à 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 "Symbol caching" 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 depuis les serveurs de Microsoft, ce qui peut prendre un certain temps. Notez que le bouton Charger tous les symboles n'est disponible que pendant le débogage.

  • UNCHECK la coche à côté de "Microsoft Symbol Servers" 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.


Assurez-vous que vous n'avez pas ouvert Visual Studio en mode administrateur

J'ai fait face à ce problème et j'ai dû fonctionner en mode normal.





cassini