Visual Studio Build sehr langsam

71

Dies gilt sowohl für die Versionen 2008 als auch 2010 (und wahrscheinlich auch für frühere). Auch für C ++ - und C # -Projekte.

Ein erster Build (nach dem Neustart) wird mit normaler Geschwindigkeit und mit relativ guter CPU-Auslastung ausgeführt. Nach "einiger Zeit" (dh Verwenden des Computers für "Sachen") kann ein nachfolgender Build sehr, sehr langsam und mit sehr geringer CPU-Auslastung ausgeführt werden. Die einzige Lösung, die ich gefunden habe, scheint ein Neustart zu sein, dann beginnt der Zyklus von vorne. Dies geschieht sowohl bei WPF- als auch bei Nicht-WPF-Projekten, obwohl es bei WPF zehnmal schlimmer ist.

Dies ist mir auf verschiedenen Computern passiert, sogar auf verschiedenen Organisationen. Ich denke, es ist eine Visual Studio-Sache, keine Umgebungssache. Ich habe das Übliche versucht (Google, AV, Intellisense, Resharper usw. ausschalten und freue mich derzeit darauf, die bestellte SSD zu erhalten).

Meine aktuelle Maschinenspezifikation ist 2,7 Gigabyte Quad Core, 4 GB RAM, XP (Win7 ist noch nicht in Betrieb), 250 GB Festplatte usw.

Hat jemand eine Idee, was das sein könnte und wie man es behebt?

Danke im Voraus!

Maz
quelle
Wenn ich raten müsste, würde ich sagen, dass Visual Studio sich einen bestimmten Prozentsatz des gesamten verfügbaren Speichers reserviert, den es für seinen Cache verwendet. Wenn weniger Gesamtspeicher verfügbar ist, gibt es weniger VS-Speicher und damit weniger Caching. Ich weiß es aber nicht.
Phillip Schmidt
Ich habe das gleiche Problem mit VS2010 und WPF - ich habe eine SSD und es hilft keiner.
BrainSlugs83
Hmm. Ich habe dies jahrelang auf mehreren Computern mit VS2008 und VS2010 mit nativem C ++ gehabt, aber es scheint verschwunden zu sein, da ich mich nicht daran erinnere, dies kürzlich gesehen zu haben.
Drescherjm

Antworten:

106

Versuchen Sie dies, wie es für mich funktioniert hat:

Drücken Sie Windows+ Roder öffnen Sie den Lauf von Start.

Jetzt tippe %temp%und lösche alles von dort ...

Öffnen Sie nun erneut Ausführen und geben Sie prefetchdort auch alles ein und löschen Sie es.

Öffnen Sie nun VS und sehen Sie sich die Leistung an.

Sam
quelle
4
Wow, der Prefetch hat es geschafft. Ich habe alle% temp% -Dateien gelöscht und ungefähr 3 GB zurückgewonnen, aber das hat es nicht behoben. Das Entfernen des Inhalts aus dem Prefetch hat es geschafft!
Agarcian
Verwenden Sie ccleanerund fügen Sie aus Optionen die Ordner %temp%und prefetchden Download-Link ccleaner.com/ccleaner/download/standard
Ashraf Abusada
31

Versuche dies:

Devenv.exe / resetsettings

jurget
quelle
Dieses Flag hat Probleme behoben, die ich mit VS2010 hatte, das beim Start hängen blieb. Ich werde mich für die Zukunft daran erinnern!
Henry Wilson
3
Ich hatte gerade das gleiche Problem in 2012/13. Gehen Sie zu Extras / Exporteinstellungen importieren / Zurücksetzen. Ich habe es gelöst. Das Problem wurde durch einen Stromausfall im Ruhezustand verursacht und ich denke, die Einstellungsdatei wurde beschädigt.
Peterincumbria
@ Jurget Danke. Dies brachte mich aus einem Stau heraus, in dem etwas zwischen dem Azure SDK-Update und meinen anderen webbezogenen Einstellungen in Visual Studio dazu führte, dass webbezogene Vorgänge unglaublich langsam ausgeführt wurden und sogar die Website lokal ausgeführt wurde. Ich bin mir nicht sicher, ob es wichtig ist, aber ich habe diesen Befehl auch ausgeführt, während ich mich in einer Eingabeaufforderung auf Administratorebene befand.
Robert Oschler
18

