Debug / caricamento di Visual Studio molto lento

Sono alla fine. Visual Studio è in genere dolorosamente lento nel debug o semplicemente carica ("avvia senza debug") i miei siti MVC ASP.NET. Non sempre: all'inizio i progetti si caricheranno bene e velocemente, ma una volta caricati lentamente, dopo caricheranno sempre lentamente. Potrei aspettare 1-2 minuti o più.

La mia configurazione:

Attualmente sto usando Visual Studio 2012 Express , ma ho avuto lo stesso problema anche in Visual Studio 2010 Express. La mia soluzione è memorizzata su un'unità di rete; in particolare, è My Documents reindirizzato su un'unità di rete, se è importante. (Non dovrebbe. Ci sono volte in cui il mio sito si carica molto velocemente con questa configurazione.)

Carico in Internet Explorer 9 di solito, ma lo stesso problema si verifica in Firefox.

Questo può accadere in qualsiasi progetto ASP.NET MVC su cui lavoro, e sembra ruotare attorno a DisplayTemplates, come fanno tutti i miei progetti ASP.NET MVC. Ed è tutto C # e Razor, se questo è importante.

Sintomi:

Il sistema caricherà i miei simboli centinaia di volte. Fondamentalmente, il seguente, ma ci sono almeno 300 di queste righe, ognuna con file DLL sempre leggermente diversi per gli stessi 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.

In quanto sopra, ho tre DisplayTemplates: "Contact", "Location" e "StatusCode". Sembra che IIS stia caricando due volte simboli per ogni volta che viene chiamato il displaytemplate. Pertanto, se sto visualizzando una tabella di 100 voci che chiama tutte e tre queste piastre di visualizzazione, sono caricati 600 simboli separati.

Neanche questa è un'operazione veloce. Esaminando i file di registro generati da IIS, sono necessari circa 200 ms per caricare ciascun simbolo. Pertanto, ritardi super lunghi.

Cosa ho provato:

• Debug o versione di rilascio, non importa.
• Mettere il mio progetto su un'implementazione IIS completa su un server Web lo esegue in modo superveloce senza problemi.
• Cassini, IIS Express 7.5 e IIS Express 8.0 presentano tutti il ​​problema.
• Elimina tutti i punti di interruzione non fa nulla.
• Anche Clean Solution o l'eliminazione di .suo non fanno nulla.
• Se riparo IIS Express, o cancello la My Docs\IISExpresscartella, o riparo / reinstallo Visual Studio → il problema PUO 'andare via, ma solo per un po', prima che torni indietro.

Qualsiasi consiglio è apprezzato.

Per rispondere a più domande, sì, la mia macchina ha sicuramente la potenza. La cosa esasperante è che lo stesso progetto, con NIENTE alterato, può caricarsi molto rapidamente a volte, in genere dopo aver riparato IIS Express ed eliminato la My Docs\IISExpresscartella. Alla fine succede "qualcosa" ed è necessario caricare nuovamente 2 minuti. Quello a cui sto lavorando non è un progetto complicato. Nessuna libreria o dipendenza esterna e il mio VS.NET non ha componenti aggiuntivi.

Da notare che questa macchina ha Symantec Endpoint Protection, che ha una storia di caos. Ma disabilitarlo completamente (è bene essere un amministratore) non ha risolto il problema.

Ho una teoria a questo punto. Sto pensando che tutto questo perché sto lavorando su una cartella reindirizzata da una condivisione di rete. Mentre il debugger stava attraversando le sue centinaia di righe di "simboli caricati", ho fatto una pausa per vedere cosa stava facendo. Era nel mio codice, caricando il DisplayTemplate che avevo. Entrando nell'output del modello questo:

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'

Sembra che Visual Studio stia ricompilando il mio displaytemplate ogni volta che viene chiamato, ancora una volta, centinaia di volte. La mia teoria è che Visual Studio compila il file, lo salva nella condivisione di rete, la condivisione di rete quindi in qualche modo imprime un nuovo tempo su di esso e Visual Studio pensa quindi che il file sia cambiato e quindi Visual Studio lo ricompila di nuovo. Solo una teoria però; Non ne ho davvero idea.

Per uno, a quanto pare ho i file offline su (questo è un computer desktop in un ufficio; non me ne può fregare di meno). Domani disabiliterò, riavvio e riproverò.

Inoltre, spostare il mio progetto così com'è nella C locale: risolverlo. Si carica molto rapidamente. Ma questo non è l'ideale in un ambiente di lavoro. Perdo versioni precedenti, non viene eseguito il backup del mio codice se non lo copio manualmente e non viene più condiviso con nessuno.

Posso accontentarmi di copiarlo avanti e indietro da C alla condivisione di rete, se si tratta di esso. È molto più fastidioso aspettare due minuti per ogni caricamento della pagina.

