it-swarm.com.de

Visual Studio Debugging/Laden sehr langsam

Ich bin am Ende. Visual Studio ist normalerweise schmerzhaft langsam zu debuggen oder einfach zu laden ("Start ohne Debuggen") meiner ASP.NET MVC-Sites. Nicht immer: Zunächst laden die Projekte Nizza und schnell, aber wenn sie langsam geladen werden, werden sie danach immer langsam geladen. Ich könnte 1-2 Minuten oder länger warten.

Mein Setup:

Ich verwende derzeit Visual Studio 2012 Express , aber ich hatte das gleiche Problem auch in Visual Studio 2010 Express. Meine Lösung wird auf einem Netzlaufwerk gespeichert. Insbesondere ist es, wenn "Meine Dokumente" auf ein Netzlaufwerk umgeleitet wird, wenn es wichtig ist. (Es sollte nicht. Es gibt Zeiten, in denen meine Website unter dieser Konfiguration sehr schnell geladen wird.)

Ich lade normalerweise in Internet Explorer 9, aber das gleiche Problem tritt in Firefox auf.

Dies kann in jedem ASP.NET-MVC-Projekt, an dem ich arbeite, passieren. Es scheint, dass es sich um DisplayTemplates handelt, die alle meine ASP.NET-MVC-Projekte ausführen. Und es ist alles C # und Razor, wenn es darauf ankam.

Symptome:

Das System lädt meine Symbole hunderte von Zeiten. Grundsätzlich die folgenden, es gibt jedoch mindestens 300 solcher Zeilen, die jeweils mit leicht unterschiedlichen DLL -Dateien für dieselben CSHTMLs versehen sind:

'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.

Im obigen Abschnitt habe ich drei DisplayTemplates: "Kontakt", "Ort" und "Statuscode". Es scheint, dass IIS bei jedem Aufruf der Displayvorlage zweimal Symbole lädt. Wenn ich also eine Tabelle mit 100 Einträgen zeige, die alle drei dieser Displayvorlagen aufruft, werden 600 verschiedene Symbole geladen.

Dies ist auch keine schnelle Operation. Wenn Sie in den Protokolldateien suchen, die IIS generiert, dauert es etwa 200 ms, bis jedes Symbol geladen ist. Also extrem lange Verzögerungen.

Was ich versucht habe:

  • Debug- oder Release-Version spielt keine Rolle.
  • Wenn Sie eine vollständige IIS -Implementierung auf einem Webserver durchführen, wird das Projekt ohne Probleme extrem schnell ausgeführt.
  • Cassini, IIS Express 7.5 und IIS Express 8.0 haben alle das Problem.
  • Alle Haltepunkte löschen bewirkt nichts.
  • Clean Solution oder Löschen des .suo-Vorgangs auch nichts.
  • Wenn ich IIS Express repariere oder den Ordner My Docs\IISExpress lösche oder Visual Studio repariere/neu installiere, KANN das Problem möglicherweise eine Zeitlang beseitigt werden, bevor es zurückkehrt.

Irgendwelche Ratschläge werden geschätzt.

Um mehr Fragen zu beantworten, ja, meine Maschine hat definitiv die Leistung. Das ärgerliche ist, dass dasselbe Projekt mit NOTHING geändert manchmal sehr schnell geladen werden kann, normalerweise nachdem ich IIS Express repariert und den Ordner My Docs\IISExpress gelöscht habe. Irgendwann passiert "etwas" und es dauert nur noch 2 Minuten, um es erneut zu laden. Woran ich arbeite, ist kein kompliziertes Projekt. Keine externen Bibliotheken oder Abhängigkeiten, und mein VS.NET hat keine Addons.

Es ist zu beachten, dass dieses Gerät über Symantec Endpoint Protection verfügt, das in der Vergangenheit Verwüstungen verursacht hat. Wenn Sie es jedoch vollständig deaktivieren (es ist gut, Administrator zu sein), wurde das Problem nicht behoben.

Ich habe an diesem Punkt eine Theorie. Ich denke, das ist alles, weil ich einen umgeleiteten Ordner von einer Netzwerkfreigabe abarbeite. Während der Debugger seine Hunderte von "geladenen Symbol" -Zeilen durchging, blieb ich stehen, um zu sehen, was er tat. Es war in meinem Code und lud die DisplayTemplate, die ich hatte. Bei der Ausgabe der Vorlage wird folgendes ausgegeben:

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'

