Partager via

Magasin de packages de runtime

À compter de .NET Core 2.0, il est possible de empaqueter et de déployer des applications sur un ensemble connu de packages qui existent dans l’environnement cible. Les avantages sont des déploiements plus rapides, une utilisation inférieure de l’espace disque et des performances de démarrage améliorées dans certains cas.

Cette fonctionnalité est implémentée en tant que magasin de packages runtime, qui est un répertoire sur disque où les packages sont stockés (généralement à /usr/local/share/dotnet/store sur macOS/Linux et C :/Program Files/dotnet/store sur Windows). Sous ce répertoire, il existe des sous-répertoires pour les architectures et les frameworks cibles. La disposition des fichiers est similaire à la façon dont les ressources NuGet sont disposées sur le disque :

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

Un fichier manifeste cible répertorie les packages dans le magasin de packages runtime. Les développeurs peuvent cibler ce manifeste lors de la publication de leur application. Le manifeste cible est généralement fourni par le propriétaire de l’environnement de production ciblé.

Préparation d’un environnement d’exécution

L’administrateur d’un environnement d’exécution peut optimiser les applications pour des déploiements plus rapides et réduire l’espace disque utilisé en créant un magasin de packages d’exécution et le manifeste cible correspondant.

La première étape consiste à créer un manifeste de magasin de packages qui répertorie les packages qui composent le magasin de packages runtime. Ce format de fichier est compatible avec le format de fichier projet (csproj).

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

Exemple

L’exemple de manifeste de magasin de packages suivant (packages.csproj) est utilisé pour ajouter Newtonsoft.Json et Moq à un magasin de packages runtime :

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

Approvisionner le magasin de packages de runtime en exécutant dotnet store avec le manifeste de magasin de packages, le runtime et le framework :

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

Exemple

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

Vous pouvez passer plusieurs chemins de manifeste de magasin de packages cible à une seule commande dotnet store en répétant l’option et le chemin dans la commande.

Par défaut, la sortie de la commande est un répertoire de packages sous le sous-répertoire .dotnet/store du profil de l’utilisateur. Vous pouvez spécifier un autre emplacement à l’aide de l’option --output <OUTPUT_DIRECTORY> . Le répertoire racine du magasin contient le fichier manifeste cible artifact.xml. Ce fichier peut être mis à la disposition du téléchargement et être utilisé par les auteurs d’applications qui souhaitent cibler ce magasin lors de la publication.

Exemple

Le fichier artifact.xml suivant est généré après avoir exécuté l’exemple précédent. Notez qu’il Castle.Core s’agit d’une dépendance de Moq. Il est donc inclus automatiquement et apparaît dans le fichier manifeste artifacts.xml .

<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>

Publication d’une application par rapport à un manifeste cible

Si vous avez un fichier manifeste cible sur le disque, vous spécifiez le chemin d’accès au fichier lors de la publication de votre application avec la dotnet publish commande :

dotnet publish --manifest <PATH_TO_MANIFEST_FILE>

Exemple

dotnet publish --manifest manifest.xml

Vous déployez l’application publiée résultante dans un environnement avec les packages décrits dans le manifeste cible. L’échec de cette opération entraîne l’échec du démarrage de l’application.

Spécifiez plusieurs manifestes cibles lors de la publication d’une application en répétant l’option et le chemin d’accès (par exemple). --manifest manifest1.xml --manifest manifest2.xml Ainsi, l’application est épurée pour réunir les packages spécifiés dans les fichiers manifeste cibles fournis à la commande.

Si vous déployez une application avec une dépendance de manifeste présente dans le déploiement (l’assembly est présent dans le dossier bin ), le magasin de packages runtime n’est pas utilisé sur l’hôte pour cet assembly. L'assemblage du dossier bin est utilisé qu'il soit présent ou non dans le store de packages d'exécution sur l'hôte.

La version de la dépendance indiquée dans le manifeste doit correspondre à la version de la dépendance dans le magasin de packages runtime. Si vous avez une incompatibilité de version entre la dépendance dans le manifeste cible et la version qui existe dans le magasin de packages runtime et que l’application n’inclut pas la version requise du package dans son déploiement, l’application ne démarre pas. L’exception contient le nom du manifeste cible qui a appelé l’assembly du magasin de packages de runtime, ce qui vous permet de résoudre l’incompatibilité.

Lorsque le déploiement est réduit lors de la publication, seules les versions spécifiques des packages de manifeste que vous indiquez ne sont pas incluses dans la sortie publiée. Les packages aux versions indiquées doivent être présents sur l’hôte pour que l’application démarre.

Spécification de manifestes cibles dans le fichier projet

Une alternative à la spécification de manifestes cibles avec la dotnet publish commande consiste à les spécifier dans le fichier projet sous la forme d’une liste de chemins séparés par des points-virgules sous une <TargetManifestFiles> balise.

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

Spécifiez les manifestes cibles dans le fichier projet uniquement lorsque l’environnement cible de l’application est connu, par exemple pour les projets .NET Core. Ce n’est pas le cas pour les projets open source. Les utilisateurs d’un projet open source le déploient généralement dans différents environnements de production. Ces environnements de production ont généralement différents ensembles de packages préinstallés. Vous ne pouvez pas faire d’hypothèses sur le manifeste cible dans de tels environnements. Vous devez donc utiliser l’option --manifest .dotnet publish

magasin implicite ASP.NET Core (.NET Core 2.0 uniquement)

Le magasin implicite ASP.NET Core s’applique uniquement à ASP.NET Core 2.0. Nous recommandons vivement aux applications d’utiliser ASP.NET Core 2.1 et versions ultérieures, qui n’utilisent pas le magasin implicite. ASP.NET Core 2.1 et versions ultérieures utilisent l’infrastructure partagée.

Pour .NET Core 2.0, la fonctionnalité du magasin de packages runtime est utilisée implicitement par une application ASP.NET Core lorsque l’application est déployée en tant qu’application de déploiement dépendante du framework . Les cibles dans Microsoft.NET.Sdk.Web contiennent les manifestes référençant le magasin de packages implicite sur le système cible. En outre, toute application dépendante de l’infrastructure qui dépend du Microsoft.AspNetCore.All package génère une application publiée qui contient uniquement l’application et ses ressources, et non les packages répertoriés dans le Microsoft.AspNetCore.All métapackage. Il est supposé que ces packages sont présents sur le système cible.

Le magasin de packages runtime est installé sur l’hôte lorsque le Kit de développement logiciel (SDK) .NET est installé. D’autres programmes d’installation peuvent fournir le magasin de packages d’exécution, notamment les installations Zip/tarball du Kit de développement logiciel (SDK) .NET, apt-getRed Hat Yum, le bundle d’hébergement Windows Server .NET Core et les installations manuelles du magasin de packages runtime.

Lors du déploiement d’une application de déploiement dépendante du framework, assurez-vous que l’environnement cible a installé le Kit de développement logiciel (SDK) .NET. Si l’application est déployée dans un environnement qui n’inclut pas ASP.NET Core, vous pouvez désactiver le stockage implicite en définissant <PublishWithAspNetCoreTargetManifest> sur false dans le fichier de projet comme dans l’exemple suivant :

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

Remarque

Pour les applications de déploiement autonomes , il est supposé que le système cible ne contient pas nécessairement les packages de manifeste requis. Par conséquent, <PublishWithAspNetCoreTargetManifest> ne peut pas être défini true pour une application autonome.

Voir aussi

  • Last updated on