Rollforward der eigenständigen Runtimebereitstellung

.NET Core eigenständige Anwendungsbereitstellungen umfassen sowohl die .NET Core-Bibliotheken als auch die .NET Core-Laufzeit. 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. Auf diese Weise kann Ihre bereitgestellte Anwendung mit Sicherheitskorrekturen (und anderen Korrekturen) ausgeführt werden, die während publish verfügbar sind. Die Anwendung muss erneut veröffentlicht werden, um einen neuen Patch zu erhalten. Eigenständige Anwendungen werden durch Angeben des -r <RID> Befehls oder durch Angeben dotnet publish des Laufzeitbezeichners (RID) in der Projektdatei (csproj / vbproj) oder in der Befehlszeile erstellt.

Übersicht über Rollforward der Patchversion

restoreund buildpublish sind dotnet Befehle, die separat ausgeführt werden können. Die Laufzeitauswahl ist Teil des restore Vorgangs, nicht publish oder build. Wenn Sie anrufen publish, wird die neueste Patchversion ausgewählt. Wenn Sie publish mit dem --no-restore Argument aufrufen, erhalten Sie möglicherweise nicht die gewünschte Patch-Version, da ein vorheriges restore möglicherweise nicht mit der neuen eigenständigen Anwendungspublikationsrichtlinie ausgeführt wurde. In diesem Fall wird ein Buildfehler mit Text generiert, der den folgenden ähnelt:

"Das Projekt wurde mit Microsoft.NETCore.App Version 2.0.0 wiederhergestellt, aber mit den aktuellen Einstellungen wird stattdessen Version 2.0.6 verwendet. Um dieses Problem zu beheben, stellen Sie sicher, dass dieselben Einstellungen für die Wiederherstellung und für nachfolgende Vorgänge wie Build oder Veröffentlichung verwendet werden. In der Regel kann dieses Problem auftreten, wenn die RuntimeIdentifier-Eigenschaft während des Builds oder veröffentlichen, aber nicht während der Wiederherstellung festgelegt wird."

Hinweis

restore und build können implizit als Teil eines anderen Befehls ausgeführt werden, wie publish. Wenn sie implizit als Teil eines anderen Befehls ausgeführt werden, werden sie mit zusätzlichem 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 standardmäßig keine Laufzeitpakete wiederhergestellt, da der Kontext fehlt.

Umgehen von restore während publish

Die Ausführung von restore als Teil der publish Operation könnte in Ihrem Szenario unerwünscht sein. Führen Sie die folgenden Schritte aus, um restore während publish beim Erstellen eigenständiger Anwendungen zu vermeiden:

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

No-restore-Argument mit dotnet publish-Optionen

Wenn Sie sowohl eigenständige Anwendungen als auch frameworkabhängige Anwendungen mit derselben Projektdatei erstellen möchten und das --no-restore Argument mit dotnet publishverwenden möchten, wählen Sie eine der folgenden Optionen aus:

1. Framework-abhängiges Verhalten bevorzugen. Wenn die Anwendung frameworkabhängig ist, ist dies das Standardverhalten. Wenn die Anwendung eigenständig ist und eine nicht gepatchte lokale 2.1.0-Laufzeit verwenden kann, setzen Sie TargetLatestRuntimePatch auf false in der Projektdatei.

2. Eigenständiges Verhalten bevorzugen. Wenn die Anwendung eigenständig ist, ist dies das Standardverhalten. Wenn die Anwendung frameworkabhängig ist und den neuesten Patch benötigt, setzen Sie TargetLatestRuntimePatch auf true in der Projektdatei.

3. Übernehmen Sie die explizite Kontrolle über die Laufzeitframeworkversion, indem Sie RuntimeFrameworkVersion auf die spezifische Patchversion in der Projektdatei festlegen.