Visual Studio Debuggen / Laden sehr langsam

Ich bin am Ende. Visual Studio ist in der Regel sehr langsam beim Debuggen oder beim einfachen Laden ("Starten ohne Debuggen") meiner ASP.NET MVC-Sites. Nicht immer: Zuerst werden die Projekte schön und schnell geladen, aber sobald sie langsam geladen werden, werden sie danach immer langsam geladen. Ich könnte 1-2 Minuten oder länger warten.

Mein Setup:

Derzeit verwende ich Visual Studio 2012 Express , aber ich hatte das gleiche Problem auch in Visual Studio 2010 Express. Meine Lösung ist auf einem Netzlaufwerk gespeichert. Insbesondere handelt es sich um Eigene Dateien, die auf ein Netzlaufwerk umgeleitet werden, wenn dies von Bedeutung ist. (Sollte es nicht sein. Es gibt Zeiten, in denen meine Site unter diesem Setup 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 passieren, an dem ich arbeite, und es scheint sich um DisplayTemplates zu drehen, wie es alle meine ASP.NET MVC-Projekte tun. Und es ist alles C # und Razor, wenn das wichtig ist.

Symptome:

Das System lädt meine Symbole hunderte Male. Grundsätzlich die folgenden, aber es gibt mindestens 300 solcher Zeilen mit jeweils geringfügig unterschiedlichen DLL-Dateien für die gleichen CSHTMLs:

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

Oben habe ich drei DisplayTemplates: "Kontakt", "Standort" und "Statuscode". Es scheint, dass IIS bei jedem Aufruf der Anzeigevorlage zweimal Symbole lädt. Wenn ich also eine Tabelle mit 100 Einträgen anzeige, die alle drei dieser Anzeigevorlagen aufruft, werden 600 separate Symbole geladen.

Dies ist auch keine schnelle Operation. In den von IIS generierten Protokolldateien dauert es ungefähr 200 ms, bis jedes Symbol geladen ist. Somit superlange Verzögerungen.

Was ich versucht habe:

• Debug- oder Release-Version spielt keine Rolle.
• Wenn Sie mein Projekt auf einem Webserver auf eine vollständige IIS-Implementierung setzen, läuft es superschnell und ohne Probleme.
• Cassini, IIS Express 7.5 und IIS Express 8.0 haben alle das Problem.
• Alle Haltepunkte löschen bewirkt nichts.
• Clean Solution oder das Löschen der .suo-Datei tun ebenfalls nichts.
• Wenn ich IIS Express repariere oder den My Docs\IISExpressOrdner lösche oder Visual Studio repariere / neu installiere → Das Problem kann verschwinden, aber nur für eine Weile, bevor es sofort wieder auftritt.

Jeder Rat wird geschätzt.

Um weitere Fragen zu beantworten: Ja, meine Maschine hat definitiv die Leistung. Das Wütende ist, dass dasselbe Projekt, bei dem NICHTS geändert wurde, manchmal sehr schnell geladen werden kann, normalerweise nachdem ich IIS Express repariert und den My Docs\IISExpressOrdner gelöscht habe . Schließlich passiert "etwas" und es dauert nur 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 überhaupt keine Addons.

Zu beachten ist, dass dieses Gerät über Symantec Endpoint Protection verfügt, das in der Vergangenheit Chaos verursacht hat. Das vollständige Deaktivieren (es ist gut, Administrator zu sein) hat das Problem jedoch nicht behoben.

Ich habe an dieser Stelle eine Theorie. Ich denke, das ist alles, weil ich an einem umgeleiteten Ordner von einer Netzwerkfreigabe arbeite. Während der Debugger seine Hunderte von "geladenen Symbolen" durchlief, hielt ich inne, um zu sehen, was er tat. Es war in meinem Code und lud die DisplayTemplate, die ich hatte. Beim Betreten 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 meine Anzeigevorlage jedes Mal neu kompilieren, wenn sie aufgerufen wird, was wiederum hunderte Male der Fall ist. Meine Theorie ist, dass Visual Studio die Datei kompiliert, auf der Netzwerkfreigabe speichert, die Netzwerkfreigabe dann irgendwie eine neue Zeit darauf stempelt und Visual Studio dann denkt, dass sich die Datei geändert hat und Visual Studio sie daher erneut kompiliert. Nur eine Theorie; Ich habe wirklich keine Ahnung.

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

Wenn Sie mein Projekt so wie es ist auf das lokale C: verschieben, wird es behoben. Es wird sehr schnell geladen. Dies ist jedoch in einer Arbeitsumgebung nicht ideal. Ich verliere frühere Versionen, mein Code wird nur dann gesichert, wenn ich ihn manuell kopiere, und er wird nicht mehr an Dritte weitergegeben.

Ich kann damit auskommen, es von C auf die Netzwerkfreigabe hin und her zu kopieren, wenn es darum geht. Es ist viel ärgerlicher, zwei Minuten auf jedes Laden der Seite zu warten.

So habe ich das Problem "langsames Laden von Symbolen" in Visual Studio 2012 gelöst:

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

• Aktivieren Sie das Häkchen neben "Nur meinen Code aktivieren".

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

• Klicken Sie auf die Schaltfläche "..." und erstellen / wählen Sie irgendwo auf Ihrem lokalen Computer einen neuen Ordner aus, um zwischengespeicherte Symbole zu speichern. Ich habe mein "Symbol-Caching" genannt und es in "Dokumente -> Visual Studio 2012" eingefügt.

• Klicken Sie auf "Alle Symbole laden" und warten Sie, bis die Symbole von den Microsoft-Servern heruntergeladen wurden. Dies kann eine Weile dauern. Beachten Sie, dass die Schaltfläche Alle Symbole laden nur beim Debuggen verfügbar ist.

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

• OK klicken".

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

Beachten Sie, dass Sie, wenn Sie Änderungen / Downloads an Microsoft-Assemblys vornehmen, möglicherweise zum Dialogfeld "Symbole" zurückkehren und erneut "Alle Symbole laden" müssen.

Das Ausschalten von IntelliTrace hat dies für mich behoben.

In Visual Studio Extras -> Optionen -> IntelliTrace

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

Nichts davon funktionierte für mich, aber ich fand einen Haltepunkt auf einem Symbol, das gelöscht wurde. Das Jahr 2010 schien daran zu hängen. Um zu sehen, ob dies Ihr Problem ist, debuggen Sie-> Windows-> Haltepunkte. Wenn welche vorhanden sind, löschen Sie sie einfach.

Saunders erwähnte, dass er dies überprüft habe, 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.

Ich habe den Ordner "Temporäre ASP.NET-Dateien" gelöscht und das Laden meiner localhost-Seite hat sich dramatisch verbessert. Hier ist der Pfad ...% temp% \ Temporäre ASP.NET-Dateien \

Haben Sie FusionLog aktiviert?

Mein VisualStudio startete sehr langsam, öffnete die Lösung und lud Symbole, als ich mit dem Debuggen begann. Es war nur auf meiner Maschine langsam, aber nicht auf anderen Maschinen.

FusionLog schreibt Tonnen von Protokollmaterial auf die Festplatte. Nur das Deaktivieren auf RegEdit hat in meinem Fall alles gelöst.

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

Ich hatte das gleiche Problem und habe die meisten der oben genannten Auflösungen ausprobiert. Das einfache Löschen von Cache- und temporären Dateien funktioniert 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 Temporäre ASP.NET-Dateien).