Es sieht so aus, als würde Visual Studio mein displaytemplate bei jedem Aufruf von neu kompilieren, was wiederum hunderte Male der Fall ist. Meine Theorie ist, dass Visual Studio die Datei kompiliert, sie auf der Netzwerkfreigabe speichert. Die Netzwerkfreigabe stempelt dann irgendwie eine neue Uhrzeit, und Visual Studio denkt, dass sich die Datei geändert hat, sodass Visual Studio sie erneut kompiliert. Nur eine Theorie; Ich habe wirklich keine Ahnung.

Zum einen habe ich offenbar Offline-Dateien (dies ist ein Desktop-Computer in einem Büro; ich kann mich nicht weniger darum kümmern). Ich werde morgen deaktivieren, neu starten und es erneut versuchen.

Das Verschieben meines Projekts in das lokale C: behebt es. Es lädt sehr schnell. Dies ist jedoch in einer Arbeitsumgebung nicht ideal. Ich verliere frühere Versionen, mein Code wird überhaupt nicht gesichert, es sei denn, ich kopiere ihn manuell und er wird nicht mehr an Dritte weitergegeben.

Ich kann mit dem Kopieren von C auf die Netzwerkfreigabe hin und her gehen, wenn es dazu kommt. Es ist viel ärgerlicher, zwei Minuten auf jede Seite zu warten.

448
Ber'Zophus

So habe ich das Problem des "langsamen Symbolladens" in Visual Studio 2012 gelöst:

  • Gehen Sie zu Extras -> Optionen -> Debugging -> Allgemein

  • Überprüfen Sie das Häkchen neben "Nur meinen Code aktivieren".

  • Gehen Sie zu Extras -> Optionen -> Debugging -> Symbole

  • Klicken Sie auf die Schaltfläche "..." und erstellen Sie einen neuen Ordner auf Ihrem lokalen Computer, um zwischengespeicherte Symbole zu speichern. Ich habe mein "Symbol-Caching" benannt und in Documents -> Visual Studio 2012 eingefügt.

  • Klicken Sie auf "Alle Symbole laden" und warten Sie, bis die Symbole von den Servern von Microsoft heruntergeladen werden. Dies kann eine Weile dauern. Beachten Sie, dass die Schaltfläche Alle Symbole laden nur während des Debugging verfügbar ist.

  • Deaktivieren Sie das Häkchen neben "Microsoft Symbol Servers", um zu verhindern, dass Visual Studio die Microsoft-Server remote abfragt.

  • OK klicken".

Von nun an sollte das Laden von Symbolen viel schneller sein. 

Wenn Sie Änderungen/Downloads an Microsoft-Assemblys vornehmen, müssen Sie möglicherweise erneut in das Dialogfeld Symbole gehen und erneut "Alle Symbole laden".

589
Zeb Kimmel

Das Deaktivieren von intelliTrace hat dieses Problem für mich behoben. 

In Visual Studio Extras -> Optionen -> IntelliTrace

Deaktivieren Sie dann das Kontrollkästchen für "IntelliTrace aktivieren".

Disable IntelliTrace in Visual Studio 2012

102
moke

Nichts davon funktionierte für mich, aber ich habe einen Haltepunkt auf einem Symbol gefunden, das gelöscht wurde. Es scheint, als hinge das Jahr 2010 daran. Um zu sehen, ob dies Ihr Problem ist, gehen Sie zu debug-> windows-> breakpoints.

Saunders erwähnte, dass er dies überprüft hatte, aber es wurde in den Lösungen für dieses Problem nicht erwähnt. Vielleicht allgemein bekannt für einige, aber nicht für uns alle.

72
user2144480

Ich habe den Ordner "Temporäre ASP.NET-Dateien" gelöscht und die Lade meiner localhost-Seite wurde erheblich verbessert. Hier ist der Pfad ...% temp%\Temporäre ASP.NET-Dateien \

38
Shaun Kennedy

Haben Sie FusionLog aktiviert?

Mein VisualStudio startete sehr langsam, öffnet die Lösung und lädt beim Start des Debugging Symbole. Es war nur auf meiner Maschine langsam, aber nicht auf anderen Maschinen.

