Freigeben über

Laufzeitpaketspeicher

Ab .NET Core 2.0 ist es möglich, Apps für eine bekannte Gruppe von Paketen zu packen und bereitzustellen, die in der Zielumgebung vorhanden sind. Die Vorteile sind schnellere Bereitstellungen, geringere Speicherplatznutzung und verbesserte Startleistung in einigen Fällen.

Dieses Feature wird als Laufzeitpaketspeicher implementiert, bei dem es sich um ein Verzeichnis auf dem Datenträger handelt, in dem Pakete gespeichert werden (in der Regel unter /usr/local/share/dotnet/store unter macOS/Linux und C:/Program Files/dotnet/store unter Windows). Unter diesem Verzeichnis gibt es Unterverzeichnisse für Architekturen und Zielframeworks. Das Dateilayout ähnelt der Art und Weise, wie NuGet-Ressourcen auf dem Datenträger angeordnet werden:

\dotnet
    \store
        \x64
            \netcoreapp2.0
                \microsoft.applicationinsights
                \microsoft.aspnetcore
                ...
        \x86
            \netcoreapp2.0
                \microsoft.applicationinsights
                \microsoft.aspnetcore
                ...

Eine Zielmanifestdatei listet die Pakete im Laufzeitpaketspeicher auf. Entwickler können dieses Manifest beim Veröffentlichen ihrer App als Ziel festlegen. Das Zielmanifest wird in der Regel vom Besitzer der zielbezogenen Produktionsumgebung bereitgestellt.

Vorbereiten einer Laufzeitumgebung

Der Administrator einer Laufzeitumgebung kann Apps für schnellere Bereitstellungen und eine geringere Speicherplatznutzung optimieren, indem ein Laufzeitpaketspeicher und das entsprechende Zielmanifest erstellt werden.

Der erste Schritt besteht darin, ein Paketspeichermanifest zu erstellen, das die Pakete auflistet, die den Laufzeitpaketspeicher verfassen. Dieses Dateiformat ist mit dem Projektdateiformat (csproj) kompatibel.

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="NUGET_PACKAGE" Version="VERSION" />
    <!-- Include additional packages here -->
  </ItemGroup>
</Project>

Beispiel

Das folgende Beispiel für das Paketspeichermanifest (packages.csproj) wird verwendet, um Newtonsoft.Json und Moq zu einem Laufzeitpaketspeicher hinzuzufügen.

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
    <PackageReference Include="Moq" Version="4.7.63" />
  </ItemGroup>
</Project>

Stellen Sie den Laufzeitpaketspeicher bereit, indem Sie das Paketspeichermanifest, die Laufzeit und das Framework ausführen dotnet store :

dotnet store --manifest <PATH_TO_MANIFEST_FILE> --runtime <RUNTIME_IDENTIFIER> --framework <FRAMEWORK>

Beispiel

dotnet store --manifest packages.csproj --runtime win-x64 --framework netcoreapp2.0 --framework-version 2.0.0

Sie können mehrere Zielpaketspeichermanifestpfade an einen einzelnen dotnet store Befehl übergeben, indem Sie die Option und den Pfad im Befehl wiederholen.

Standardmäßig ist die Ausgabe des Befehls ein Paketspeicher, der sich im Unterverzeichnis .dotnet/store des Benutzerprofils befindet. Sie können einen anderen Speicherort mithilfe der --output <OUTPUT_DIRECTORY> Option angeben. Das Stammverzeichnis des Speichers enthält die Zielmanifestdatei artifact.xml. Diese Datei kann zum Herunterladen zur Verfügung gestellt und von App-Autoren verwendet werden, die diesen Store beim Veröffentlichen als Ziel verwenden möchten.

Beispiel

Die folgende artifact.xml Datei wird nach dem Ausführen des vorherigen Beispiels erstellt. Beachten Sie, dass Castle.Core eine Abhängigkeit von Moq ist, weshalb es automatisch eingeschlossen wird und in der artifacts.xml Manifestdatei angezeigt wird.

<StoreArtifacts>
  <Package Id="Newtonsoft.Json" Version="10.0.3" />
  <Package Id="Castle.Core" Version="4.1.0" />
  <Package Id="Moq" Version="4.7.63" />
</StoreArtifacts>

Veröffentlichen einer App mit einem Zielmanifest

Wenn Sie über eine Zielmanifestdatei auf dem Datenträger verfügen, geben Sie den Pfad zu der Datei an, wenn Sie Ihre App mit dem dotnet publish Befehl veröffentlichen:

dotnet publish --manifest <PATH_TO_MANIFEST_FILE>

Beispiel

dotnet publish --manifest manifest.xml

Sie stellen die resultierende veröffentlichte App in einer Umgebung bereit, in der die im Zielmanifest beschriebenen Pakete enthalten sind. Wenn sie dies nicht tun, führt dies dazu, dass die App nicht gestartet werden kann.