Dies kann so eingerichtet werden, dass es bei der Anmeldung bei Windows automatisch erfolgt, indem dem C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\StartupOrdner eine cmd-Datei mit folgendem Inhalt hinzugefügt wird:

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

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

Ich denke, ich kann endlich die Ursache kennen, 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 für jeden von ihnen hat das Problem endgültig und zuverlässig gelöst. [hoffnungsvoll]

(Beachten Sie nur, dass conhost.exe kein Visual Studio-Prozess ist, obwohl Visual Studio ihn verwendet. Daher haben andere Benutzer möglicherweise andere Anwendungen, die conhost.exe ausführen. Ich weiß, dass mein Computer dies nicht tut, weshalb ich dies kann Beenden Sie die Aufgabe sicher alle außer YMMV.)

Warum passiert das? Es scheint aufzutreten, wenn ich mehr als ein Projekt gleichzeitig öffne, was ich häufig mache, obwohl ich immer nur eines davon baue und debugge.

Edit # 1 - Dies ist leider keine "Silberkugel". Bei mir funktioniert das nicht immer. 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.

Wenn ich mein Projekt danach neu starte, wird es normalerweise schnell geladen. Aber nicht immer.

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

Edit # 2 - Zwei Jahre später, und dies ist immer noch ein Problem für mich in Visual Studio Community 2013, aber ich schien zumindest die Schuldige Aufgabe zu finden: Explorer.exe . Ja, wer wusste. In dem Moment, in dem ich diese Aufgabe beende, 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 Schließen des Fensters reicht nicht aus, ich muss die gesamte Explorer.exe-Aufgabe beenden. Ich konnte nur raten, was es tut ... verrückt nach Dateihandles?

