Freigeben über

Rollforward der eigenständigen Runtimebereitstellung

  • Artikel

Eigenständige Anwendungsbereitstellungen von .NET Core enthalten sowohl die .NET Core-Bibliotheken als auch die .NET Core-Runtime. Beginnend mit .NET Core SDK 2.1 (Version 2.1.300) veröffentlicht eine eigenständige Anwendungsbereitstellung die höchste Patch-Runtime auf Ihrem Computer. dotnet publish wählt für eine eigenständige Bereitstellung standardmäßig die aktuellste installierte Version als Teil des SDK auf dem veröffentlichenden Computer aus. Dadurch kann Ihre bereitgestellte Anwendung während publish mit Problembehebungen der Sicherheit (und anderen Problembehebungen) ausgeführt werden. Die Anwendung muss erneut veröffentlicht werden, um einen neuen Patch abzurufen. Eigenständige Anwendungen werden durch Angabe von -r <RID> auf dem Befehl dotnet publish oder durch Angabe des Runtime-Bezeichners (RID) in der Projektdatei (CSPROJ/VBPROJ) oder der Befehlszeile erstellt.

Übersicht über Rollforward der Patchversion

restore, build und publish sind dotnet-Befehle, die separat ausgeführt werden können. Die Auswahl der Runtime ist Teil des Vorgangs restore, nicht publish oder build. Wenn Sie publish aufrufen, wird die neueste Patchversion ausgewählt. Wenn Sie publish mit dem Argument --no-restore aufrufen, erhalten Sie möglicherweise nicht die gewünschte Patchversion, da ein vorheriger restore-Vorgang möglicherweise nicht mit der neuen Richtlinie für die Veröffentlichung eigenständiger Anwendungen ausgeführt wurde. In diesem Fall wird ein Buildfehler mit einem Text generiert, der dem Folgenden ähnelt:

„Das Projekt wurde mit Microsoft.NETCore.App-Version 2.0.0 wiederhergestellt. Jedoch wird aufgrund der aktuellen Einstellungen stattdessen Version 2.0.6 verwendet. Um dieses Problem zu beheben, stellen Sie sicher, dass die gleichen Einstellungen für die Wiederherstellung und für nachfolgende Vorgänge wie Build- oder Veröffentlichungsvorgänge verwendet werden. Normalerweise tritt dieses Problem auf, wenn die RuntimeIdentifier-Eigenschaft während des Builds oder der Veröffentlichung festgelegt wird, jedoch nicht während der Wiederherstellung.“

Hinweis

restore und build können implizit als Teil eines anderen Befehls ausgeführt werden, z.B. publish. Wenn sie implizit als Teil eines anderen Befehls ausgeführt werden, wird zusätzlicher Kontext bereitgestellt, sodass die richtigen Artefakte erstellt werden. Wenn Sie publish mit einer Runtime ausführen (z.B. dotnet publish -r linux-x64), stellt restore Pakete implizit für die Linux-x64-Runtime wieder her. Wenn Sie restore explizit aufrufen, werden Runtime-Pakete nicht standardmäßig wiederhergestellt, da dieser Kontext nicht besteht.

Umgehen von restore während publish

Das Ausführen von restore als Teil des publish-Vorgangs kann für Ihr Szenario unangebracht sein. Führen Sie die folgenden Schritte aus, um restore während publish beim Erstellen eigenständiger Anwendungen zu vermeiden:

  • Legen Sie die Eigenschaft RuntimeIdentifiers auf eine durch Semikolons getrennte Liste aller zu veröffentlichenden RIDs fest.
  • Setzen Sie die TargetLatestRuntimePatch-Eigenschaft auf true.

No-restore-Argument mit dotnet publish-Optionen

Wenn Sie sowohl eigenständige Anwendungen und Framework-abhängige Anwendungen mit derselben Projektdatei erstellen und das Argument --no-restore mit dotnet publish verwenden möchten, wählen Sie eine der folgenden Optionen aus:

  1. Framework-abhängiges Verhalten bevorzugen. Wenn die Anwendung Framework-abhängig ist, ist dies das Standardverhalten. Wenn die Anwendung eigenständig ist und eine nicht gepatchte lokale Runtime (2.1.0) verwenden kann, legen Sie false für TargetLatestRuntimePatch in der Projektdatei fest.

  2. Eigenständiges Verhalten bevorzugen. Wenn die Anwendung eigenständig ist, ist dies das Standardverhalten. Wenn die Anwendung Framework-abhängig ist und den neuesten Patch erfordert, legen Sie true für TargetLatestRuntimePatch in der Projektdatei fest.

  3. Übernehmen Sie die explizite Kontrolle über die Runtime-Framework-Version, indem Sie für RuntimeFrameworkVersion die spezifische Patchversion in der Projektdatei festlegen.