FusionLog schreibt Tonnen von Protokolldateien auf die Festplatte. Das Deaktivieren auf RegEdit löste alles in meinem Fall.

Dies ist der FusionLog-Schlüssel in der Registrierung:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Überprüfen Sie den ForceLog-Wert (1 aktiviert, 0 deaktiviert).

26
rkawano

Ich glaube, ich weiß vielleicht wenigstens die Ursache, aber nicht den Grund dafür. Als das Problem erneut auftrat, bemerkte ich eine Menge verwaister "conhost.exe" -Prozesse. Ich würde Visual Studio schließen und sie würden offen bleiben. Das Beenden der Aufgabe auf jedem von ihnen hat das Problem endgültig gelöst. [hoffnungsvoll]

(Beachten Sie, dass conhost.exe kein Visual Studio-Prozess ist, obwohl Visual Studio es verwendet. Daher können andere Benutzer da draußen andere Anwendungen haben, die conhost.exe ausführen. Ich weiß, dass mein Computer nicht funktioniert, weshalb ich dies kann Aufgabe sicher beenden, außer YMMV.)

Warum passiert das? Es scheint vorzukommen, wenn ich mehr als ein Projekt auf einmal öffne, was ich häufig mache, obwohl ich immer nur eines von ihnen baue und debugge.


Edit # 1 - Dies ist leider keine "silberne Kugel". Es funktioniert nicht immer für mich. Wenn die Dinge langsam werden, schließe ich normalerweise alle meine Visual Studio-Sitzungen, gehe dann in den Task-Manager und beende jede Instanz davon, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe und MSBuild.exe Ich kann finden.

Normalerweise wird das Projekt nach dem Neustart dann schnell geladen. Aber nicht immer.

Ich denke wirklich, dass die beste Vorgehensweise wahrscheinlich darin besteht, Code aus einem umgeleiteten Ordner/Netzwerkfreigabe nicht zu erstellen und zu debuggen.


Bearbeiten Sie Nr. 2 - Zwei Jahre später, und dies ist noch ein Problem für mich in Visual Studio Community 2013, aber ich habe zumindest die schuldige Aufgabe gefunden: Explorer.exe . Ja, wer wusste schon. In dem Moment, in dem ich diese Aufgabe beendet habe, wird die Seite in einer Sekunde geladen.

Wenn ich einen Windows Explorer-Dateibrowser für mein umgeleitetes Netzlaufwerk geöffnet habe (was häufig der Fall ist, da sich dort mein Code befindet), scheint dieses Problem aufzutreten. Das Fenster zu schließen reicht nicht aus, ich muss die gesamte Explorer.exe-Aufgabe beenden. Ich konnte nur vermuten, was es macht ... verrückt mit Feilengriffen?

Normalerweise kann ich den Task-Manager verwenden, um eine neue Explorer.exe-Task zu starten (ich kann nur so viel Alt-Tabbing verwenden), und Visual Studio lädt Nizza und schnell weiter. Wenn ich aber den Windows Explorer noch einmal öffne, geht es fast immer auf Super-Slow-Mo zurück.

Wenn Sie also eine umgeleitete Netzwerkfreigabe haben, versuchen Sie es. Es ist sicher besser als vor Ort zu arbeiten.

25
Ber'Zophus

Ich hatte das gleiche Problem und versuchte die meisten der obigen Auflösungen. Das Löschen von Cache- und temporären Dateien endet für mich.

Versuchen Sie, den Inhalt dieser beiden Ordner zu entfernen:

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

und

C:\Users\\{UserName}\AppData\Local\Temp (insbesondere die Ordner iisexpress und Temporary ASP.NET Files).

Sie können dies so einrichten, dass es beim Anmelden bei Windows automatisch geschieht, indem Sie dem Ordner C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup eine cmd-Datei mit folgendem Inhalt hinzufügen:

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

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

Die oben genannten sind alles gute Lösungen und ich habe alle ausprobiert, bekam aber die Lösung hier , die dazu kommt 

Debug -> Delete All Breakpoints
21
Tahir Hassan

Für mich war es IE 9.08.8112.16241. Sobald ich Firefox oder Chrome verwendet habe, gab es kein langsames Debugging mit F10 oder F11. Ich weiß nicht, was das Problem mit IE ist, aber ich hasse es offiziell, es jetzt zum Testen zu verwenden.

