Repositório 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 alvo.

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 num único comando dotnet store, repetindo no comando a opção e o caminho.

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 ficheiro de manifesto de destino artifact.xml. 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 deartifact.xml é produzido após a execução do exemplo anterior. Observe que Castle.Core é uma dependência de Moq, portanto, é incluído automaticamente e aparece no arquivo de manifesto 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 uma aplicação com base em 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 for implementado um aplicativo com uma dependência de manifesto presente na implantação (o assembly está na pasta bin), o repositório de pacotes de tempo de execução não será utilizado no host para esse assembly. A montagem da pasta bin é utilizada independentemente da sua presença na loja de pacotes em 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 houver uma incompatibilidade de versão entre a dependência no manifesto de destino da aplicação e a versão existente no repositório de pacotes de runtime, e o aplicativo não incluir a versão necessária do pacote na sua implementação, o aplicativo falha ao iniciar. A exceção inclui o nome do manifesto de destino que solicitou o assembly do repositório de pacotes de tempo de execução, o que ajuda a resolver a incompatibilidade.

Quando a implantação é reduzida na publicação, somente as versões específicas dos pacotes de manifesto que você especificar são excluídas 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 manifests de destino com o comando dotnet publish é especificá-los no ficheiro do projeto como uma lista de caminhos separados por ponto e vírgula sob uma tag <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. Não se pode fazer suposições sobre o manifesto de destino em tais ambientes, por isso deve-se usar a opção --manifest 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, a funcionalidade de armazenamento de pacotes em tempo de execução é usada implicitamente por uma aplicação ASP.NET Core quando a aplicação é implantada como uma aplicação de implantação dependente da plataforma. Os destinos em Microsoft.NET.Sdk.Web incluem manifestos que fazem referência ao armazenamento de pacotes 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 ao instalar o SDK do .NET. Outros instaladores podem fornecer o repositório de pacotes de execução de ambiente, incluindo as instalações em formato Zip/tarball do SDK do .NET, apt-get Red Hat Yum, o conjunto de hospedagem do .NET Core no Windows Server e as instalações manuais do repositório de pacotes 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 a aplicação for implementada num ambiente que não inclua ASP.NET Core, pode optar por sair da loja implícita especificando <PublishWithAspNetCoreTargetManifest> set to false no ficheiro do projeto, como no seguinte exemplo:

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

Ver também

• dotnet-publicar
• dotnet-armazém