Immerhin war ich in der Lage, das Problem zu lösen, alle unnötigen Visual Studio-Pakete auf eine saubere und minimal-invasive Weise zu deaktivieren, die keine Änderung der VS-Konfigurationsdateien oder das Herumspielen mit der Registrierung erfordert! Dies beinhaltet die Task Runner-Einrichtung, die VsHub-Einrichtung, die eine Menge VS-Instabilität und Verlangsamung verursacht, sowie jedes andere VS-Paket von mehr als 150, mit dem es geliefert wird.
Hier ist eine kurze Zusammenfassung: Grundlegende Funktionalität Komponente für VS ist ein Paket (nicht mit NuGet-Pakete verwechseln - diese sind hier nicht relevant). Alle Erweiterungen, die Sie aus dem Web installieren können (sowie viele vorinstallierte), haben die Form von VSIX, das ein erweitertes Paketformat ist. Visual Studio verfügt über eine API (unveröffentlicht, aber immer noch), die mit VSIX-Paketen arbeiten kann, einschließlich der Suche nach diesen und der Aktivierung / Deaktivierung dieser. Leider kann es nur mit VSIX umgehen und sieht keine reinen VS-Pakete. Dies wird per Design deklariert - reine VS-Pakete werden als Systemkomponenten betrachtet und haben keine Möglichkeit, sie zu deaktivieren. Oder so sagen sie ... Ich habe das offizielle (obwohl schlecht veraltete) MS-Plugin für Extensions-Diagnosen dekompiliert und festgestellt, dass es direkt an der Registry fummelt, um Informationen über installierte VSPackages zu erhalten, versucht aber nicht einmal, dort etwas zu ändern (Disable). Meine eigene Untersuchung von HKCU \ Software \ Microsoft \ VisualStudio hat entdeckt, dass riesige und ausgeklügelte Datenstrukturen nutzlos sind, weil es nur der Cache des VS-internen Status ist, den VS zufällig und oft aktualisiert, also selbst wenn wir herausfinden, wie man ihn deaktiviert Das Paket durch die Registrierung wäre sinnlos, da VS es sofort überschreiben würde.
Zwei Hinweise, die mich schließlich zur endgültigen Lösung brachten, waren: 1. Es gibt eine Datei C: \ Programme (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ devenv.pkgdef Der Inhalt dieser Datei ist nicht besonders interessant, aber meine C ++ Vergangenheit gab mir einen Hinweis darauf, ob PkgDef vorhanden ist Es besteht eine gute Chance, dass es auch PkgUnDef gibt, obwohl es normalerweise nicht vorhanden ist. ProcMon hat bestätigt, dass während des Starts VS auf devenv.pkgundef Dateipräsenz überprüft und ich auf dem richtigen Weg war. 2. Zweiter Hinweis - Ich weiß, dass einige andere Produkte (denken Sie an SQL Server Management Studio) VS-Shell in Verkleidung verwenden (deshalb sehen Sie VS 2010 in Ihren Add \ Remove-Programmen - es ist SQL SMS). Und diese anderen Produkte haben offensichtlich eine Möglichkeit, die meisten VS-Funktionen auszusortieren und nur ein paar Funktionen zu belassen, die sie wirklich brauchen. Also habe ich gelernt wie sie es machen und hier gehts - pkgundef datei nochmal!
Es war eine Frage von ein paar Sonden und Registry-Scans, um den richtigen Inhalt für devenv.PkgUnDef zu schreiben, um die Pakete loszuwerden, die ich nicht mag, ohne sichtbare Nebenwirkungen oder schlimme Folgen.
Mein C: \ Programme (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ devenv.pkgundef sieht folgendermaßen aus:
%Vor%Um zu überprüfen, welche spezifischen Pakete Sie geladen haben, gibt es Extension Analyzer . Es ist ziemlich altmodisch, also habe ich eine Version gehackt, die mit hier funktioniert.
.Eine andere Möglichkeit zu sehen, was VS verlangsamt, ist, es mit dem / Log-Parameter auszuführen und Aktivitätsprotokoll-Proviler anzuwenden.
Ich hoffe, es hilft den Leuten, ihr schlankes und schnelles Visual Studio wiederzuerlangen! Konstantin
Die Links unten erklären, wie Pakete (Erweiterungen) deaktiviert werden, die in Visual Studio integriert sind.
Grundsätzlich:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools
. extension.vsixmanifest
-Datei und das TaskRunnerExplorer
-Verzeichnis. TaskRunnerExplorer\*.pkg
-Dateien und notieren Sie GUID-Schlüssel am Anfang der Dateien (z. B. [$RootKey$\Packages\{b483c4e7-43a6-4f7b-a9a1-79e2c5d12148}]
). extension.vsixmanifest
und entfernen Sie alle Erwähnungen von TaskRunnerExplorer. TaskRunnerExplorer
. HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio.0_Config\Packages\
. Momentan sind diese Schlüssel {8da206d4-9521-4f38-92c9-a8d5d0af611c}
und {b483c4e7-43a6-4f7b-a9a1-79e2c5d12148}
. Hinweis: Um Dateien in Program Files (x86)
zu bearbeiten, müssen Sie entweder Ihre Notepad-Anwendung im Admin-Modus ausführen oder eine Kopie in einem Verzeichnis bearbeiten, das Ihnen gehört, und dann das Original überschreiben.
Ich habe Probleme mit Visual Studio 2015 gehabt, als ich eine Million Instanzen von node.exe
hochgefahren habe, immer und immer wieder, wenn ich unsere Website-Lösung öffne. Das hat dazu geführt, dass McAfee Nannyware und die Dell-Verschlüsselungssoftware, die sie auf unseren Entwicklungskisten installiert haben, aus dem Ruder laufen.
Dazwischen war die CPU ziemlich verbraucht. Unnötig zu sagen, das hat es ... schwierig gemacht, Dinge zu erledigen.
Also musste ich über Dinge nachdenken, und ich dachte, wenn ich die node
, npm
und gulp
Binärdateien ausgeben könnte, wären sie zumindest nicht in der Lage, irgendeine CPU zu verbrauchen. Also schrieb ich über die denkbar einfachsten Stub-Konsolen-Apps. Meine eigenen Versionen von
node.exe
gulp.exe
npm.exe
npm.cmd
, das einfach mein npm.exe
ausgeführt hat und seine Befehlszeilenargumente lang übergeben hat. Das einzige, was diese ausführbaren Dateien tun, ist, log4net
zu verwenden und eine Zeile in eine Protokolldatei zu schreiben, mit dem Namen der ausführbaren Datei und den Argumenten, mit denen die ausführbare Datei aufgerufen wurde. Ich parkte die 4 davon in einem Verzeichnis und nutzte diesen Beitrag
Konfigurieren von Visual Studio 2015, um meine ausführbaren Stubbed-Dateien an den Anfang des Suchpfads zu setzen.
WELL ...
Es stellt sich heraus, dass Visual Studio 2015 wiederholt npm
wie folgt aufgerufen hat:
Also ging ich zur Wurzel unseres Projekts und führte denselben Befehl aus (mit den echten Binärdateien). Und siehe da, npm
schleuderte und meldete Fehler, indem er versuchte, eine nicht existierende package.json
zu öffnen, die sich in der Baumstruktur von
Es sah aus, als wäre es ein Überbleibsel aus einer Zeit zurück, die dort leere Verzeichnisse hinterlassen hatte. Sobald ich die leeren Verzeichnisse entfernt habe, in denen versucht wurde, ein nicht vorhandenes package.json
zu öffnen, ist das Leben gut.
HINWEIS: Jemand hat die Stub-Executables angefordert, die ich hier durch einen Kommentar beschrieben habe. Sie können den Quellcode für sie in Github bei Ссылка
findenViel Spaß.
In Visual Studio 2015 können Sie verhindern, dass Gulp bei jedem Build ausgeführt wird.
Wenn das erledigt ist, sollte der Bindings-Baum so aussehen, wie Nullen nach jedem Element auf der obersten Ebene angezeigt werden.
Beachten Sie, dass die oben genannten Änderungen über die Benutzeroberfläche letztlich dazu führen, dass Elemente aus gulpfile.js
selbst entfernt werden. Sie können diese Änderung also genauso einfach vornehmen, indem Sie etwas entfernen, das wie folgt aussieht:
Dies ist nicht "in Visual Studio", aber Sie können Ihre gulpfile.js öffnen und die generierte Zeile am Anfang der Datei löschen. Möglicherweise müssen Sie Ihre Lösung später auch neu laden, da bin ich mir nicht sicher.
Ich bin hierher gekommen, um nach einer Antwort zu suchen und habe gerade gemerkt, dass es eine neue Zeile in meinem gulpfile.js gibt. Ich habe nachgesehen, wann das begann und es stellt sich heraus, dass, als ich mein Azure SDK auf 2.7 aktualisiere und Visual Studio 2015 RTM benutze, habe ich diese Zeile in meine gulpfile eingefügt.
Wenn jemand einen Weg findet, dies über Visual Studio zu tun, anstatt generierte Zeilen in einer Datei zu hacken, würde ich es auch gerne wissen.
Tags und Links visual-studio-2015 gulp task-runner-explorer