none
.NET Dlls auf SSD kopieren RRS feed

  • Frage

  • Hallo,

    ich habe eine Frage zur Installation des .NET-Frameworks. Soweit ich bisher herausgefunden habe, lässt sich dieses ja (fast) nicht auf einer anderen Festplatte außer C: installieren. Ich habe nun in meinem Rechner eine SSD als zweite Festplatte (D:). Darauf habe ich Visual Studio sowie alle Projektdateien installiert. Beim Kompilieren von Projektmappen werden ja aber recht häufig die .NET-Dlls gelesen (vor allem system.dll usw.), daher hätte ich diese auch gern auf der SSD. Ich hatte schon probiert, ein paar der am häufigsten verwendeten Dlls auf die SSD zu kopieren und den entsprechenden Pfad in der PATH-Umgebungsvariablen einzutragen, aber das hat leider nichts gebracht.

    Hat jemand eventuell noch eine andere Idee? Eine komplette Neuinstallation auf der SSD als Laufwerk C kommt z.Z. aus Zeit- und Platzgründen (nur 60GB) nicht in Frage, ebenso kein SSD-Caching.

    Viele Grüße

    WisDev

    Dienstag, 9. Oktober 2012 07:03

Antworten

  • Hallo WisDev,

    da das .NET Paket eng an das Betriebsystem gebunden ist, muss dieses immer in dem %systemroot% Ordner installiert werden. Die einzige Möglichkeit, diese Framework auf eine andere Festplatte zu installieren, wäre durch das Festlegen von sogenannten reparse points. Im Allgemeinen sind diese Weiterleitungen an anderen Ordnern oder Dateien im System. Ein kostenloses Tool dafür, sowie mehr Informationen darüber, können Sie unter [1] finden.

    [1] http://www.rekenwonder.com/linkmagic.htm  

    Wir hoffen, vielen Besuchern der MSDN Foren durch das Posten dieses Problems und einer möglichen Lösung weiterhelfen zu können.

    Viele Grüße,
    Hristo Valev
    MSDN Hotline für MSDN Online Deutschland

    Disclaimer:
    Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
    Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die MSDN Hotline: http://www.msdn-online.de/Hotline
    MSDN Hotline: Schnelle & kompetente Hilfe für Entwickler: kostenfrei!

    Es gelten für die MSDN Hotline und dieses Posting diese Nutzungsbedingungen, Hinweise zu MarkenzeichenInformationen zur Datensicherheit sowie die gesonderten Nutzungsbedingungen für die MSDN Hotline.

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:12
    Dienstag, 9. Oktober 2012 09:14
  • Hi WisDev,

    wenn ich es jetzt richtig im Kopf habe werden werden die dlls im GAC nur 1 mal in den Speicher geladen und dann von den Verschiedenen Programmen benutzt.

    Und ich denke, dass dein Speicher schneller ist als deine SSD.

    Die wirst hier also beim Compilieren wohl keinen Geschwindigkeitsvorteil erhalten.

    MFG

    Björn

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:13
    Dienstag, 9. Oktober 2012 17:15
  • Hallo,

    der Artikel ist veraltet, er bezieht sich noch auf die Verhältnisse von .NET 1.x.
    Wenn Du in die Registry in den Zweig schaust, siehst Du reichlich mehr (nur keinen direkten Pfad mehr).

    Mittlerweile ist der GAC aufgeteilt, siehe u. a. die Diskussion Warum benötigt das Framework 4 auf 64-Bit-Systemen 2 GB freien Speicherplatz?

    Zudem werden die Dateien aus dem GAC zwar vom Compiler, aber nicht fürs Kompilieren des Projekts verwendet. Dort wird %ProgramFiles%\Reference Assemblies wegen des Multi-Target Support (seit VS 2008) verwendet, da unterschiedliche Assemblies verwendet werden können. Die Pfade sind in der Registry zu finden unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup.

    Aber alle Verzeichnisse sind verdrahtet mit ihren Setups und verschiebt man sie wird es bei Aktualisierungen (Windows Update uam.) mit Sicherheit Probleme geben.

    Hristo Valevs Tipp mit einem Junction/Mount Point[1] wäre evtl. eine Möglichkeit, aber von meiner Seite nie probiert (ergo auf eigene Gefahr).

    Gruß Elmar

    [1] Da der genannte Link anscheinend nicht durchgängig erreichbar ist, einer aus der SQL Server Ecke: Using Mount Points with SQL Server. Im wesentlichen ebenso für andere Software gültig, am Ende findet sich zudem eine umfangreichere Link-Liste.

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:14
    Dienstag, 9. Oktober 2012 18:46
    Beantworter