Ich hatte das gleiche Problem.

Ich hatte McAfee Security Center installiert, indem ich den "Echtzeit-Scan" deaktivierte.

Die Bauzeiten gingen von 40 Sekunden für ein kleines Projekt auf 1 Sekunde.

Harm van der Haas
quelle
Kaspersky für mich; 1+ Minuten bis 1 Sekunde.
Nick
1
Windows Defender: 40 Sekunden => 3 Millisekunden. Vielen Dank!
Toddmo
Bitdefender verursachte ebenfalls Probleme und fror sogar VS ein. 10+ Sek. Bis 1 Sek. Vielen Dank!
John M.
MalwareBytes Echtzeitschutz für mich
GHC
In meinem Fall Ende 2020 wurde Acronis True Image Protection ausgeführt und meine Projektordnerzeiten wurden wieder normalisiert
Rippo
12

Überprüfen Sie Ihre Energiespareinstellungen in Windows. Stellen Sie "Hochleistung" ein (auch auf dem Desktop). Das hat mir geholfen.

Gijs Mater
quelle
1
Ich verwende VS2015 unter Windows 10 und hatte das gleiche Problem. Ich habe die Verzeichnisse% temp% und prefetch gelöscht. Dann habe ich die Einstellung devenv.exe zurückgesetzt, aber sie haben nicht geholfen. Dann habe ich die Energiespareinstellungen von Balanced auf High Performance geändert und es hat funktioniert. Die CPU wird zu 100% ausgelastet. Die CPU-Auslastung stieg nicht über 30%
irsis
1
Nach dem plötzlichen Stromausfall auf unserem Campus bekam ich das VS 2015 Build-Problem. Es dauert ewig, eine Lösung zu entwickeln. Das ist die Methode, damit es funktioniert. Diese Methode scheint so seltsam, aber es funktioniert wirklich. Vielen Dank.
Boveyking
1
Aus Neugier habe ich den Energieplan wieder auf Balance umgestellt und angefangen, die Lösung zu bauen, sie blieb wieder hängen. Dann wieder auf Hochleistung umgestellt, baute es. Es scheint, dass dies nur eine Methode für mich ist, um VS zum Laufen zu bringen. Ich bin so glücklich, in einer so wundervollen Welt zu leben und auf einem so wunderbaren Gebiet zu arbeiten. Ich sehe jeden Tag Wunder.
Boveyking
uowwwwwwwwwwwwwwwww ... Ich hatte einen langsamen Build, und das funktionierte für mich ... Außerdem hatte ich nach dem Stoppen des Debuggens eine Verzögerung, die durch Löschen aller Haltepunkte behoben wurde (es gab viele deaktivierte Haltepunkte) ... Jetzt wurde viel gearbeitet besser ... danke für diese Antwort ... Ich bin sicher, diese Änderung wird mir weitere Leistungsverbesserungen bringen ..
Fernando Meneses Gomes
7