Update: Ich habe alle IE Programm-Add-Ons deaktiviert und es ist wieder auf volle Geschwindigkeit. Wenn Sie sie einzeln aktivieren, wurde LastPass (in meinem Fall) der Täter. Ich schätze, ich kann MS doch nicht die Schuld geben.

18
DMadden51

Für mich habe ich diesen Tipp implementiert, der die Leistung grundlegend verbessert hat, indem er die folgenden beiden Attribute zum compilation-Tag in web.config hinzufügt

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

Was macht batch = "false"?

Es macht die Pre-Kompilierung selektiver, indem nur Seiten erstellt werden, die haben sich geändert und müssen neu kompiliert werden

Was genau machen die OptimizeCompilations? Quelle

ASP.NET verwendet einen Hash-Code für jede Anwendung, der den Status einer .__ enthält. Anzahl der Dinge, einschließlich des Ordners bin und App_Code, und global.asax. Beim Start einer ASP.NET-Anwendungsdomäne wird geprüft, ob diese Hash-Code hat sich von dem zuvor berechneten geändert. Wenn ja, Dann wird der gesamte Codegen-Ordner (in dem kompiliert und Schatten kopiert wurden Assemblys live) gelöscht.

Wenn diese Optimierung aktiviert ist (über OptimizeCompilations = "true"), berücksichtigt der Hashwert nicht mehr bin, App_Code und global.asax. Wenn sich diese Änderungen dann ändern, tun wir dies nicht. wischen Sie den codegen-Ordner aus.

Referenz: Compilierungselement auf msdn

13
Korayem

Ich hatte auch Probleme mit der Ausführung von Fehlern beim Debuggen, und ich habe sehr viele Debugger-Optionen ausprobiert. In meinem Fall wurde eine große Leistung erzielt, wenn ich diese Optionen ändere:

Extras - Optionen - Debugging - Ausgabefenster - (Allgemeine Ausgabeeinstellungen - Alle Debug-Ausgaben) - OFF

12
arkhivania

In meinem Fall war dies die .NET Reflector Visual Studio-Erweiterung (Version 8.3.0.93) mit VS 2012. Das Debuggen dauerte 10 Sekunden für jedes Step Over (F10).

Wechseln Sie in Visual Studio zu Tools/Extensions and Updates ... und deaktivieren Sie die .NET Reflector Visual Studio-Erweiterung . Vergessen Sie nicht, Visual Studio neu zu starten.

12
shamp00

In meinem Fall war es so 

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

Nachdem ich dies deaktiviert hatte, ging mein Debug-Start von 45 bis 60 Sekunden auf 0 bis 5 Sekunden.

11
toddmo

Ich hatte Probleme mit dem langsamen Debuggen von Visual Studio, wenn der Debugger "Native Code" aktiviert war. Versuchen Sie es zu deaktivieren.

Auf "Visual Studio 2012" gehen Sie zu:

  1. Projekteigenschaften ->
  2. Web ->
  3. Debugger (Ende der Seite). -> 
  4. Deaktivieren Sie alle außer ASP.NET

Ich hoffe es hilft.

Ähnliche Fragen: 1 , 2

10

Einmal, nach einem Stromausfall, musste ich jedes Mal, wenn ein Haltepunkt getroffen wurde oder eine Exception ausgelöst wurde, das gleiche Langsamkeitsproblem haben.

Ich hatte die vage Erinnerung daran, dass die "suo" -Datei (im selben Verzeichnis wie die "sln" -Lösungsdatei) beschädigt werden kann und alles langsamer machen kann.

enter image description here

Ich habe meine "Suo" -Dateien gelöscht und alles war in Ordnung. Das Löschen von .suo-Dateien ist harmlos und bedeutet nur, dass ich mein Windows-Layout sowie das Startprojekt und einige andere nicht kritische Anpassungen neu erstellt.

9
Larry

Ich war auch mit diesem Problem konfrontiert, im Folgenden sind die Schritte, die ich durchführe und es funktioniert immer für mich:

  • Löschen der .suo-Datei der Lösung.
  • Löschen der temporären ASP.NET-Dateien (Sie finden es unter % WINDOW%\Microsoft.NET\Framework \\ Temporäre ASP.NET-Dateien). 
  • Löschen aller Haltepunkte in der Anwendung.