Normalerweise kann ich den Task-Manager verwenden, um eine neue explorer.exe-Task zu starten (ich kann nur so viel Alt-Tabbing ausführen), und Visual Studio wird weiterhin gut und schnell geladen. Aber wenn ich den Windows Explorer wieder öffne, geht es fast immer wieder auf Super-Zeitlupe zurück.

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

Die oben genannten sind alle gute Lösungen und ich habe sie alle ausprobiert, aber hier die Lösung gefunden , nämlich zu

Debug -> Delete All Breakpoints

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

Update: Ich habe alle IE-Programm-Add-Ons deaktiviert und es ist wieder auf Hochtouren. Das Einschalten nacheinander ergab, dass LastPass (in meinem Fall) der Schuldige war. Ich glaube, ich kann MS doch nicht beschuldigen.

Für mich habe ich diesen Tipp implementiert, der die Leistung drastisch verbessert hat, indem dem Kompilierungs-Tag in web.config die folgenden zwei Attribute hinzugefügt wurden

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

Was macht batch = "false"?

Die Vorkompilierung wird selektiver, indem nur Seiten kompiliert werden, die geändert wurden und neu kompiliert werden müssen

Was genau machen die optimizeCompilations? Quelle

ASP.NET verwendet einen Hash-Code pro Anwendung, der den Status einer Reihe von Dingen enthält, einschließlich des Ordners bin und App_Code sowie global.asax. Bei jedem Start einer ASP.NET-App-Domäne wird überprüft, ob sich dieser Hash-Code von dem zuvor berechneten Code geändert hat. Wenn dies der Fall ist, wird der gesamte Codegen-Ordner (in dem kompilierte und schattenkopierte Assemblys gespeichert sind) gelöscht.

Wenn diese Optimierung aktiviert ist (über optimizeCompilations = "true"), berücksichtigt der Hash bin, App_Code und global.asax nicht mehr. Wenn sich diese ändern, wird der Codegen-Ordner daher nicht gelöscht.

Referenz: Kompilierungselement auf msdn

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

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

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

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

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

Gehen Sie in "Visual Studio 2012" 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

In meinem Fall war es

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

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

Einmal musste ich nach einem Stromausfall jedes Mal mit dem gleichen Langsamkeitsproblem konfrontiert werden, wenn ein Haltepunkt erreicht oder eine Ausnahme ausgelöst wurde.

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

Ich habe meine "suo" -Dateien gelöscht und alles war in Ordnung. Das Löschen von .suo-Dateien ist harmlos und impliziert nur die Neuerstellung meines Windows-Layouts sowie des Startprojekts und einiger anderer unkritischer Anpassungen.

Ich war auch mit diesem Problem konfrontiert. Nachfolgend sind die Schritte aufgeführt, die ich ausfü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 sie unter % WINDOW% \ Microsoft.NET \ Framework \\ Temporäre ASP.NET-Dateien )
• Löschen aller Haltepunkte in der Anwendung.

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