Geben Sie beim Veröffentlichen einer App mehrere Zielmanifeste an, indem Sie die Option und den Pfad wiederholen (z. B --manifest manifest1.xml --manifest manifest2.xml. ). Wenn Sie dies tun, wird die App für die Vereinigungsmenge der Pakete zugeschnitten, die in den für den Befehl bereitgestellten Zielmanifestdateien angegeben werden.

Wenn Sie eine Anwendung mit einer Manifestabhängigkeit bereitstellen, die in der Bereitstellung vorhanden ist (die Assembly ist im Bin-Ordner vorhanden), wird der Laufzeitpaketspeicher nicht auf dem Host für diese Assembly verwendet . Die bin-Ordnerstruktur wird unabhängig von dessen Anwesenheit im Laufzeitpaketspeicher auf dem Host verwendet.

Die im Manifest angegebene Version der Abhängigkeit muss mit der Version der Abhängigkeit im Laufzeitpaketspeicher übereinstimmen. Wenn eine Versionskonflikt zwischen der Abhängigkeit im Zielmanifest und der im Laufzeitpaketspeicher vorhandenen Version vorliegt und die App nicht die erforderliche Version des Pakets in der Bereitstellung enthält, kann die App nicht gestartet werden. Die Ausnahme enthält den Namen des Zielmanifests, das die Assembly im Laufzeitpaketspeicher aufgerufen hat. Das hilft Ihnen bei der Behebung des Konflikts.

Wenn die Bereitstellung bei der Veröffentlichung gekürzt ist, werden nur die spezifischen Versionen der Manifestpakete, die Sie angeben, aus der veröffentlichten Ausgabe zurückbehalten. Die Pakete in den angegebenen Versionen müssen auf dem Host vorhanden sein, damit die App gestartet werden kann.

Festlegen von Zielmanifesten in der Projektdatei

Eine Alternative zum Angeben von Zielmanifesten mit dem dotnet publish Befehl besteht darin, sie in der Projektdatei als durch Semikolons getrennte Liste von Pfaden unter einem <TargetManifestFiles-Tag> anzugeben.

<PropertyGroup>
  <TargetManifestFiles>manifest1.xml;manifest2.xml</TargetManifestFiles>
</PropertyGroup>

Geben Sie die Zielmanifeste in der Projektdatei nur an, wenn die Zielumgebung für die App bekannt ist, z. B. für .NET Core-Projekte. Dies ist nicht der Fall für Open-Source-Projekte. Die Benutzer eines Open-Source-Projekts stellen es in der Regel in verschiedenen Produktionsumgebungen bereit. Diese Produktionsumgebungen verfügen in der Regel über unterschiedliche Pakete, die vorinstalliert sind. Sie können in solchen Umgebungen keine Annahmen über das Zielmanifest treffen, daher sollten Sie die Option --manifest von dotnet publish verwenden.

ASP.NET Core impliziter Speicher (nur .NET Core 2.0)

Der implizite ASP.NET Core-Speicher gilt nur für ASP.NET Core 2.0. Es wird dringend empfohlen, dass Anwendungen ASP.NET Core 2.1 und höher verwenden, was nicht den impliziten Speicher verwendet. ASP.NET Core 2.1 und höher verwendet das freigegebene Framework.

Für .NET Core 2.0 wird das Laufzeitpaketspeicherfeature implizit von einer ASP.NET Core-App verwendet, wenn die App als frameworkabhängige Bereitstellungs-App bereitgestellt wird. Die Ziele umfassen Manifeste in Microsoft.NET.Sdk.Web, die auf den impliziten Paketspeicher des Zielsystems verweisen. Darüber hinaus führt jede frameworkabhängige App, die von dem Microsoft.AspNetCore.All Paket abhängt, zu einer veröffentlichten App, die nur die App und deren Ressourcen enthält, und nicht die pakete, die Microsoft.AspNetCore.All im Metapaket aufgeführt sind. Es wird davon ausgegangen, dass diese Pakete im Zielsystem vorhanden sind.

Der Laufzeitpaketspeicher wird auf dem Host installiert, wenn das .NET SDK installiert ist. Andere Installationsprogramme stellen möglicherweise einen Runtimepaketspeicher bereit, beispielsweise die Zip-/Tarball-Installationen des .NET SDK, apt-get, Red Hat Yum, das .NET Core Windows Server-Hostingpaket und manuelle Installationen des Runtimepaketspeichers.

Stellen Sie beim Bereitstellen einer frameworkabhängigen Bereitstellungs-App sicher, dass die Zielumgebung das .NET SDK installiert hat. Wenn die App für eine Umgebung bereitgestellt wird, die ASP.NET Core nicht enthält, können Sie den impliziten Speicher deaktivieren, indem Sie <PublishWithAspNetCoreTargetManifest> angeben, das in der Projektdatei wie im folgenden Beispiel auf false festgelegt ist:

<PropertyGroup>
  <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

Hinweis

Bei eigenständigen Bereitstellungs-Apps wird davon ausgegangen, dass das Zielsystem nicht unbedingt die erforderlichen Manifestpakete enthält. Deshalb kann <PublishWithAspNetCoreTargetManifest> für eine App mit eigenständiger Bereitstellung nicht auf true festgelegt werden.

Siehe auch