Repositório de pacotes de runtime

A partir do .NET Core 2.0, é possível empacotar e implantar aplicativos em um conjunto conhecido de pacotes que existem 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.

Esse recurso é implementado como um repositório de pacotes de runtime, que é um diretório em disco em que os pacotes são armazenados (normalmente em /usr/local/share/dotnet/store no macOS/Linux e C:/Program Files/dotnet/store no Windows). Nesse 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 runtime. Os desenvolvedores podem direcionar esse manifesto ao publicar seu aplicativo. Normalmente, o manifesto de destino é fornecido pelo proprietário do ambiente de produção direcionado.

Preparando um ambiente de runtime

O administrador de um ambiente de runtime pode otimizar aplicativos para implantações mais rápidas e menor uso de espaço em disco criando um repositório de pacotes de runtime e o manifesto de destino correspondente.

A primeira etapa é criar um manifesto do repositório de pacotes que lista os pacotes que compõem o repositório de pacotes de runtime. Esse 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 manifesto do repositório de pacotes de exemplo a seguir (packages.csproj) é usado para adicionar Newtonsoft.Json e Moq a um repositório de pacotes de runtime:

<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 runtime executando dotnet store com o manifesto, runtime e 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

É possível passar vários caminhos de manifesto do repositório de pacotes de destino para um único comando dotnet store repetindo a opção e o caminho no comando.

Por padrão, a saída do comando é um repositório de pacotes no subdiretório .dotnet/store do perfil do usuário. Você pode especificar um local diferente usando a opção --output <OUTPUT_DIRECTORY> . O diretório raiz da loja contém um arquivo manifesto de destino artifact.xml. Esse arquivo pode ser disponibilizado para download e ser usado por autores de aplicativos que desejam direcionar esse repositório durante a publicação.

Exemplo

O arquivo artifact.xml a seguir é produzido depois de executar o exemplo anterior. Observe que Castle.Core é uma dependência de Moq, portanto, ele é 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>

Publicação de um aplicativo 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. Não fazer isso resulta na falha ao iniciar o aplicativo.

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ê fizer isso, o aplicativo será cortado para a união de pacotes especificada nos arquivos de manifesto de destino fornecidos para o comando.

Se você implantar um aplicativo com uma dependência de manifesto presente na implantação (o assembly está presente na pasta bin), o repositório de pacotes de runtime não será usado no host desse assembly. O assembly da pasta bin é usado, independentemente de sua presença no repositório de pacotes de runtime no host.

A versão da dependência indicada no manifesto deve corresponder à versão da dependência no repositório de pacotes de runtime. Se houver uma incompatibilidade de versão entre a dependência no manifesto de destino 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 em sua implantação, então o aplicativo não conseguirá iniciar. A exceção inclui o nome do manifesto de destino chamado que chamou o assembly do repositório de pacotes de runtime, que ajuda você a solucionar problemas de incompatibilidade.

Quando a implantação é cortada na publicação, somente as versões específicas dos pacotes de manifesto indicadas são retidas na saída publicada. Os pacotes nas versões indicadas devem estar presentes no host para que o aplicativo seja iniciado.

Especificação de manifestos de destino no arquivo de projeto

Uma alternativa para especificar manifestos de destino com o comando dotnet publish é especificá-los no arquivo de projeto como uma lista de caminhos separados por ponto e vírgula sob a 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 do .NET Core. Esse não é o caso de projetos de software livre. Os usuários de um projeto de software livre 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 nesses ambientes, portanto, você deve usar a opção --manifest de dotnet publish.

repositório implícito do ASP.NET Core (somente .NET Core 2.0)

O repositório implícito ASP.NET Core aplica-se apenas a ASP.NET Core 2.0. É altamente recomendável que os aplicativos usem ASP.NET Core 2.1 e posterior, que não usa o repositório implícito. ASP.NET Core 2.1 e posteriores usam a estrutura compartilhada.

No .NET Core 2.0, o recurso de repositório de pacotes de runtime é usado implicitamente por um aplicativo ASP.NET Core quando o aplicativo é implantado como aplicativo implantação dependente de estrutura. Os alvos em Microsoft.NET.Sdk.Web incluem manifestos que fazem referência ao repositório de pacotes implícito no sistema de destino. Além disso, qualquer aplicativo dependente de estrutura que dependa do Microsoft.AspNetCore.All pacote resulta em um aplicativo publicado que contenha 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 repositório de pacotes de runtime é instalado no host quando o SDK do .NET é instalado. Talvez outros instaladores forneçam o repositório de pacotes de runtime, inclusive instalações Zip/tarball do SDK do .NET, apt-get, Red Hat Yum, pacote de hospedagem do Windows Server do .NET Core e instalações manuais de repositório de pacotes de runtime.

Ao implantar um aplicativo de implantação dependente da estrutura , verifique se o ambiente de destino tem o SDK do .NET instalado. Se o aplicativo for implantado em um ambiente que não inclua ASP.NET Core, você poderá recusar o repositório implícito especificando <PublishWithAspNetCoreTargetManifest> definido false no arquivo de projeto como no exemplo a seguir:

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

Consulte também

• dotnet-publish
• dotnet-store