Ich hoffe das hilft.

Mein langsames VS-Problem wurde durch Deaktivieren des Browser-Links behoben

Wenn jemand bemerkt, dass dieses Verhalten aus dem linken Feld kommt, stellen Sie sicher, dass in web.config keine Haltepunkte festgelegt sind. Ich muss einen mit einem streunenden Mausklick eingestellt haben, und es hat alle Debug-Operationen wirklich verlangsamt.

Nachdem Sie den ganzen Tag darauf gewartet haben, dass Symbole so langsam wie die Geschwindigkeit der Schildkröte geladen werden, mischen und wechseln Sie zwischen allen möglichen Kombinationen: Just My Code, Caching-Symbole , Intellitrace , Just-In-Time, Tötungsprozesse usw.

Meine Lösung bestand darin , das Antivirus zu deaktivieren . Ja, Windows Defender hat meinen Projektstart verlangsamt! Es überprüfte alle DLLs, wie Visual Studio sie angefordert hatte, und verlangsamte den gesamten Ladevorgang der Symbole.

Ich muss sagen, dass unsere Maschinen großartige Spezifikationen haben, um die Lösung wirklich schnell zu kompilieren. Das war also nie ein Problem. Wir codieren in VS 2013 Ultimate.

Das Leeren des Symbolcaches hat bei mir funktioniert.

Siehe: Menüleiste / Extras / Optionen / Debuggen / Symbole / Leerer Symbolcache

Ähnliches Problem verschwendete besser die Hälfte meines Tages!

Da sich die Lösung für mein Problem von der hier genannten unterscheidet, werde ich sie veröffentlichen, damit sie jemand anderem helfen kann.

Meins war ein Haltepunkt. Ich hatte einen Haltepunkt "Pause bei Funktion" (dh anstatt F9 in einer Codezeile zu drücken, erstellen wir sie mithilfe des Haltepunktfensters), der in einer Bibliotheksfunktion außerhalb meines Projekts anhalten soll.

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

Dies verlangsamte sich im Vergleich zur Hölle (Projektstart von 2 Sekunden auf 5 Minuten).

Das Entfernen des Haltepunkts löste es endgültig.

Eine Sache, die für mich nach all dem funktioniert hat, war:
Setzen Sie im Thread-Fenster (Debug-> Windows-> Threads) die Gruppe Gruppieren auf Keine. Dies ist nur beim Debuggen möglich.

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

In Visual Studio:

Extras -> Optionen -> Debuggen -> 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").

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

Öffnen Sie nun das Projekt in Visual Studio, hoffentlich wird der Debugger schnell angehängt / getrennt.

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

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

Lösche es.

Voila, arbeitete wie ein Zauber.

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

Denn jedes Mal, wenn wir das Projekt starten, wird ein neuer Tab mit Browser-Link-Kommunikation geöffnet.

Schließen Sie einfach alle mit dem Projekt verknüpften Registerkarten und lassen Sie nur eine offen!

Dieses kostenlose, sofort visuelle Studio! Es ist Magie ! ;-);

„Browser Link ist eine Funktion seit Visual Studio 2013, die einen Kommunikationskanal zwischen der Entwicklungsumgebung und einem oder mehreren Webbrowsern erstellt. Sie können Browser Link verwenden, um Ihre Webanwendung in mehreren Browsern gleichzeitig zu aktualisieren. Dies ist nützlich für browserübergreifende Tests. “

Eine schnelle und einfache Lösung für diejenigen, die nicht viel von den Standard-VS-Einstellungen abweichen.

Extras -> Einstellungen importieren und exportieren -> Ja, meine aktuellen Einstellungen speichern -> Visual C #

Ich bin sicher, dass die obige Lösung auch mit anderen Standardeinstellungen funktionieren würde. In meinem Fall hat etwas meine Einstellungen zum Laden von Symbolen durcheinander gebracht, aber ich konnte es nicht beheben, obwohl ich einige der vorgeschlagenen Lösungen ausprobiert habe.

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

Ich war mit diesem Problem konfrontiert und musste im normalen Modus laufen.