Magazyn pakietu środowiska uruchomieniowego

Począwszy od oprogramowania .NET Core 2.0, można pakować i wdrażać aplikacje dla znanego zestawu pakietów, które istnieją w środowisku docelowym. Zalety to szybsze wdrożenia, mniejsze użycie miejsca na dysku i lepsza wydajność uruchamiania w niektórych przypadkach.

Ta funkcja jest zaimplementowana jako magazyn pakietów środowiska uruchomieniowego , czyli katalog na dysku, w którym są przechowywane pakiety (zazwyczaj w katalogu /usr/local/share/dotnet/store w systemie macOS/Linux i C:/Program Files/dotnet/store na Windows). W tym katalogu znajdują się podkatalogi dla architektur i platform docelowych. Układ pliku jest podobny do układu zasobów NuGet rozłożyć na dysku:

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

Docelowy plik manifestu wyświetla listę pakietów w magazynie pakietów środowiska uruchomieniowego. Deweloperzy mogą kierować do tego manifestu podczas publikowania aplikacji. Manifest docelowy jest zwykle dostarczany przez właściciela docelowego środowiska produkcyjnego.

Przygotowywanie środowiska uruchomieniowego

Administrator środowiska uruchomieniowego może zoptymalizować aplikacje pod kątem szybszych wdrożeń i mniejszego wykorzystania miejsca na dysku, budowania magazynu pakietów środowiska uruchomieniowego i odpowiedniego manifestu docelowego.

Pierwszym krokiem jest utworzenie manifestu magazynu pakietów, który zawiera listę pakietów tworzących magazyn pakietów środowiska uruchomieniowego. Ten format pliku jest zgodny z formatem pliku projektu (csproj).

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

Przykład

Poniższy przykład manifest magazynu pakietów (packages.csproj) służy do dodawania i Newtonsoft.Json do magazynu pakietów środowiska Moq uruchomieniowego:

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

Aprowizowanie magazynu pakietów środowiska uruchomieniowego przez wykonanie z manifestem, środowiskiem uruchomieniowym i platformą magazynu dotnet store pakietów:

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

Przykład

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

Można przekazać wiele ścieżek manifestu docelowego magazynu pakietów do pojedynczego dotnet store polecenia, powtarzając opcję i ścieżkę w poleceniu.

Domyślnie dane wyjściowe polecenia to magazyn pakietów w podkatalogu .dotnet/store profilu użytkownika. Możesz określić inną lokalizację przy użyciu --output <OUTPUT_DIRECTORY> opcji . Katalog główny magazynu zawiera docelowy manifest, artifact.xmlpliku. Ten plik może być dostępny do pobrania i używany przez autorów aplikacji, którzy chcą korzystać z tego sklepu podczas publikowania.

Przykład

Poniższy artifact.xml jest wytwarzanych po uruchomieniu poprzedniego przykładu. Należy pamiętać, że jest to zależność pliku , więc jest ona uwzględniana automatycznie i wyświetlana w Castle.Core Moq artifacts.xml manifestu.

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

Publikowanie aplikacji względem manifestu docelowego

Jeśli na dysku masz docelowy plik manifestu, możesz określić ścieżkę do pliku podczas publikowania aplikacji za pomocą dotnet publish polecenia :

dotnet publish --manifest <PATH_TO_MANIFEST_FILE>

Przykład

dotnet publish --manifest manifest.xml

Wynikowa opublikowana aplikacja jest wdrażana w środowisku, które zawiera pakiety opisane w manifeście docelowym. Nie można tego zrobić, powoduje, że nie można uruchomić aplikacji.

Określ wiele manifestów docelowych podczas publikowania aplikacji, powtarzając opcję i ścieżkę (na przykład --manifest manifest1.xml --manifest manifest2.xml ). Gdy to zrobisz, aplikacja zostanie przycinana do unii pakietów określonych w docelowych plikach manifestu dostarczanych do polecenia.

W przypadku wdrażania aplikacji z zależnością manifestu, która znajduje się we wdrożeniu (zestaw znajduje się w folderze bin), magazyn pakietów środowiska uruchomieniowego nie jest używany na hoście dla tego zestawu. Zestaw folderu bin jest używany niezależnie od jego obecności w magazynie pakietów środowiska uruchomieniowego na hoście.

