Share via

Runtime-pakketarchief

  • Artikel

Vanaf .NET Core 2.0 is het mogelijk om apps te verpakken en te implementeren op basis van een bekende set pakketten die aanwezig zijn in de doelomgeving. De voordelen zijn snellere implementaties, minder schijfruimtegebruik en verbeterde opstartprestaties in sommige gevallen.

Deze functie wordt geïmplementeerd als een runtime-pakketarchief, een map op schijf waarop pakketten worden opgeslagen (meestal op /usr/local/share/dotnet/store op macOS/Linux en C:/Program Files/dotnet/store in Windows). Onder deze map bevinden zich submappen voor architecturen en doelframeworks. De bestandsindeling is vergelijkbaar met de manier waarop NuGet-assets op schijf zijn ingedeeld:

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

Een doelmanifestbestand bevat de pakketten in het runtime-pakketarchief. Ontwikkelaars kunnen dit manifest richten bij het publiceren van hun app. Het doelmanifest wordt doorgaans geleverd door de eigenaar van de doelproductieomgeving.

Een runtime-omgeving voorbereiden

De beheerder van een runtime-omgeving kan apps optimaliseren voor snellere implementaties en minder schijfruimte gebruiken door een runtimepakketarchief en het bijbehorende doelmanifest te bouwen.

De eerste stap is het maken van een pakketarchiefmanifest waarin de pakketten worden vermeld die het runtime-pakketarchief vormen. Deze bestandsindeling is compatibel met de projectbestandsindeling (csproj).

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

Voorbeeld

Het volgende voorbeeldmanifest voor pakketopslag (packages.csproj) wordt gebruikt om een runtime-pakketarchief toe te voegen en Moq toe te voegenNewtonsoft.Json:

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

Richt het runtime-pakketarchief in door het pakketarchiefmanifest, de runtime en het framework van het pakketarchief uit te dotnet store voeren:

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

Voorbeeld

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

U kunt meerdere manifestpaden voor het doelpakketarchief doorgeven aan één dotnet store opdracht door de optie en het pad in de opdracht te herhalen.

Standaard is de uitvoer van de opdracht een pakketarchief onder de submap .dotnet/store van het profiel van de gebruiker. U kunt een andere locatie opgeven met behulp van de --output <OUTPUT_DIRECTORY> optie. De hoofdmap van het archief bevat een doelmanifest artifact.xml bestand. Dit bestand kan beschikbaar worden gesteld voor downloaden en worden gebruikt door app-auteurs die deze store willen targeten bij het publiceren.

Voorbeeld

Het volgende artifact.xml bestand wordt geproduceerd nadat het vorige voorbeeld is uitgevoerd. Houd er rekening mee dat Castle.Core dit een afhankelijkheid is van Moq, zodat deze automatisch wordt opgenomen en wordt weergegeven in het artifacts.xml manifestbestand.

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

Een app publiceren op basis van een doelmanifest

Als u een doelmanifestbestand op schijf hebt, geeft u het pad naar het bestand op bij het publiceren van uw app met de dotnet publish opdracht:

dotnet publish --manifest <PATH_TO_MANIFEST_FILE>

Voorbeeld

dotnet publish --manifest manifest.xml

U implementeert de resulterende gepubliceerde app in een omgeving met de pakketten die in het doelmanifest worden beschreven. Als u dit niet doet, kan de app niet worden gestart.

Geef meerdere doelmanifesten op bij het publiceren van een app door de optie en het pad (bijvoorbeeld --manifest manifest1.xml --manifest manifest2.xml) te herhalen. Wanneer u dit doet, wordt de app ingekort voor de samenvoeging van pakketten die zijn opgegeven in de doelmanifestbestanden die aan de opdracht zijn geleverd.

Als u een toepassing implementeert met een manifestafhankelijkheid die aanwezig is in de implementatie (de assembly bevindt zich in de bin-map ), wordt het runtime-pakketarchief niet gebruikt op de host voor die assembly. De assembly van de bin-map wordt gebruikt, ongeacht de aanwezigheid in het runtime-pakketarchief op de host.