9
Geeky Ninja

Ich weiß nicht, ob Sie dieses Problem immer noch haben, aber ich debugge Websites in Visual Studio, indem Sie den Debugger an den Prozess selbst anfügen, anstatt dass VS es für mich erledigt, und ich habe festgestellt, dass dies die Zeiten erheblich verbessert. Ich benutze eine Erweiterung für VS namens AttachTo und ich habe einen kleinen Artikel darüber, wie ich es hier benutze. 

Ich hoffe das hilft.

9
Andrew Davis

Mein langsames VS-Problem wurde gelöst, indem der Browser Link deaktiviert wurde.

enter image description here

7
Salty

Nachdem Sie den ganzen Tag darauf gewartet haben, dass Symbole so langsam wie die Schildkrötengeschwindigkeit geladen werden, mischen und wechseln Sie zwischen allen möglichen Kombinationen: Nur My Code, Caching-Symbole , Intellitrace , Just-In-Time, Kill Prozesse , etc.

Meine Lösung war eigentlich Deaktivieren des Antivirus. Ja, Windows Defender verlangsamte meinen Projektstart! Es prüfte alle DLLs, wenn Visual Studio sie anforderte, und verlangsamte den gesamten Symbolladeprozess.

Ich muss sagen, dass unsere Maschinen großartige Spezifikationen haben, um die Lösung sehr schnell zusammenzustellen, so dass dies nie ein Problem war. Wir programmieren in VS 2013 Ultimate.

6
I.G. Pascual

Wenn jemand feststellt, dass dieses Verhalten aus dem linken Feld kommt, stellen Sie sicher, dass in web.config keine Haltepunkte gesetzt sind. Ich muss einen mit einem verirrten Mausklick gesetzt haben, der alle Debug-Vorgänge wirklich verlangsamt hat.

6
zmercier

Das Leeren des Symbol-Cache funktionierte für mich. 

Siehe: Menüleiste/Extras/Optionen/Debugging/Symbole/Cache für leere Symbole

5
Dimitri C.

Stellen Sie sicher, dass Sie Visual Studio nicht im Administratormodus geöffnet haben

Ich war mit diesem Problem konfrontiert und musste im Normalmodus laufen.

3
sajad

Gehen Sie zu Ihren Umgebungsvariablen und suchen Sie nach dem Schlüssel _NT_SYMBOL_PATH.

Lösche es.

Voila arbeitete wie ein Zauber.

3
ozba

Eine Sache, die für mich funktioniert hat, nachdem ich all das getan habe:
Legen Sie im Fenster Threads (Debug-> Windows-> Threads) Group by auf None fest. Dies ist nur während des Debugging möglich.

Dies hatte auch nach dem Schließen dieses Fensters Auswirkungen. 

3
David

Ein ähnliches Problem verschwendete die Hälfte meines Tages!

Da die Lösung für mein Problem anders war als hier, werde ich sie hier posten, damit sie jemand anderem helfen kann.

Mein war ein Haltepunkt. Ich hatte einen "Break at function" Haltepunkt (d. H. Anstatt F9 in einer Codezeile zu drücken, erstellen wir sie mit dem Haltepunktfenster), der in einer Bibliotheksfunktion außerhalb meines Projekts stehen soll.

Und ich hatte "Verwenden Sie Intellisense, um den Funktionsnamen zu überprüfen". (Info hier .)

Dies verlangsamte sich gegen die Hölle (Projektstart von 2 Sekunden auf 5 Minuten).

Das Entfernen des Haltepunkts löste dies für immer.

3
BuddhiP

Für mich waren es bedingte Haltepunkte. Die scheinen die Dinge wirklich zu verlangsamen.

2
ewolfman

Das Problem für mich war die "Browser Link" -Funktion, die sehr umfangreich ist, wenn mehrere Registerkarten für dasselbe Projekt geöffnet sind!

Jedes Mal, wenn wir das Projekt starten, wird eine neue Registerkarte mit Browser-Link-Kommunikation geöffnet.

Schließen Sie einfach alle mit dem Projekt verknüpften Registerkarten und halten Sie nur eine geöffnet!  