Versuchen Sie, ProcessMonitor ( http://technet.microsoft.com/en-us/sysinternals/bb896645) zu verwenden ) zu verwenden, um herauszufinden, was Visual Studio während des Erstellungsprozesses tut. Fügen Sie den Filter "ProcessName is devenv.exe dann Include" hinzu und recherchieren Sie. Es war nützlich für mich.

Ich habe ein ähnliches Problem - einen sehr langsamen Build- und Debug-Prozess - und kann es mit Process Monitor lösen. Ich habe Process Monitor ausgeführt und festgestellt, dass der Visual Studio-Prozess einige HTL-Dateien viele Male gelesen und geschrieben hat. Es war das Assembly Binding Log ( http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4(v=vs.100).aspx ) - das Dienstprogramm, das Informationen zur Bibliotheksbindung speichert. Nachdem ich dieses Protokoll aktiviert und dieses Dienstprogramm ca. 8 GB HTM-Protokolle auf meiner Festplatte erstellt hatte, war es sehr langsam. Dann deaktiviere ich die Protokollierung, die Bauzeit meines Projekts verringert sich von 10 Minuten auf 10 Sekunden!

Kosix
quelle
2
Bitte posten Sie einen Beispielcode, nicht nur Links, damit Ihre Antwort immer noch nützlich ist, wenn die Links tot sind.
Illidanek
Das hat mir nicht geholfen. Ich sehe, dass es viel in Protokolle geschrieben hat, aber das Ausschalten hat nicht geholfen.
Daniel Ryan
3

Ich verwende VS2015 unter Windows 10 und hatte das gleiche Problem. Ich habe die Verzeichnisse% temp% und prefetch gelöscht, die nicht funktionierten. Dann habe ich die Energiespareinstellungen von Balanced auf High Performance geändert und es hat funktioniert.

dhina s
quelle
2

Ich habe diese Art von Antwort nicht gesehen, daher denke ich, dass meine für jemanden hilfreich sein könnte. Mein Problem mit der VS-Erstellungszeit war dumm: Ich hatte den Quellcode auf einem anderen Computer. Jedes Mal, wenn ich versucht habe, es zu erstellen, muss eine Verbindung zu diesem Computer hergestellt werden, was zu einer langen VS-Einfrierzeit führt. Ich habe dieses Problem entdeckt, nachdem ich die meisten Lösungen hier und anderswo ausprobiert hatte. (Emoticon mit dem Kopf gegen den Schreibtisch schlagen)

Gabriel Marius Popescu
quelle
1

Meine Lösung für das sehr träge Visual Studio (das Erstellen dauerte etwa 1,5 bis 2 Minuten) bestand darin, das drahtlose Netzwerk auszuschalten.

Ich hatte das drahtlose Netzwerk zusätzlich zu dem kabelgebundenen aktiviert. Anscheinend hat mein Computer versucht, über die drahtlose Verbindung eine Verbindung zu unserem lokalen Server herzustellen, der für das drahtlose Netzwerk nicht verfügbar ist und die lange Verzögerung verursacht hat.

Antti
quelle
Können Sie noch etwas Licht ins Dunkel bringen? - Wie genau beeinflusst die Netzwerkgeschwindigkeit die Erstellungszeit von Visual Studio? - Auf jeden Fall habe ich das oben beschriebene Problem auf einem Desktop (ohne drahtlose Netzwerkkarte).
BrainSlugs83
1
Dies geschah vor so langer Zeit, dass ich mich nicht an die genauen Details erinnere, aber es war ungefähr so, dass der Erstellungsprozess, als ich das drahtlose Netzwerk verbunden hatte, aus irgendeinem Grund versuchte, eine Verbindung zu einem Netzwerklaufwerk herzustellen, und auf das Standardnetzwerk von Windows wartete Standort-Timeout, bevor der Build fortgesetzt wurde. Als ich das drahtlose Netzwerk schloss (das keinen Zugriff auf unser Netzwerklaufwerk ermöglichte) und nur das kabelgebundene Netzwerk verwendete (das den Zugriff auf das Netzwerklaufwerk ermöglichte), wurde der Erstellungsprozess sehr viel schneller.
Antti
Visual Studio versucht, eine Verbindung zum MS-Server herzustellen und einige Informationen herunterzuladen. Wenn Ihre Internetverbindung ausgeschaltet ist, wird der Build normal ausgeführt.
Ali Amanzadegan
1

Wenn es sich um ein ASP.NET MVC-Projekt handelt, überprüfen Sie die .csproj-Datei, um festzustellen, ob sie festgelegt <MvcBuildViews>true</MvcBuildViews>ist. Dies kann zu langsamen Builds führen.

bkaid
quelle
1

Ich hatte das gleiche Problem. Das Löschen des versteckten .vsOrdners im Lösungsverzeichnis löste das Problem.

György Kőszeg
quelle
1

Einer der Gründe ist, dass Visual Studio immer wieder dieselben abhängigen Projekte neu erstellt, obwohl sich nichts geändert hat. Stellen Sie sich eine Lösung mit Tonnen von Projekten vor, die ohne ersichtlichen Grund weiter erstellt werden. Das verschwendet RIESIGE Zeit ...

Die Hauptlösung hierfür besteht darin, jedes "In Ausgabeverzeichnis kopieren " zu überarbeiten, wobei es auf " Immer " gesetzt ist. Ändern Sie dies in " Kopieren, wenn neuer ".

Es kann hilfreich sein, ein detailliertes Build-Protokoll anzuzeigen. Öffnen Sie Extras > Optionen > " Projekte und Lösungen "> " Erstellen und Ausführen ". Setzen Sie nun "Ausführlichkeit der Ausgabe des MSBuild-Projektaufbaus" auf " Diagnose ".

Für weitere Informationen wird in diesem Thread dieser spezielle Punkt erläutert

Korayem
quelle
0

Wie lange dauert "Irgendwann"? (zB Stunden? Tage?)

Es könnte so einfach sein, dass Ihnen der Arbeitsspeicher ausgeht. Strg-Umschalt-Esc lädt den Prozessmonitor, auf dem Sie Ihre Speichernutzung sehen und Schweine töten können. Sobald es knapp wird, verlangsamen Ihre Linker den Versuch, Speicher auf die Festplatte zu übertragen (und Windows meldet normalerweise keinen Austauschaufwand, es sei denn, Sie aktivieren die Systemauslastung). Abhängig von der Größe Ihres Projekts kann Linking RIESIGE Mengen an Speichererstellungstabellen verwenden.

Yeraze
quelle
Nein, viel RAM (zB 1,5 GB für 4 GB), also ziemlich sicher, dass die Festplatte nicht überlastet wird. "Some time" ist oft der 2. oder 3. Build nach einem Neustart, möglicherweise mit ein wenig Debugging zuvor. Ich konnte im Proc Explorer nichts Nützliches herausfinden. Der einzige "Hinweis" ist, dass es nach einem Neustart für eine Weile gut funktioniert. Die Frage ist, was kann dazu führen, dass der Computer nach einigen Build- / Debug-Sitzungen verstopft wird? Danke
Maz
1
Ich stoße auf das Problem (mit WPF-Projekten auf VS 2010) sowohl auf meinen 8-GB- als auch auf meinen 16-GB-Computern (wobei in beiden Fällen mehr als 50% verfügbar sind, 16 GB sind ein 2,2-GHz-Quad-Core mit HT, 8 GB sind 3,2 GHz AMD Hexa-Core).
BrainSlugs83
Entschuldigung für die Ablehnung, war versehentlich und kann es nicht rückgängig machen. Kann es zurücksetzen, wenn die Antwort bearbeitet wird.
Krzysztof Bociurko
0

Irgendwann hatte ich ein Programm, dessen Kompilierung nach einigen Wochen erheblich länger dauerte. Aus Frustration habe ich den Debug-Ordner der Lösung und der Projekte gelöscht. Visual Studio hat zunächst die gesamte Lösung neu erstellt (was einige Zeit in Anspruch nimmt), aber danach hatte der Bauprozess seine alte Geschwindigkeit wieder. Ich bin mir nicht sicher, ob es auch bei Ihnen funktioniert.

JMRC
quelle
0

Überprüfen Sie die Option Internet-Eigenschaften (Verbindungen) und stellen Sie sicher, dass diese Option aktiviert Automatically detect settingsist.

ewwink
quelle
0

Wenn eine einzelne Lösung viele Projekte enthält, versuchen Sie, nur die geänderte zu erstellen, anstatt die gesamte Lösung zu erstellen. Alt + B + U statt Alt + B + B.

Cheny
quelle
0

Erstellen Sie eine Sicherungskopie der Dateien und löschen Sie alles in dem Ordner in diesem Ordner.

C: \ Benutzer \ {Benutzername} \ AppData \ Local \ Microsoft \ WebsiteCache

Starten Sie Visual Studio neu und überprüfen Sie die Leistung.

Hoffe das hilft! Vielen Dank

Mohamed Alikhan
quelle
0

Führen Sie zur schnellen Überprüfung einen Scan durch, um sicherzustellen, dass derzeit nichts Ihr System infiziert, und gehen Sie dann zu Windows Defender Security Center-> Viren- und Bedrohungsschutz -> Echtzeitschutz deaktivieren:

Echtzeitschutz

Erstellen Sie Ihre Lösung in Visual Studio neu, notieren Sie sich die Gesamtzeit und beobachten Sie im Task-Manager, ob die ausführbare Datei des Antimalware-Dienstes anscheinend erhebliche Prozessorzeit beansprucht. Angenommen, Ihr Build ist schneller und Ihre CPU weniger ausgelastet. Herzlichen Glückwunsch, Sie haben eine Ursache für Ihre Leistungsprobleme identifiziert. Der nächste Schritt besteht darin, Windows Defender verantwortungsbewusst anzuweisen, Visual Studio in Ruhe zu lassen, ohne es vollständig auszuschalten.

Kasturi Sameer
quelle
0

In meinem Fall habe ich das Verzeichnis "wwwroot" im Projektverzeichnis verwendet, um einige GB Daten zu speichern. Das Verschieben der "wwwroot" aus dem Lösungsverzeichnis löste meine Erstellungszeiten. Für meine .NET Core-Webanwendung habe ich launchSettings.json bearbeitet und eine neue Umgebungsvariable hinzugefügt ASPNETCORE_WEBROOT:

...
"profiles": {
    "Development": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "ASPNETCORE_WEBROOT": "../../wwwroot"
      },
      "applicationUrl": "https://localhost:5001;http://localhost:5000"
    },