Wersja zależności wskazanej w manifeście musi być dopasowana do wersji zależności w magazynie pakietów środowiska uruchomieniowego. Jeśli występuje niezgodność wersji między zależnością w manifeście docelowym a wersją, która istnieje w magazynie pakietów środowiska uruchomieniowego, a aplikacja nie zawiera wymaganej wersji pakietu we wdrożeniu, uruchomienie aplikacji nie powiedzie się. Wyjątek zawiera nazwę manifestu docelowego, który został wywołany dla zestawu magazynu pakietów środowiska uruchomieniowego, co ułatwia rozwiązywanie problemów z niezgodnością.

Gdy wdrożenie zostanie przycięte podczas publikowania, tylko określone wersje pakietów manifestu, które wskazujesz, zostaną zatrzymane z opublikowanych danych wyjściowych. Pakiety we wskazanych wersjach muszą być obecne na hoście, aby aplikacja została uruchamiana.

Określanie manifestów docelowych w pliku projektu

Alternatywą dla określania manifestów docelowych za pomocą polecenia jest określenie ich w pliku projektu jako rozdzielanej średnikami listy ścieżek dotnet publish pod <TargetManifestFiles> tagiem.

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

Określ manifesty docelowe w pliku projektu tylko wtedy, gdy środowisko docelowe aplikacji jest dobrze znane, na przykład w przypadku projektów .NET Core. Nie dotyczy to projektów typu open source. Użytkownicy projektu open source zwykle wdrażają go w różnych środowiskach produkcyjnych. Te środowiska produkcyjne zazwyczaj mają wstępnie zainstalowane różne zestawy pakietów. W takich środowiskach nie można wprowadzić założeń dotyczących manifestu docelowego, dlatego należy użyć --manifest opcji dotnet publish .

ASP.NET Core magazynu niejawnego (tylko program .NET Core 2.0)

Magazyn ASP.NET Core niejawny ma zastosowanie tylko do ASP.NET Core 2.0. Zdecydowanie zalecamy, aby aplikacje ASP.NET Core 2.1 i nowsze, które nie używają magazynu niejawnego. ASP.NET Core 2.1 i nowszych używają udostępnionej struktury.

W przypadku programu .NET Core 2.0 funkcja magazynu pakietów środowiska uruchomieniowego jest niejawnie używana przez aplikację ASP.NET Core, gdy aplikacja jest wdrażana jako aplikacja wdrażania zależna od struktury. Obiekty docelowe w Microsoft.NET.Sdk.Web programie zawierają manifesty odwołujące się do niejawnego magazynu pakietów w systemie docelowym. Ponadto każda aplikacja zależna od struktury, która zależy od pakietu, powoduje, że opublikowana aplikacja zawiera tylko aplikację i jej zasoby, a nie pakiety wymienione w Microsoft.AspNetCore.All Microsoft.AspNetCore.All metapakiecie. Zakłada się, że te pakiety są obecne w systemie docelowym.

Magazyn pakietów środowiska uruchomieniowego jest instalowany na hoście po zainstalowaniu zestawu .NET SDK. Inne instalatory mogą dostarczać magazyn pakietów środowiska uruchomieniowego, w tym instalacje zip/tarball zestawu .NET SDK, oprogramowania Red Hat Yum, pakietu hostingu serwera programu .NET Core Windows Server oraz ręczne instalacje magazynu pakietów środowiska apt-get uruchomieniowego.

Podczas wdrażania aplikacji wdrażania zależnej od platformy upewnij się, że w środowisku docelowym jest zainstalowany zestaw SDK platformy .NET. Jeśli aplikacja jest wdrażana w środowisku, które nie zawiera ASP.NET Core, możesz zrezygnować z niejawnego magazynu, określając w pliku projektu wartość , jak w poniższym <PublishWithAspNetCoreTargetManifest> false przykładzie:

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

Uwaga

W przypadku aplikacji do samodzielnego wdrażania zakłada się, że system docelowy nie musi zawierać wymaganych pakietów manifestu. W związku <PublishWithAspNetCoreTargetManifest> z tym nie można ustawić na wartość dla aplikacji true samodzielnej.

Zobacz też