Alle Antworten

  • Hi WisDev,

    die .NET dll sind im GAC installiert. Was du vor hast wird nicht funktionieren.

    MFG

    Björn

    Dienstag, 9. Oktober 2012 09:01
  • Hallo WisDev,

    da das .NET Paket eng an das Betriebsystem gebunden ist, muss dieses immer in dem %systemroot% Ordner installiert werden. Die einzige Möglichkeit, diese Framework auf eine andere Festplatte zu installieren, wäre durch das Festlegen von sogenannten reparse points. Im Allgemeinen sind diese Weiterleitungen an anderen Ordnern oder Dateien im System. Ein kostenloses Tool dafür, sowie mehr Informationen darüber, können Sie unter [1] finden.

    [1] http://www.rekenwonder.com/linkmagic.htm  

    Wir hoffen, vielen Besuchern der MSDN Foren durch das Posten dieses Problems und einer möglichen Lösung weiterhelfen zu können.

    Viele Grüße,
    Hristo Valev
    MSDN Hotline für MSDN Online Deutschland

    Disclaimer:
    Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
    Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die MSDN Hotline: http://www.msdn-online.de/Hotline
    MSDN Hotline: Schnelle & kompetente Hilfe für Entwickler: kostenfrei!

    Es gelten für die MSDN Hotline und dieses Posting diese Nutzungsbedingungen, Hinweise zu MarkenzeichenInformationen zur Datensicherheit sowie die gesonderten Nutzungsbedingungen für die MSDN Hotline.

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:12
    Dienstag, 9. Oktober 2012 09:14
  • Hi Palin,

    wenn die .NET dll im GAC liegen, müsste mir doch dieser gestern gefundene Link zum "Verschieben" des GAC weiterhelfen?

    http://msdn.microsoft.com/de-de/library/bb979545.aspx

    Oder jemand diesbzgl. Bedenken oder schlechte Erfahrungen gemacht?

    VG
    WisDev

    Dienstag, 9. Oktober 2012 10:25
  • Hi WisDev,

    wenn ich es jetzt richtig im Kopf habe werden werden die dlls im GAC nur 1 mal in den Speicher geladen und dann von den Verschiedenen Programmen benutzt.

    Und ich denke, dass dein Speicher schneller ist als deine SSD.

    Die wirst hier also beim Compilieren wohl keinen Geschwindigkeitsvorteil erhalten.

    MFG

    Björn

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:13
    Dienstag, 9. Oktober 2012 17:15
  • Hallo,

    der Artikel ist veraltet, er bezieht sich noch auf die Verhältnisse von .NET 1.x.
    Wenn Du in die Registry in den Zweig schaust, siehst Du reichlich mehr (nur keinen direkten Pfad mehr).

    Mittlerweile ist der GAC aufgeteilt, siehe u. a. die Diskussion Warum benötigt das Framework 4 auf 64-Bit-Systemen 2 GB freien Speicherplatz?

    Zudem werden die Dateien aus dem GAC zwar vom Compiler, aber nicht fürs Kompilieren des Projekts verwendet. Dort wird %ProgramFiles%\Reference Assemblies wegen des Multi-Target Support (seit VS 2008) verwendet, da unterschiedliche Assemblies verwendet werden können. Die Pfade sind in der Registry zu finden unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup.

    Aber alle Verzeichnisse sind verdrahtet mit ihren Setups und verschiebt man sie wird es bei Aktualisierungen (Windows Update uam.) mit Sicherheit Probleme geben.

    Hristo Valevs Tipp mit einem Junction/Mount Point[1] wäre evtl. eine Möglichkeit, aber von meiner Seite nie probiert (ergo auf eigene Gefahr).

    Gruß Elmar

    [1] Da der genannte Link anscheinend nicht durchgängig erreichbar ist, einer aus der SQL Server Ecke: Using Mount Points with SQL Server. Im wesentlichen ebenso für andere Software gültig, am Ende findet sich zudem eine umfangreichere Link-Liste.

    • Als Antwort markiert WisDev Mittwoch, 10. Oktober 2012 08:14
    Dienstag, 9. Oktober 2012 18:46
    Beantworter
  • Junctions funktionieren wunderbar, wobei ich nicht Teile des Systems ausgelagert habe, sondern nur die dicken Brocken.

    D.h. System wird auf der SSD komplett installiert. Dann wird mittels einer LiveCD (basierend auf Windows7 o.a.) die Inhalte der großen Verzeichnisse - vorallem Users aber auch Program Files und Program Files (x86) - auf die normale Platte geschoben. Dann richtest du die Junctions mit dem bei Windows 7 bei liegenden Kommandozeilentool mkllink ein. Wenn ich dich richtig verstanden habe, dann kannst du die SSD ja noch komplett verwenden. Die Daten auf der HDD musst du nicht einmal löschen. Die Programme, welche schnell laden sollen, müssen allerdings in einem weiteren Programs SSD Verzeichnis installiert werden.

    Wie Elmar schon sagte ohne Gewähr.

    Dienstag, 9. Oktober 2012 18:57
  • Also ich habe gestern mal den GAC auf die SSD verschoben. Danach musste ich VisualStudio2012 reparieren, da einige "ungewöhnliche" Fehlermeldungen kamen. Ich habe dann die Compilezeit von einem Projekt verglichen, sie ist von 20 auf 19 Sekunden gesunken - also praktische keine Verbesserung.

    Laut ProcessMonitor werden einige Files aus dem GAC (also jetzt von der SSD) gelesen, aber die Mehrzahl weiterhin aus c:\...Microsoft.NET... und eben auch system32 usw.

    Die Sache mit den Junctions klingt vernünftig, das würde ich aber erstmal nur auf einem Testsystem probieren. Da ich aber keines zur Verfügung habe und damit der Aufwand recht hoch wäre, werde ich mir wohl eher irgendwann eine größere SSD kaufen und dann alles (also Win, VS, Projektmappen) darauf installieren.

    Danke für alle Hinweise.

    WisDev

    Mittwoch, 10. Oktober 2012 08:23