Dieses kostenlose sofortige visuelle Studio! Es ist Magie ! ;-)

„Browser Link ist seit Visual Studio 2013 eine Funktion, die einen Kommunikationskanal zwischen der Entwicklungsumgebung und einem oder mehreren Webbrowsern erstellt. Sie können den Browser-Link verwenden, um Ihre Webanwendung gleichzeitig in mehreren Browsern zu aktualisieren, was für das Cross-Browser-Testen hilfreich ist. “

2
A. Morel

Eine schnelle und einfache Lösung für alle, die keine großen Abweichungen von den Standard-VS-Einstellungen haben.

Extras -> Import- und Exporteinstellungen -> Ja, meine aktuellen Einstellungen speichern -> Visual C #

Ich bin sicher, dass die obige Lösung auch mit anderen Standardeinstellungen funktioniert. In meinem Fall war etwas mit meinen Symbolladeeinstellungen durcheinander, aber ich konnte es nicht reparieren, obwohl ich einige der vorgeschlagenen Lösungen ausprobierte.

2
GDS

In meinem Fall bemerkte ich, dass die Deaktivierung meiner Internetverbindung so schnell wie mit Strg-F5 ausgeführt werden konnte. Ich ging also zu debug-> options-> Symbolen und deaktivierte alle .pdb-Speicherorte.

Anscheinend versuchte VS, bei jedem Start einer Debug-Sitzung eine Verbindung zu diesen Servern herzustellen.

Beachten Sie, dass das Deaktivieren von Debug-> Optionen-> Debugging-> Allgemein "Quellenunterstützung aktivieren" oder "Quelldateien müssen genau mit der Originalversion übereinstimmen" würde keinen Unterschied machen.

2
Trap

Ihr "Eigene Dateien" Ordner, der einer Netzwerkfreigabe zugeordnet ist?

Das Starten von IIS Express kann Minuten anstelle von Sekunden dauern, wenn dies der Fall ist, selbst wenn Ihre Lösung lokal und nicht auf der Netzwerkfreigabe ist. Vergewissern Sie sich, dass in regedit.exe HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User ShellFolders\Personal auf %USERPROFILE%\My Documents zeigt. 

Ist dies nicht der Fall, ändern Sie sie oder bitten Sie Ihren Netzwerkadministrator, eine Ausnahme zu Ihrer Richtlinie zu machen.

2
adam0101

Öffnen Sie den Lösungsordner im Windows Explorer, schließen Sie das Visual Studio, und löschen Sie die .suo-Datei aus dem Windows Explorer.

Jetzt öffnen Sie das Projekt in Visual Studio, hoffentlich wird der Debugger schnell angeschlossen/gelöst.

2
Abdul Rauf

Ich hatte versehentlich die Option "Threads in Source anzeigen" ausgewählt. Bei der Abwahl der Auswahl war das Durchlaufen des Codes normal.

 Show Threads in Source

2
Ravi Selvaraj

In Visual Studio:

Extras -> Optionen -> Debugging -> Symbole

Wählen Sie "Nur angegebene Module". Klicken Sie auf den Link "Module angeben" und fügen Sie ein leeres Modul hinzu (klicken Sie auf die Schaltfläche "Neues Dokument" und klicken Sie auf "OK").

2
MCS

Es gibt auch Komplikationen in Teilansichten, bei denen ein Fehler auf der Seite auftritt, der nicht sofort erkannt wird. Wie Model.SomeValue anstelle von Model.ThisValue. Es kann nicht unterstreichen und Probleme beim Debuggen verursachen. Dies kann sehr schmerzhaft sein.

2
DMadden51

Das Debuggen von Asp.net Core war schmerzhaft langsam, da eine unbekannte VS-Erweiterung den Standard-Just-in-Time-Debugger ersetzt hatte.

Ich habe eine solche Nachricht in der Registerkarte OPTIONS\DEBUGGING\Just-In-Time-Konfiguration gefunden (als Warntext) .Ein anderer Debugger hat sich als Just-In-Time-Debugger registriert. Aktivieren Sie zur Reparatur das Just-In-Time-Debugging, oder führen Sie die Visual Studio-Reparatur aus.

Beschreibung: https://msdn.Microsoft.com/de-DE/library/ssc8234s.aspx?f=255&MSPPError=-2147217396

