Gibt es eine GAC-Entsprechung für .NET Core?

Question

Wie ich derzeit im vollständigen .NET Framework verstehe, wenn wir das Framework auf dem Computer installieren, stellt es die gesamte BCL auf dem Computer GAC. Auf diese Weise werden bei der Entwicklung einer Software mit .NET und der Bereitstellung auf diesem Computer die BCL-Assemblys verwendet, die im GAC verfügbar gemacht werden, wenn das .NET Framework selbst installiert wurde.

Nun, wie ich weiß CoreFX ist das Äquivalent des BCL für den neuen .NET Core. Der Hauptunterschied ist jedoch, dass wir in der project.json genau angeben können, welche Teile des CoreFX wir brauchen.

Meine Frage ist: Wenn wir .NET Core-Anwendungen bereitstellen, gibt es in der Produktionsumgebung ein GAC-Äquivalent? Gibt es also bei der Bereitstellung der auszuführenden App einen zentralen Ort auf dem Computer, an dem die App nachsehen wird, ob der gesamte CoreFX verfügbar ist?

Answer 1

Nein, es gibt nicht, nicht in der Art, wie Sie an die GAC denken. Core-Apps sollen voneinander isoliert sein, so dass Sie Patches erstellen können, ohne Angst davor zu haben, die anderen zu beeinflussen. Sie versenden alle Pakete, die Sie benötigen, mit der App.

Es gibt ein Wartungsverzeichnis, das zum Versenden von Updates für Core-Komponenten verwendet werden kann, es aber vollständig auslagern, nicht die Versionierung nebeneinander aktivieren und es nur für Updates verwenden soll, die über Microsoft Update geliefert werden.

Answer 2

bearbeiten 2017-09-01

Etwas analog den GAC, .NET Core 2.0 führt die "Runtime package store":

Beginnend mit .NET Core 2.0, ist es möglich, zu verpacken und Apps gegen eine bekannte Gruppe von Paketen bereitstellen, die in der Zielumgebung vorhanden sind. Die Vorteile sind schnellere Bereitstellungen, geringerer Speicherplatzverbrauch und eine verbesserte Startleistung in einigen Fällen.

Diese Funktion ist als Laufzeitpaketspeicher implementiert. Dies ist ein Verzeichnis auf dem Datenträger, in dem Pakete gespeichert werden (normalerweise unter/usr/local/share/dotnet/store unter macOS/Linux und C:/Programme/dotnet/unter Windows speichern).

---

Sie suchen eine "Rahmenabhängigen Einsatz". Von the docs:

• Rahmenabhängige Bereitstellung:

  Sie können zwei Arten von Implementierungen für .NET Core-Anwendungen erstellen. Wie der Name schon sagt, beruht Framework-Dependent Deployment (FDD) auf einer gemeinsamen systemweiten Version von .NET Core, die auf dem Zielsystem vorhanden sein soll. Da .NET Core bereits vorhanden ist, ist Ihre App auch zwischen Installationen von .NET Core portierbar. Ihre App enthält nur ihren eigenen Code und alle Abhängigkeiten von Drittanbietern, die sich außerhalb der .NET Core-Bibliotheken befinden. FDDs enthalten DLL-Dateien, die mit dem Dienstprogramm dotnet von der Befehlszeile aus gestartet werden können. Beispiel: dotnet app.dll führt eine Anwendung namens app.

• Unabhängige Bereitstellung. Im Gegensatz zu FDD ist eine eigenständige Implementierung (SCD) nicht darauf angewiesen, dass gemeinsame Komponenten auf dem Zielsystem vorhanden sind. Alle Komponenten, einschließlich der .NET Core-Bibliotheken und der .NET Core-Laufzeitumgebung, sind in der Anwendung enthalten und von anderen .NET Core-Anwendungen isoliert.SCDs enthalten eine ausführbare Datei (z. B. app.exe auf Windows-Plattformen für eine Anwendung mit dem Namen app), die eine umbenannte Version des plattformspezifischen .NET Core-Hosts ist, und eine DLL-Datei (z. B. app.dll), die die eigentliche Anwendung darstellt.