Magazyn pakietu środowiska uruchomieniowego

  • Artykuł

Począwszy od platformy .NET Core 2.0, można pakować i wdrażać aplikacje względem znanego zestawu pakietów, które istnieją w środowisku docelowym. Korzyści są szybsze wdrożenia, mniejsze użycie miejsca na dysku i zwiększona wydajność uruchamiania w niektórych przypadkach.

Ta funkcja jest implementowana jako magazyn pakietów środowiska uruchomieniowego, który jest katalogiem na dysku, na którym są przechowywane pakiety (zazwyczaj w folderze /usr/local/share/dotnet/store w systemach macOS/Linux i C:/Program Files/dotnet/store w systemie Windows). W tym katalogu znajdują się podkatalogi architektur i platform docelowych. Układ pliku jest podobny do sposobu, w jaki zasoby NuGet są rozmieszczone na dysku:

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

Docelowy plik manifestu zawiera listę pakietów w magazynie pakietów środowiska uruchomieniowego. Deweloperzy mogą kierować ten manifest podczas publikowania aplikacji. Manifest docelowy jest zwykle udostępniany 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 miejsca na dysku, tworząc magazyn pakietów środowiska uruchomieniowego i odpowiedni manifest docelowy.

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

Następujący przykładowy manifest magazynu pakietów (packages.csproj) służy do dodawania Newtonsoft.Json i Moq do magazynu pakietów środowiska uruchomieniowego:

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

Aprowizuj magazyn pakietów środowiska uruchomieniowego, wykonując polecenie za pomocą dotnet store manifestu magazynu pakietów, środowiska uruchomieniowego i platformy:

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

Przykład

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

Możesz przekazać wiele ścieżek manifestu magazynu pakietów docelowych do jednego 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 plik manifestu docelowego artifact.xml . Ten plik można udostępnić do pobrania i być używany przez autorów aplikacji, którzy chcą kierować do tego sklepu podczas publikowania.

Przykład

Poniższy plik artifact.xml jest generowany po uruchomieniu poprzedniego przykładu. Należy pamiętać, że Castle.Core jest to zależność Moqklasy , dlatego jest ona uwzględniana automatycznie i pojawia się w pliku manifestu 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>

Publikowanie aplikacji względem manifestu docelowego

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

dotnet publish --manifest <PATH_TO_MANIFEST_FILE>

Przykład

dotnet publish --manifest manifest.xml

Wynikowa opublikowana aplikacja jest wdrażana w środowisku zawierającym pakiety opisane w manifeście docelowym. Nie można to zrobić, co powoduje niepowodzenie uruchomienia 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 przycięta do unii pakietów określonych w docelowych plikach manifestu dostarczonych do polecenia.

W przypadku wdrożenia 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ć zgodna z wersją zależności w magazynie pakietów środowiska uruchomieniowego. Jeśli masz 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 wywoływanego dla zestawu magazynu pakietów środowiska uruchomieniowego, co ułatwia rozwiązywanie problemów z niezgodnością.

Po przycinaniu wdrożenia podczas publikowania tylko określone wersje wskazywanych pakietów manifestu są wstrzymane z opublikowanych danych wyjściowych. Aby można było uruchomić aplikację, pakiety w wskazanych wersjach muszą znajdować się na hoście.

Określanie manifestów docelowych w pliku projektu

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

<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 platformy .NET Core. Tak nie jest w przypadku projektów open source. Użytkownicy projektu open source zazwyczaj wdrażają go w różnych środowiskach produkcyjnych. Te środowiska produkcyjne zazwyczaj mają różne zestawy wstępnie zainstalowanych pakietów. Nie można założyć założeń dotyczących manifestu docelowego w takich środowiskach, dlatego należy użyć --manifest opcji dotnet publish.

ASP.NET Core niejawny magazyn (tylko platforma.NET Core 2.0)

Niejawny magazyn ASP.NET Core dotyczy tylko ASP.NET Core 2.0. Zdecydowanie zalecamy, aby aplikacje używały ASP.NET Core 2.1 i nowszych, które nie korzystają z niejawnego magazynu. ASP.NET Core 2.1 lub nowszym używają struktury udostępnionej.

W przypadku platformy .NET Core 2.0 funkcja magazynu pakietów środowiska uruchomieniowego jest używana niejawnie przez aplikację ASP.NET Core, gdy aplikacja jest wdrażana jako aplikacja zależna od platformy. Obiekty docelowe w programie Microsoft.NET.Sdk.Web obejmują 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 Microsoft.AspNetCore.All pakietu, powoduje opublikowanie aplikacji zawierającej tylko aplikację i jej zasoby, a nie pakiety wymienione w Microsoft.AspNetCore.All metapakiecie. Zakłada się, że te pakiety znajdują się w systemie docelowym.

Magazyn pakietów środowiska uruchomieniowego jest instalowany na hoście po zainstalowaniu zestawu SDK platformy .NET. Inne instalatory mogą zapewnić magazyn pakietów środowiska uruchomieniowego, w tym instalacje zip/tarball zestawu .NET SDK, apt-get, Red Hat Yum, pakiet hostingu systemu Windows Server platformy .NET Core i instalacje ręcznego magazynu pakietów środowiska uruchomieniowego.

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

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

Uwaga

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

Zobacz też