Wenn Sie den Standard-JIT-Debugger zurückgeben (nur die Managed-Option wurde deaktiviert), werden alle meine Probleme gelöst.

2

Ich habe dieses Problem schließlich behoben (oder zumindest verbessert), indem es diese Änderungen in der Konfiguration local IIS vorgenommen hat:

  1. Open IIS Konfiguration
  2. Klicken Sie in die Anwendungspools
  3. Klicken Sie mit der rechten Maustaste in jeden Pool und öffnen Sie die erweiterte Konfiguration
  4. Stellen Sie sicher, dass "32-Bit-Apps aktivieren" aufTRUE Und Startmodus auf AlwaysRunning eingestellt ist.

Ich hoffe, das hilft jemandem, weil ich langsam verrückt wurde, als ich versuchte, das langsame Debug-Problem zu beheben

1
kristonpelz

Jedes Mal, wenn ich während der Entwicklung mit dem lokalen Host rekompilierte, dauerte es mehrere Minuten. Es war furchtbar frustrierend. Nachdem Sie unzählige Fixes ausprobiert haben, einschließlich der Installation auf einer SSD. Ich habe gefunden, was wirklich funktioniert hat. Ich habe eine Ramdisk erstellt und das ganze Projekt darin eingefügt. Neukompilierungen zum lokalen Host sind jetzt unter zehn Sekunden. Vielleicht nicht elegant, aber es hat wirklich funktioniert.

1
kunstena

Dies könnte jemandem helfen, Ich hatte das gleiche Problem und stellte fest, dass ich eine SD-Karte mit Laufwerk e:\.__ hatte. Nachdem ich meine SD-Karte entfernt hatte, wurde das Problem behoben

1
Maro

Navigieren Sie zu IIS Express, löschen Sie den Cache und die Sites

cd "C:\Program Files (x86)\IIS Express\"
  • führen Sie diesen appcmd.exe list site /xml | appcmd delete site /in aus.
  • führen Sie diesen Del /S /F /Q %temp% aus, um den Ordner "Userprofile Temp" zu löschen.
  • führen Sie diesen Del /S /F /Q %Windir%\Temp aus. Dadurch wird der Windows-Temp-Ordner gelöscht.

Löschen Sie außerdem Ihre temporären Dateien in %temp% und melden Sie sich ab oder starten Sie den Computer neu

Dies löscht alle Seiten, viel Spaß!

1
transformer

In meinem Fall, 

Mir wurde klar, dass das Remote-Debugging ausgeführt wird und die meisten Ressourcen verbraucht. Ich musste die App nicht wirklich auf 64 Bit setzen, so dass das Remote-Debugging nicht ausgeführt wurde und die Ausführung schneller war.

0
nPcomp

Ich habe mein Visual Studio in einem neuen Job mit C # als Standardsprache eingerichtet. Mir war noch nicht klar, dass ich dazu verdammt war, in VB zu programmieren.

Ich habe den C # -Standard vergessen, da VB gut zu funktionieren schien. Das Durchschreiten des Codes nahm jedoch eine lächerliche Zeit in Anspruch. Nachdem ich einige Fixes ausprobiert hatte, änderte ich die Standardsprache in VB ... Bingo!

Wenn Sie so weit gekommen sind, ist es auf jeden Fall einen Versuch wert.

0
Resource

Für mich war es das Debuggen im Modus "Managed Compatibility". Deaktivieren Sie unter Extras -> Optionen -> Debugging -> Allgemein am Kontrollkästchen "Verwalteten Kompatibilitätsmodus verwenden". Das Debugging wurde an der Stelle ausgeführt, an der es bis zu einer Minute dauerte, bis eine Zeile durchlaufen wurde. Ich vermute, das bedeutet 'Verwaltet' in den oben genannten OP-Ausschnitten.

Mehr dazu hier: https://blogs.msdn.Microsoft.com/visualstudioalm/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/

0
Chad Hedgcock