De versie van de afhankelijkheid die in het manifest wordt aangegeven, moet overeenkomen met de versie van de afhankelijkheid in het runtime-pakketarchief. Als er een versie niet overeenkomt tussen de afhankelijkheid in het doelmanifest en de versie die bestaat in het runtimepakketarchief en de app niet de vereiste versie van het pakket in de implementatie bevat, kan de app niet worden gestart. De uitzondering bevat de naam van het doelmanifest dat wordt aangeroepen voor de assembly van het runtimepakketarchief, waarmee u problemen kunt oplossen die niet overeenkomen.

Wanneer de implementatie wordt ingekort bij het publiceren, worden alleen de specifieke versies van de manifestpakketten die u aangeeft, ingetrokken uit de gepubliceerde uitvoer. De pakketten op de aangegeven versies moeten aanwezig zijn op de host om de app te kunnen starten.

Doelmanifesten opgeven in het projectbestand

Een alternatief voor het opgeven van doelmanifesten met de dotnet publish opdracht is deze in het projectbestand op te geven als een door puntkomma's gescheiden lijst met paden onder een <TargetManifestFiles-tag> .

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

Geef de doelmanifesten in het projectbestand alleen op wanneer de doelomgeving voor de app bekend is, zoals voor .NET Core-projecten. Dit is niet het geval voor opensource-projecten. De gebruikers van een opensource-project implementeren het doorgaans in verschillende productieomgevingen. Deze productieomgevingen hebben over het algemeen verschillende sets pakketten die vooraf zijn geïnstalleerd. U kunt geen veronderstellingen maken over het doelmanifest in dergelijke omgevingen, dus u moet de --manifest optie van dotnet publish.

impliciete opslag van ASP.NET Core (alleen.NET Core 2.0)

Het impliciete ASP.NET Core-archief is alleen van toepassing op ASP.NET Core 2.0. We raden toepassingen ten zeerste aan ASP.NET Core 2.1 en hoger te gebruiken, die niet gebruikmaken van het impliciete archief. ASP.NET Core 2.1 en hoger gebruiken het gedeelde framework.

Voor .NET Core 2.0 wordt de functie runtimepakketarchief impliciet gebruikt door een ASP.NET Core-app wanneer de app wordt geïmplementeerd als een frameworkafhankelijke implementatie-app . De doelen in Microsoft.NET.Sdk.Web omvatten manifesten die verwijzen naar het impliciete pakketarchief op het doelsysteem. Bovendien resulteert elke frameworkafhankelijke app die afhankelijk is van het Microsoft.AspNetCore.All pakket, in een gepubliceerde app die alleen de app en de bijbehorende assets bevat en niet de pakketten die worden vermeld in de Microsoft.AspNetCore.All metapackage. Er wordt van uitgegaan dat deze pakketten aanwezig zijn op het doelsysteem.

Het runtime-pakketarchief wordt op de host geïnstalleerd wanneer de .NET SDK is geïnstalleerd. Andere installatieprogramma's kunnen de runtime-pakketopslag bieden, waaronder Zip/tarball-installaties van de .NET SDK, apt-getRed Hat Yum, de .NET Core Windows Server Hosting-bundel en handmatige runtime-pakketopslaginstallaties.

Zorg ervoor dat bij het implementeren van een frameworkafhankelijke implementatie-app de .NET SDK is geïnstalleerd in de doelomgeving. Als de app is geïmplementeerd in een omgeving die geen ASP.NET Core bevat, kunt u zich afmelden <voor de impliciete store door PublishWithAspNetNetTargetManifest> op te false geven dat is ingesteld op in het projectbestand, zoals in het volgende voorbeeld:

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

Notitie

Voor zelfstandige implementatie-apps wordt ervan uitgegaan dat het doelsysteem niet noodzakelijkerwijs de vereiste manifestpakketten bevat. PublishWithAspNetCoreTargetManifest> kan daarom niet worden ingesteld op true een zelfstandige app. <

Zie ook