Ecco come ho risolto il problema del "caricamento lento dei simboli" in Visual Studio 2012:

• Vai su Strumenti -> Opzioni -> Debug -> Generale

• CONTROLLA il segno di spunta accanto a "Abilita solo il mio codice".

• Vai su Strumenti -> Opzioni -> Debug -> Simboli

• Fare clic sul pulsante "..." e creare / selezionare una nuova cartella da qualche parte sul computer locale per memorizzare i simboli memorizzati nella cache. Ho chiamato il mio "Symbol caching" e l'ho inserito in Documenti -> Visual Studio 2012.

• Fai clic su "Carica tutti i simboli" e attendi che i simboli vengano scaricati dai server di Microsoft, il che potrebbe richiedere del tempo. Si noti che il pulsante Carica tutti i simboli è disponibile solo durante il debug.

• Deseleziona il segno di spunta accanto a "Microsoft Symbol Server" per impedire a Visual Studio di eseguire query in remoto sui server Microsoft.

• Fai clic su "OK".

D'ora in poi, il caricamento dei simboli dovrebbe essere molto più veloce.

Notare che se si apportano modifiche / download agli assembly Microsoft, potrebbe essere necessario tornare alla finestra di dialogo Simboli e caricare nuovamente tutti i simboli.

La disattivazione di intelliTrace ha risolto questo problema per me.

In Visual Studio, Strumenti -> Opzioni -> IntelliTrace

Quindi deseleziona la casella di controllo "Abilita IntelliTrace".

Niente di tutto ciò ha funzionato per me, ma ho trovato un punto di interruzione su un simbolo che è stato eliminato. Sembra che il 2010 fosse sospeso. Per vedere se questo è il tuo problema, esegui il debug-> windows-> punti di interruzione Se ce ne sono, eliminali.

Saunders, ha affermato di averlo verificato ma non è stato menzionato nelle soluzioni a questo problema. Forse conoscenza comune per alcuni, ma non per tutti noi.

Ho eliminato la cartella "File temporanei ASP.NET" e il caricamento della mia pagina localhost è migliorato notevolmente. Ecco il percorso ...% temp% \ File ASP.NET temporanei \

Hai abilitato FusionLog?

Il mio VisualStudio è stato molto lento da avviare, aprire la soluzione e caricare i simboli quando si avvia il debug. Era lento solo sulla mia macchina, ma non su altre macchine.

FusionLog scrive tonnellate di elementi log su disco. Disabilitarlo su RegEdit ha risolto tutto, nel mio caso.

Questa è la chiave FusionLog nel registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Controlla il valore ForceLog (1 abilitato, 0 disabilitato).

Ho riscontrato lo stesso problema e ho provato la maggior parte delle risoluzioni sopra. La semplice eliminazione dei file cache e temp finisce per funzionare per me.

Prova a rimuovere il contenuto di queste due cartelle:

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

e

C:\Users\\{UserName}\AppData\Local\Temp (in particolare le cartelle iisexpress e Temporary ASP.NET Files).

Questo può essere impostato per accadere automaticamente all'accesso a Windows aggiungendo un file cmd alla C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startupcartella con il seguente contenuto:

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

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

Penso di poter finalmente conoscere almeno la causa, anche se non il motivo. Quando il problema è ricominciato, ho notato che molti processi "conhost.exe" sono rimasti orfani. Vorrei chiudere Visual Studio e rimarrebbero aperti. Terminare l'attività su ciascuno di essi ha finalmente risolto il problema in modo affidabile. [fiduciosamente]

(Basta notare che conhost.exe non è un processo di Visual Studio sebbene Visual Studio lo utilizzi. Pertanto, altri utenti là fuori potrebbero avere altre applicazioni là fuori che eseguono conhost.exe. So che la mia macchina non lo fa, motivo per cui posso terminare in modo sicuro tutte le attività tranne YMMV.)

Quanto al perché questo accada? Sembra accadere quando apro più di un progetto alla volta, cosa che tendo a fare spesso, anche se ne costruisco ed eseguo il debug di uno solo in qualsiasi momento.

Modifica n. 1 - Purtroppo questo non è un "proiettile d'argento". Non sempre funziona per me. In genere, quando le cose si rallentano, chiudo semplicemente tutte le mie sessioni di Visual Studio, quindi vado nel Task Manager e finisco qualsiasi istanza di esso, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe e MSBuild.exe Posso trovare.

In genere, dopo di che, quando riavvio il mio progetto, questo si caricherà rapidamente. Ma non sempre.

Credo davvero che il miglior modo di agire sia probabilmente quello di non creare e debug del codice da una cartella / condivisione di rete reindirizzata.

