Armazenamento de pacotes de tempo de execução
A partir do .NET Core 2.0, é possível empacotar e implantar aplicativos em um conjunto conhecido de pacotes existentes no ambiente de destino. Os benefícios são implantações mais rápidas, menor uso de espaço em disco e melhor desempenho de inicialização em alguns casos.
Este recurso é implementado como um armazenamento de pacotes de tempo de execução, que é um diretório no disco onde os pacotes são armazenados (normalmente em /usr/local/share/dotnet/store no macOS/Linux e C:/Program Files/dotnet/store no Windows). Neste diretório, há subdiretórios para arquiteturas e estruturas de destino. O layout do arquivo é semelhante à maneira como os ativos do NuGet são dispostos no disco:
\dotnet
\store
\x64
\netcoreapp2.0
\microsoft.applicationinsights
\microsoft.aspnetcore
...
\x86
\netcoreapp2.0
\microsoft.applicationinsights
\microsoft.aspnetcore
...
Um arquivo de manifesto de destino lista os pacotes no repositório de pacotes de tempo de execução. Os desenvolvedores podem direcionar esse manifesto ao publicar seu aplicativo. O manifesto de destino é normalmente fornecido pelo proprietário do ambiente de produção de destino.
Preparando um ambiente de tempo de execução
O administrador de um ambiente de tempo de execução pode otimizar aplicativos para implantações mais rápidas e menor uso de espaço em disco criando um repositório de pacotes de tempo de execução e o manifesto de destino correspondente.
A primeira etapa é criar um manifesto de armazenamento de pacotes que liste os pacotes que compõem o repositório de pacotes de tempo de execução. Este formato de arquivo é compatível com o formato de arquivo de projeto (csproj).
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="NUGET_PACKAGE" Version="VERSION" />
<!-- Include additional packages here -->
</ItemGroup>
</Project>
Exemplo
O seguinte exemplo de manifesto de armazenamento de pacotes (packages.csproj) é usado para adicionar Newtonsoft.Json e Moq para um repositório de pacotes de tempo de execução:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
<PackageReference Include="Moq" Version="4.7.63" />
</ItemGroup>
</Project>
Provisione o repositório de pacotes de tempo de execução executando dotnet store com o manifesto, o tempo de execução e a estrutura do repositório de pacotes:
dotnet store --manifest <PATH_TO_MANIFEST_FILE> --runtime <RUNTIME_IDENTIFIER> --framework <FRAMEWORK>
Exemplo
dotnet store --manifest packages.csproj --runtime win-x64 --framework netcoreapp2.0 --framework-version 2.0.0
Você pode passar vários caminhos de manifesto do repositório de pacotes de destino para um único dotnet store comando repetindo a opção e o caminho no comando.
Por padrão, a saída do comando é um armazenamento de pacotes no subdiretório .dotnet/store do perfil do usuário. Você pode especificar um local diferente usando a --output <OUTPUT_DIRECTORY> opção. O diretório raiz do repositório contém um manifesto de destino artifact.xml arquivo. Este arquivo pode ser disponibilizado para download e ser usado por autores de aplicativos que desejam segmentar esta loja ao publicar.
Exemplo
O seguinte arquivo artifact.xml é produzido após a execução do exemplo anterior. Observe que Castle.Core é uma dependência do , portanto, ele é incluído automaticamente e aparece no arquivo de Moqmanifesto 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>
Publicando um aplicativo em relação a um manifesto de destino
Se você tiver um arquivo de manifesto de destino no disco, especifique o caminho para o arquivo ao publicar seu aplicativo com o dotnet publish comando:
dotnet publish --manifest <PATH_TO_MANIFEST_FILE>
Exemplo
dotnet publish --manifest manifest.xml
Você implanta o aplicativo publicado resultante em um ambiente que tem os pacotes descritos no manifesto de destino. Se não o fizer, a aplicação não será iniciada.
Especifique vários manifestos de destino ao publicar um aplicativo repetindo a opção e o caminho (por exemplo, --manifest manifest1.xml --manifest manifest2.xml). Quando você faz isso, o aplicativo é cortado para a união de pacotes especificados nos arquivos de manifesto de destino fornecidos ao comando.
Se você implantar um aplicativo com uma dependência de manifesto presente na implantação (o assembly está presente na pasta bin ), o armazenamento de pacotes de tempo de execução não será usado no host para esse assembly. O assembly da pasta bin é usado independentemente de sua presença no armazenamento de pacotes de tempo de execução no host.
A versão da dependência indicada no manifesto deve corresponder à versão da dependência no repositório de pacotes de tempo de execução. Se você tiver uma incompatibilidade de versão entre a dependência no manifesto de destino e a versão existente no repositório de pacotes de tempo de execução e o aplicativo não incluir a versão necessária do pacote em sua implantação, o aplicativo não será iniciado. A exceção inclui o nome do manifesto de destino que chamou o assembly do repositório de pacotes de tempo de execução, o que ajuda a solucionar a incompatibilidade.
Quando a implantação é cortada na publicação, somente as versões específicas dos pacotes de manifesto que você indica são retidas da saída publicada. Os pacotes nas versões indicadas devem estar presentes no host para que o aplicativo seja iniciado.
Especificando manifestos de destino no arquivo de projeto
Uma alternativa para especificar manifestos de destino com o dotnet publish comando é especificá-los no arquivo de projeto como uma lista de caminhos separados por ponto-e-vírgula sob uma <marca TargetManifestFiles> .
<PropertyGroup>
<TargetManifestFiles>manifest1.xml;manifest2.xml</TargetManifestFiles>
</PropertyGroup>
Especifique os manifestos de destino no arquivo de projeto somente quando o ambiente de destino do aplicativo for bem conhecido, como para projetos .NET Core. Este não é o caso de projetos de código aberto. Os usuários de um projeto de código aberto normalmente o implantam em diferentes ambientes de produção. Esses ambientes de produção geralmente têm diferentes conjuntos de pacotes pré-instalados. Você não pode fazer suposições sobre o manifesto de destino em tais ambientes, então você deve usar a --manifest opção de dotnet publish.
Armazenamento implícito do ASP.NET Core (somente .NET Core 2.0)
O armazenamento implícito do ASP.NET Core aplica-se apenas ao ASP.NET Core 2.0. É altamente recomendável que os aplicativos usem o ASP.NET Core 2.1 e posterior, que não usa o armazenamento implícito. ASP.NET Core 2.1 e posteriores usam a estrutura compartilhada.
Para o .NET Core 2.0, o recurso de armazenamento de pacotes de tempo de execução é usado implicitamente por um aplicativo ASP.NET Core quando o aplicativo é implantado como um aplicativo de implantação dependente da estrutura. Os destinos em Microsoft.NET.Sdk.Web incluem manifestos que fazem referência ao armazenamento de pacote implícito no sistema de destino. Além disso, qualquer aplicativo dependente da estrutura que dependa do Microsoft.AspNetCore.All pacote resulta em um aplicativo publicado que contém apenas o aplicativo e seus ativos e não os pacotes listados no Microsoft.AspNetCore.All metapacote. Supõe-se que esses pacotes estejam presentes no sistema de destino.
O armazenamento de pacotes de tempo de execução é instalado no host quando o SDK do .NET é instalado. Outros instaladores podem fornecer o armazenamento de pacotes de tempo de execução, incluindo instalações Zip/tarball do SDK do .NET, apt-getRed Hat Yum, o pacote de hospedagem do Windows Server .NET Core e instalações manuais de armazenamento de pacotes de tempo de execução.
Ao implantar um aplicativo de implantação dependente da estrutura, certifique-se de que o ambiente de destino tenha o SDK do .NET instalado. Se o aplicativo for implantado em um ambiente que não inclua ASP.NET Core, você poderá desativar o armazenamento implícito especificando <PublishWithAspNetCoreTargetManifest> definido como false no arquivo de projeto, como no exemplo a seguir:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Nota
Para aplicativos de implantação autônomos, supõe-se que o sistema de destino não contenha necessariamente os pacotes de manifesto necessários. Portanto, <PublishWithAspNetCoreTargetManifest> não pode ser definido como true para um aplicativo independente.