Meine Lösung bestand einfach darin, eine gespeicherte GOOD (Backup) -Kopie meiner Einstellungen (vor einem Jahr) neu zu laden. Einen Versuch wert, bevor Sie alles auf leer stellen. Mein VS2010 würde 60 Sekunden brauchen, um mit dem Debuggen zu beginnen. 3 Minuten, um das Debuggen zu beenden. Ich habe die beschädigten Einstellungen gespeichert und zu meiner Überraschung waren sie über 3 MB statt 260 KB. Ich habe die gute Sicherungskopie geladen und alles ist wieder toll :-)

0
David Coster

In meinem Fall war das Problem eine externe exe-Datei - und zwar:

WUDFCompanionHost.exe

unter dem Namen 

"Windows Driver Foundation - User-mode Driver Companion Framework Host Process".

Prozess, der stetig 10% der CPU beansprucht hat. Das Töten half direkt und innerhalb einer Sekunde wurde die Seite geladen.

0
belchev

Eine weitere mögliche Ursache ist die Vorkompilierung alter Projekte, die auf dem Dateisystem vorhanden sind, jedoch aus Visual Studio entfernt oder teilweise entfernt wurden.

Ich hatte eine Lösung, deren Laden nach einem Build 3,5 Minuten dauerte. Ich habe mir die Zeitstempel in temporären ASP.NET-Dateien angesehen und festgestellt, dass sich die Verzögerung von 3 Minuten auf eine Datei in einem alten Projekt bezieht. Habe in VS nachgesehen und das Projekt war "nicht verfügbar". Es wurde aus VS gelöscht, aus dem Dateisystem gelöscht und jetzt sind es nur noch süße 8 Sekunden.

0
planetClaire

Ich hatte dieses Problem mit VS 2013. Monatelang waren meine Tests in Ordnung, aber plötzlich tauchten die gefürchteten Loading Symbole -Meldungen auf, und ich wusste nicht, was ich getan hatte, um es zu verursachen.

Nichts, was hier oder auf einer anderen Internetseite vorgeschlagen wurde, hat mir geholfen. Ich habe alles mindestens 10 mal probiert. Das Löschen der Datei .suo hat nicht geholfen, aber am selben Speicherort befanden sich zwei Dateien mit.testsettingsextension und eine mit.vsmdiextension. Diese Dateien schienen veraltet zu sein, vielleicht ein Relikt von VS 2010. Das Teammitglied, das sie erstellt hatte, war längst vorbei.

Ich fand, dass ich alle drei Dateien ohne Probleme löschen konnte. Ich fand heraus, dass es genug war, nur eine bestimmte der.testsettings-Dateien zu entfernen, um die Loading-Symbole -Meldungen zu stoppen. Mein Albtraum ist vorbei.

0
Tony Pulokas

Für mich war das Problem Avast Antivirus. Ich habe es deinstalliert und stattdessen mit Windows Defender ausgeführt und alles funktioniert einwandfrei. In meiner Lösung hatte ich dieses Problem nur beim Ausführen von Windows-Anwendungen, entweder WinForms oder WPF. Aus irgendeinem Grund war es bei Webanwendungen nie langsam. 

0
Ogglas

Löschen Sie alles aus c:\Users\Benutzername\AppData\Local\Temp\und versuchen Sie es erneut.

0

Mein Problem war, dass das Projekt jedes Mal erstellt wurde, wenn ich mit dem Debuggen begann. Alle anderen Lösungen in diesem Thread haben leicht geholfen, aber ich musste trotzdem warten, bis das Projekt fertiggestellt war.

Meine Lösung, um den Build bei jedem Debugging zu vermeiden:

  • Gehe zu Solution Explorer -> Rechtsklick Your Solution File -> Klick Properties
  • Wählen Sie im Property Pages -> links Configuration -> und deaktivieren Sie Build.

  • Klicken Sie auf OK.

  • Stellen Sie sicher, dass Visual Studio als Administrator geöffnet ist.

  • Gehe zu Debug -> Attach to Process
  • CLICK-Kontrollkästchen Show processes from all users -> Find and Select-Prozess namens w3wp.exe -> Klicken Sie auf Attach ->, wenn die Warnung angezeigt wird, klicken Sie auf Attach.

Jetzt können Sie in localhost zu der Seite navigieren, die Sie debuggen möchten. Wenn in Ihrer Datei Haltepunkte festgelegt sind, können Sie sofort mit dem Debuggen beginnen, ohne auf die Erstellung Ihres Projekts warten zu müssen !!

0
Austin Perez