Modifica n. 2 - Due anni dopo, e questo è ancora un problema per me in Visual Studio Community 2013, ma mi è sembrato almeno di trovare l'attività colpevole: Explorer.exe . Sì, chi lo sapeva. Nel momento in cui termino quell'attività, bam, la pagina si carica in un solo secondo.

Se ho un browser di file di Esplora risorse aperto sul mio disco di rete reindirizzato (che spesso è lì dove è il mio codice), questo problema sembra verificarsi. Chiudere la finestra non è sufficiente, devo uccidere l'intera attività Explorer.exe. Potrei solo indovinare cosa sta facendo ... impazzire con le maniglie dei file?

Di solito posso usare il task manager per avviare una nuova attività explorer.exe (posso solo prendere così tanto alt-tabbing) e Visual Studio continuerà a caricare velocemente e velocemente. Ma se apro di nuovo Windows Explorer, ritorna quasi sempre al super slow-motion.

Quindi, se hai una condivisione di rete reindirizzata, provaci. Di sicuro batte a lavorare localmente.

Quanto sopra sono tutte buone soluzioni e ho provato tutte, ma ho trovato la soluzione qui , che è

Debug -> Delete All Breakpoints

Per me era IE 9.08.8112.16241. Non appena ho usato Firefox o Chrome non è stato eseguito il debug lento con F10 o F11. Non so quale sia il problema con IE, ma ora disprezzo ufficialmente usarlo per i test.

Aggiornamento: ho disattivato tutti i componenti aggiuntivi del programma IE ed è tornato alla massima velocità. Accenderli uno alla volta ha rivelato che LastPass (nel mio caso) era il colpevole. Immagino di non dare la colpa alla SM dopo tutto.

Per me, ho implementato questo suggerimento che sostanzialmente ha drasticamente migliorato le prestazioni aggiungendo i seguenti due attributi al tag di compilazione in web.config

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

Cosa fa batch = "false"?

Rende la pre-compilazione più selettiva compilando solo le pagine che sono state modificate e richiedono una nuova compilazione

Che cosa sta facendo esattamente optimilCompilations? fonte

ASP.NET utilizza un codice hash per applicazione che include lo stato di una serie di cose, tra cui la cartella bin e App_Code e global.asax. Ogni volta che viene avviato un dominio di app ASP.NET, controlla se questo codice hash è cambiato rispetto a quello precedentemente calcolato. In tal caso, l'intera cartella codegen (dove vivono gli assembly compilati e copiati shadow) viene cancellata.

Quando questa ottimizzazione è attivata (tramite optimCompilations = "true"), l'hash non tiene più conto bin, App_Code e global.asax. Di conseguenza, se cambiano, non cancelliamo la cartella codegen.

Riferimento: elemento di compilazione su msdn

Ho avuto problemi di esecuzione delle prestazioni anche con il debug e ho provato molte opzioni di debugger. Nel mio caso, ho ottenuto enormi prestazioni quando cambio queste opzioni:

Strumenti - Opzioni - Debug - Finestra di output - (Impostazioni di output generali - Tutti gli output di debug) - OFF

Nel mio caso, è stata l'estensione .NET Reflector Visual Studio (versione 8.3.0.93) con VS 2012. Il debug impiegava 10 secondi per ogni passaggio (F10).

In Visual Studio, vai su Strumenti / Estensioni e aggiornamenti ... e disabilita l' estensione di .NET Studio per Visual Studio . Non dimenticare di riavviare Visual Studio.

Ho avuto problemi con il debug lento di Visual Studio quando è stato abilitato il debugger "Native Code" . Prova a disabilitarlo.

Su "Visual Studio 2012" vai a:

1. Proprietà del progetto ->
2. Web ->
3. Debugger (in fondo alla pagina). ->
4. Disabilita tutto tranne ASP.NET

Spero che sia d'aiuto.

Domande simili: 1 , 2

Nel mio caso lo era

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

Dopo aver deselezionato questa opzione, l'inizio del debug è passato da 45-60 secondi a 0-5 secondi.

Una volta, dopo un'interruzione di corrente, ho dovuto affrontare lo stesso problema di lentezza ogni volta che veniva colpito un breakpoint o veniva generata un'eccezione.

Ho avuto il vago ricordo che il file "suo" (nella stessa directory del file della soluzione "sln") può essere danneggiato e rallentare tutto.

Ho cancellato i miei file "suo" e tutto era ok. L'eliminazione dei file .suo è innocua e implica solo ricreare il layout di Windows, oltre al progetto iniziale e alcune altre personalizzazioni non critiche.

Stavo anche affrontando questo problema, di seguito sono riportati i passaggi che eseguo e funziona sempre per me:

