Was ist der Unterschied zwischen TargetFramework und RuntimeFrameworkVersion?

Das TargetFramework wird von NuGet verwendet, um Abhängigkeiten aufzulösen und die Assets zu bestimmen, die zum Kompilieren und Erstellen der Anwendung verwendet werden sollen. (Hinter den Kulissen kommen ein paar weitere Eigenschaften wie TargetFrameworkMoniker und TargetFrameworkVersion ins Spiel, aber das SDK abstrahiert es zu einem einfacheren TargetFramework für Frameworks, die es kennt).

RuntimeFrameworkVersion ist spezifisch für .NET Core / netcoreapp . Das SDK fügt eine Abhängigkeit von Microsoft.NETCore.App für die Version ein, für die RuntimeFrameworkVersion festgelegt ist, oder verwendet die neueste Version, die es für .NET Core & lt; kennt. 2.0. Die aufgelöste Version wird dann in die runtimeconfig.json -Datei für den .NET Core-Hostframework-Resolver geschrieben, um die Version des zu ladenden freigegebenen Frameworks aufzulösen (z. B. & gt; .NET Core 1.1.4-Laufzeit).

Der Grund, warum Sie 1.1.* für netcoreapp1.0 verwenden können, ist, dass das NuGet-Paket tatsächlich die erforderlichen Assets zum Erstellen von .NET Core 1.0. * - Anwendungen enthält. Das Tooling weiß das jedoch nicht, daher erhalten Sie eine .NET Core 1.0 App, die aber vom 1.1-Framework geladen wird, da dies in der Datei runtimeconfig.json endet.

Der wichtige Unterschied ist:

• Es spielt nur für in sich abgeschlossene ausführbare Dateien eine Rolle, welche Version von Microsoft.NETCore.App verwendet wird.
  • Dieses Paket zieht das vollständige Framework mit der gewünschten Version ein, wenn Sie eine eigenständige Veröffentlichung durchführen (z. B. dotnet publish -r win7-x64 )
  • Wenn Sie eine Anwendung ausführen, die für 1.0.3 erstellt wurde, aber die 1.0.5 runtime installiert hat, wird automatisch die 1.0.5 runtime verwendet.
  • Wenn Sie RuntimeFrameworkVersion nicht setzen und eine neue Version des SDK veröffentlicht wird, die neue Patch-Versionen von .NET Core kennt, wird automatisch die neueste Version verwendet. Wenn Sie die Version explizit festlegen, sind Sie möglicherweise nicht auf dem neuesten Stand, ohne die Projektdatei zu bearbeiten.
• Die RuntimeFrameworkVersion ist auch die minimale Laufzeit, die die Anwendung lädt - wenn Sie sie auf 1.0.4 setzen und versuchen, auf einer Maschine zu laufen, auf der nur 1.0.3 installiert ist, wird die Anwendung nicht gestartet, es sei denn, Sie bearbeiten die runtimeconfig.json Datei.
• RuntimeFrameworkVersion kann auf eine unverankerte Version gesetzt werden, was beim Targeting von Vorschauversionen oder täglichen Builds, z. 2.1.0-preview1-* würde in die neueste preview1 Version aufgelöst, die in den konfigurierten NuGet-Feeds verfügbar ist.

Abgesehen von diesen gibt es nur ein paar Gründe, um mit einer höheren Version von Microsoft.NETCore.App zu bauen, wie ein Build-Bugfix für die DiaSymReader -Komponente.

In .NET Core 2.0 ist die Version von RuntimeFrameworkVersion immer 2.0.0 für "portable Anwendungen" (nicht eigenständig), da die Implementierung des Frameworks nicht mehr durch die Abhängigkeiten von Microsoft.NETCore.App und Dieses NuGet-Paket wird nur verwendet, um Referenz-Assemblies für die Kompilierung bereitzustellen.

In den Dokumenten sollten Sie nur runtimeframeworkversion

Wenn Sie beim Targeting von .NET Core eine bestimmte Version der Laufzeitumgebung benötigen, sollten Sie die Eigenschaft in Ihrem Projekt verwenden (z. B. 1.0.4), anstatt auf das Metapaket zu verweisen.

Ссылка