...
xhafan
quelle
0

Da ich über eine Google-Suche hierher gekommen bin, werde ich das veröffentlichen, was ich als Lösung für mein spezifisches Problem gefunden habe.

Ich hatte ein Upgrade von .NET Core 1.1 auf .NET Core 2.1 durchgeführt. Dies führte dazu, dass die Aufrufe von RazorGenerate und RazorTagHelper jeweils 20 Sekunden dauerten. Laut Daniel Crabtree wurde dies durch eine Änderung in .NET Core 2.1 verursacht, die standardmäßig das Vorkompilieren von Razor-Ansichten ermöglicht.

Das Update besteht darin, Ihrem .csproj Folgendes hinzuzufügen:

<PropertyGroup>
  <UseRazorBuildServer>false</UseRazorBuildServer>
</PropertyGroup>

Quelle: https://www.danielcrabtree.com/blog/444/speed-up-compilation-of-asp-net-core-2-1-projects

Travis Daily
quelle
0

Fügen Sie in YourProject.csproj das Ziel- Tag in die letzte Zeile Ihres Projekt- Tags ein

<Project>
.
.
<Target Name="PlatformVerificationTask" Condition="'$(SkipPlatformVerification)' 
    != 'true'" />  
</Project>
Khant Htet Naing
quelle
-1

Gleiches Problem mit jedem Befehl oder jeder Funktion, die ich auf VS ausgeführt habe. Nach dem Deaktivieren von Antivirus REAL TIME PROTECTION wurde die Laufzeit von 10 Sekunden auf 0,5 oder sogar weniger Sekunden reduziert. Interessant war übrigens, dass die Aktionen von Antivirus die C # -Laufzeit verlangsamten, aber C ++ war völlig in Ordnung.

Bär Grylls
quelle
Obwohl Ihre Erfahrung wahr sein mag, gab OP an, dass Antivirus bereits vollständig deaktiviert wurde und dass dies nicht hilfreich war. Außerdem hatten sie Probleme mit der C ++ - Seite. Ich bin froh, dass Sie Ihre Lösung gefunden haben.
Orion
Nun, wie ich aus den Kommentaren sehe, hat dieses Problem verschiedene Lösungen für verschiedene PCs (oder der Grund ist auch die konkrete Art von Antivirus, weil meine "Avira Antivirus" war)
Bear Grylls