• Eliminazione del file .suo della soluzione.
• Eliminazione dei file temporanei ASP.NET (è possibile trovarli all'indirizzo % WINDOW% \ Microsoft.NET \ Framework \\ File temporanei ASP.NET )
• Eliminazione di tutti i punti di interruzione nell'applicazione.

Non so se hai ancora questo problema, ma eseguo il debug dei siti in Visual Studio collegando il debugger al processo stesso anziché lasciare che VS lo faccia per me e ho scoperto che migliora notevolmente i tempi. Uso un'estensione per VS chiamata AttachTo e ho un piccolo articolo su come lo uso qui .

Spero che questo possa essere d'aiuto.

Il mio lento problema VS è stato risolto disabilitando il collegamento del browser

Se qualcuno nota che questo comportamento esce dal campo a sinistra, assicurati di non avere alcun punto di interruzione impostato in web.config. Devo averne impostato uno con un clic del mouse, e ha davvero rallentato tutte le operazioni di debug.

Dopo aver trascorso tutto il giorno ad aspettare che i simboli si caricassero lentamente quanto la velocità della tartaruga, mescolando e passando tra tutte le possibili combinazioni: Just My Code, simboli di cache , Intellitrace , Just-In-Time, processi di uccisione , ecc.

La mia soluzione era effettivamente disabilitare l'antivirus . Sì, Windows Defender stava rallentando il lancio del mio progetto! Verificherebbe tutte le DLL come richiesto da Visual Studio e rallentando l'intero processo di caricamento dei simboli.

Devo dire che le nostre macchine hanno ottime specifiche per compilare la soluzione molto velocemente, quindi non è mai stato un problema. Codifichiamo in VS 2013 Ultimate.

Svuotare la cache dei simboli ha funzionato per me.

Vedere: barra dei menu / Strumenti / Opzioni / Debug / Simboli / Cache simboli vuota

Un problema simile ha sprecato metà della mia giornata!

Dal momento che la soluzione al mio problema era diversa da ciò che è stato detto qui, lo pubblicherò in modo che possa aiutare qualcun altro.

Il mio è stato un punto di rottura. Ho avuto un breakpoint "Break at function" (cioè invece di premere F9 su una riga di codice, li creiamo usando la finestra breakpoint) che dovrebbe fermarsi in una funzione di libreria al di fuori del mio progetto.

E ho avuto "Usa Intellisense per verificare il nome della funzione " VERIFICATO. (Informazioni qui .)

Ciò ha rallentato rispetto all'inferno (avvio del progetto da 2 secondi a 5 minuti).

La rimozione del punto di interruzione lo ha risolto per sempre.

Una cosa che ha funzionato per me dopo aver fatto tutto quanto sopra è stato:
Nella finestra Discussioni (Debug-> Windows-> Discussioni), imposta Raggruppa su Nessuno. Questo può essere fatto solo durante il debug.

Ciò stava avendo un impatto anche dopo aver chiuso quella finestra.

In Visual Studio:

Strumenti -> Opzioni -> Debug -> Simboli

Scegli "Solo i moduli specificati". Fai clic sul link "specifica i moduli" e aggiungi un modulo vuoto (fai clic sul pulsante del nuovo documento e premi OK).

Apri la cartella della soluzione in Windows Explorer, chiudi Visual Studio, elimina il file .suo da Windows Explorer.

Ora apri il progetto in Visual Studio, speriamo che il debugger si attaccherà / stacchi velocemente.

Per me si trattava di punti di interruzione condizionati. Sembra che rallentino davvero le cose.

Vai alle variabili di ambiente e cerca la chiave _NT_SYMBOL_PATH.

Cancellalo.

Voila, ha funzionato come un fascino.

Il problema per me era la funzione "Link browser" che è molto pesante quando hai diverse schede aperte per lo stesso progetto!

Perché ogni volta che abbiamo lanciato il progetto, si apre una nuova scheda con le comunicazioni di collegamento del browser.

Chiudi tutte le schede associate al progetto e mantienine solo una aperta!

Questo studio visivo istantaneo gratuito! È magico ! ;-)

“Browser Link è una funzionalità di Visual Studio 2013 che crea un canale di comunicazione tra l'ambiente di sviluppo e uno o più browser Web. Puoi utilizzare Browser Link per aggiornare contemporaneamente la tua applicazione web in più browser, il che è utile per i test su più browser. "

Una soluzione semplice e veloce per coloro che non hanno molta deviazione dalle impostazioni VS predefinite.

Strumenti -> Importa ed esporta impostazioni -> Sì, salva le mie impostazioni correnti -> Visual C #

Sono sicuro che la soluzione di cui sopra funzionerebbe anche con altre impostazioni predefinite. Nel mio caso qualcosa ha incasinato le impostazioni di caricamento del mio simbolo ma non sono riuscito a risolverlo, anche se ho provato alcune delle soluzioni suggerite.

Assicurati di non aver aperto Visual Studio in modalità amministratore

Ho affrontato questo problema e ho dovuto correre in modalità normale.