Visão geral da publicação de aplicativos .NET

Este artigo explica as diferentes maneiras de publicar um aplicativo .NET. Ele aborda os modos de publicação, como produzir executáveis e binários multiplataforma e o impacto de cada abordagem em ambientes de implantação e runtime. Você pode publicar aplicativos .NET usando a CLI do .NET ou o Visual Studio.

O que é a publicação

Publicar um aplicativo .NET significa compilar o código-fonte para criar um executável ou binário, juntamente com suas dependências e arquivos relacionados, para distribuição. Após a publicação, você implanta o aplicativo em um servidor, plataforma de distribuição, contêiner ou ambiente de nuvem. O processo de publicação prepara um aplicativo para implantação e uso fora de um ambiente de desenvolvimento.

Modos de publicação

Há duas maneiras principais de publicar um aplicativo. Alguns fatores que influenciam essa decisão incluem se o ambiente de implantação tem o Runtime do .NET apropriado instalado e se você precisa de recursos de compilação específicos que exigem agrupar o runtime com seu aplicativo. Os dois modos de publicação são:

• Publicar autocontido
  Esse modo produz uma pasta de publicação que inclui um executável específico da plataforma usado para iniciar o aplicativo, um binário compilado contendo código de aplicativo, quaisquer dependências de aplicativo e o runtime do .NET necessário para executar o aplicativo. O ambiente que executa o aplicativo não precisa ter o runtime do .NET pré-instalado.

• Publicar dependente da estrutura
  Esse modo produz uma pasta de publicação que inclui um executável opcional específico da plataforma usado para iniciar o aplicativo, um binário compilado que contém o código do aplicativo e quaisquer dependências de aplicativo. O ambiente que executa o aplicativo deve ter uma versão do runtime do .NET instalada que o aplicativo pode usar.

Noções básicas de publicação

A <TargetFramework> configuração do arquivo de projeto especifica a estrutura de destino padrão quando você publica seu aplicativo. Você pode alterar a estrutura de destino para qualquer TFM (Target Framework Moniker) válido. Por exemplo, se o projeto usar <TargetFramework>net9.0</TargetFramework>, um binário direcionado ao .NET 9 será criado.

Se você quiser direcionar mais de uma estrutura, poderá definir a <TargetFrameworks> configuração como vários valores TFM, separados por um ponto-e-vírgula. Quando você cria seu aplicativo, seu aplicativo é criado para cada estrutura de destino definida pelo seu projeto. No entanto, ao publicar seu aplicativo, você deve especificar a estrutura de destino:

dotnet publish -c Release -f net9.0

Binários portáteis

Ao publicar um aplicativo .NET, você pode direcionar uma plataforma específica ou criar um binário portátil. Por padrão, mesmo ao criar um binário portátil, o .NET publica um executável específico da plataforma ("apphost") ao lado da DLL portátil, a menos que você desabilite explicitamente esse comportamento.

O executável específico da plataforma é criado devido à propriedade, que usa como UseAppHost padrão true. Para publicar apenas a DLL portátil sem o executável específico da UseAppHost plataforma, defina false como na linha de comando (-p:UseAppHost=false) ou como uma propriedade de projeto.

O benefício de direcionar uma plataforma específica é que ela pode lidar com dependências nativas que seu aplicativo pode exigir, garantindo a compatibilidade com os requisitos específicos da plataforma de destino.

Dependências nativas

Se o aplicativo tiver dependências nativas, ele poderá não ser executado em um sistema operacional diferente se publicado como um binário portátil. Por exemplo, aplicativos que dependem da API do Windows não são executados nativamente no macOS ou linux. Você precisaria fornecer um código específico da plataforma e compilar um executável para cada plataforma.

Considere também que, se uma biblioteca referenciada fornecer dependências específicas da plataforma, seu aplicativo poderá não ser executado em todas as plataformas. No entanto, quando você publica e direciona uma plataforma específica, as dependências específicas da plataforma de um pacote NuGet são copiadas para a pasta de publicação.

Para garantir que seu aplicativo seja publicado com suas dependências nativas, publique para uma plataforma específica:

dotnet publish -c Release -r <RID>

Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

Implantação dependente da estrutura

A implantação dependente da estrutura é o modo padrão quando você publica da CLI ou do Visual Studio. Nesse modo, é criado um executável específico da plataforma que pode ser usado para iniciar seu aplicativo. O executável específico da plataforma é denominado algo semelhante ao myapp.exe no Windows ou simplesmente myapp em outras plataformas.

Seu aplicativo está configurado para direcionar uma versão específica do .NET. Esse runtime do .NET direcionado é necessário para estar no ambiente em que seu aplicativo é executado. Por exemplo, se o aplicativo for direcionado ao .NET 9, qualquer ambiente em que seu aplicativo seja executado deverá ter o runtime do .NET 9 instalado.

A publicação de uma implantação dependente de estrutura cria um aplicativo que é encaminhado automaticamente para o patch de segurança do .NET mais recente disponível no ambiente que executa o aplicativo. Para obter mais informações sobre a associação de versão no momento da compilação, consulte Selecionar a versão do .NET a ser usada.

Vantagens

• Implantação pequena: somente o aplicativo e suas dependências são distribuídos. O ambiente em que o aplicativo é executado já deve ter o runtime do .NET instalado.
• Multiplataforma: o aplicativo e qualquer . A biblioteca baseada em NET é executada em outros sistemas operacionais.
• Usa o runtime corrigido mais recente: o aplicativo usa o runtime mais recente instalado no ambiente.

Desvantagens

• Requer a pré-instalação do runtime: o aplicativo só poderá ser executado se a versão do .NET direcionada já estiver instalada no ambiente.
• O .NET pode mudar: o ambiente em que o aplicativo é executado pode usar um runtime do .NET mais recente, o que pode alterar o comportamento do aplicativo.

Iniciar aplicativos dependentes do framework

Há duas maneiras de executar aplicativos dependentes da estrutura: por meio do executável específico da plataforma ("apphost") e via dotnet myapp.dll. Você pode executar o executável apphost diretamente em vez de chamar dotnet myapp.dll, o que ainda é uma maneira aceitável de executar o aplicativo. Sempre que possível, é recomendável usar o apphost. Há várias vantagens em usar o apphost:

• Os executáveis aparecem como executáveis de plataforma nativa padrão.
• Os nomes executáveis são preservados nos nomes do processo, o que significa que os aplicativos podem ser facilmente reconhecidos com base em seus nomes.
• Como o apphost é um binário nativo, ativos nativos como manifestos podem ser anexados a eles.
• O Apphost tem mitigações de segurança de baixo nível disponíveis aplicadas por padrão, o que o torna mais seguro. Por exemplo, a pilha de sombra CET (Control-flow Enforcement Technology) é habilitada por padrão, começando com o .NET 9. As mitigações aplicadas a dotnet são o menor denominador comum de todos os ambientes de execução com suporte.

Publicar

dotnet publish -c Release [-r <RID>]

dotnet publish -c Release [-r <RID>] --self-contained false

Configurar o comportamento de pesquisa de instalação do .NET

Por padrão, o apphost descobre e usa um runtime do .NET globalmente instalado, com locais de instalação variando por plataforma. Para obter mais informações sobre localizações de descoberta e instalação de runtime, consulte Solucionar problemas de falhas de inicialização do aplicativo.

O caminho do runtime do .NET também pode ser personalizado por execução. A DOTNET_ROOT variável de ambiente pode ser usada para apontar para o local personalizado. Para obter mais informações sobre todas as DOTNET_ROOT opções de configuração, consulte variáveis de ambiente do .NET.

Em geral, a melhor prática para usar DOTNET_ROOT é:

1. Limpe DOTNET_ROOT as variáveis de ambiente primeiro, ou seja, todas as variáveis de ambiente que começam com o texto DOTNET_ROOT.
2. Defina DOTNET_ROOT, e somente DOTNET_ROOT, para o caminho de destino.
3. Execute o apphost de destino.

No .NET 9 e versões posteriores, você pode configurar os caminhos de pesquisa de instalação do .NET do executável publicado por meio do e AppHostDotNetSearch das AppHostRelativeDotNet propriedades.

AppHostDotNetSearch permite especificar um ou mais locais em que o executável procurará uma instalação do .NET:

• AppLocal: pasta do executável do aplicativo
• AppRelative: caminho relativo ao executável do aplicativo
• EnvironmentVariable: valor de variáveis de DOTNET_ROOT[_<arch>] ambiente
• Global: locais de instalação globais registrados e padrão

AppHostRelativeDotNet especifica o caminho relativo ao executável que será pesquisado quando AppHostDotNetSearch contiver AppRelative.

Para obter mais informações, consulte AppHostDotNetSearche AppHostRelativeDotNetinstale as opções de localização no apphost.

Implantação de DLL multiplataforma

Como alternativa, você pode publicar seu aplicativo como uma DLL multiplataforma sem um executável específico da plataforma. Nesse modo, um myapp.dll arquivo é criado na pasta de saída de publicação. Para executar seu aplicativo, navegue até a pasta de saída e use o dotnet myapp.dll comando.

Para publicar como uma DLL multiplataforma:

dotnet publish -c Release -p:UseAppHost=false

Implantação autocontida

Quando você publica uma SCD (implantação independente), o processo de publicação cria um executável específico da plataforma. A publicação de um SCD inclui todos os arquivos .NET necessários para executar seu aplicativo, mas não inclui as dependências nativas do .NET. Essas dependências devem estar presentes no ambiente antes da execução do aplicativo.

A publicação de um SCD cria um aplicativo que não é revertido para o patch de segurança do .NET disponível mais recente. Para obter mais informações sobre a associação de versão no momento da compilação, consulte Selecionar a versão do .NET a ser usada.

Vantagens

• Controlar a versão do .NET: controlar qual versão do .NET é implantada com o aplicativo.
• Direcionamento específico da plataforma: como o aplicativo deve ser publicado para cada plataforma, fica claro onde o aplicativo é executado.

Desvantagens

• Implantações maiores: como o aplicativo inclui o runtime do .NET e todas as dependências, o tamanho do download e o espaço de disco rígido necessários são maiores do que uma implantação dependente da estrutura.
• Mais difícil de atualizar a versão do .NET: o Runtime do .NET só pode ser atualizado lançando uma nova versão do aplicativo.

Publicar

dotnet publish -c Release -r <RID> --self-contained true

Implantação de arquivo único

Quando você publica seu aplicativo como uma implantação de arquivo único, todos os arquivos dependentes do aplicativo são agrupados em um único binário. Esse modelo de implantação está disponível para aplicativos independentes e dependentes de estrutura, fornecendo uma opção atraente para implantar e distribuir seu aplicativo como um único arquivo.

Aplicativos de arquivo único são sempre específicos do sistema operacional e da arquitetura. Você precisa publicar para cada configuração, como Linux x64, Linux Arm64, Windows x64 e assim por diante.

Vantagens

• Distribuição simplificada: implante e distribua seu aplicativo como um único arquivo executável.
• Redução da desordem de arquivo: todas as dependências são agrupadas, eliminando a necessidade de gerenciar vários arquivos.
• Implantação fácil: copie um único arquivo para implantar o aplicativo.

Desvantagens

• Tamanho maior do arquivo: o arquivo único inclui todas as dependências, tornando-o maior que arquivos individuais.
• Inicialização mais lenta: os arquivos devem ser extraídos em tempo de execução, o que pode afetar o desempenho da inicialização.
• Específico da plataforma: deve publicar arquivos separados para cada plataforma de destino.

A implantação de arquivo único pode ser combinada com outras otimizações, como corte e compilação ReadyToRun para otimização adicional.

Para obter mais informações sobre a implantação de arquivo único, consulte a implantação de arquivo único.

Publicar

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

Implantação AOT nativa

A implantação AOT nativa compila seu aplicativo diretamente para o código nativo, eliminando a necessidade de um runtime. Essa opção de publicação usa o modo de implantação independente , pois o código nativo compilado deve incluir tudo o que for necessário para executar o aplicativo. Isso resulta em tempos de inicialização mais rápidos e uso reduzido de memória, mas vem com algumas limitações nos recursos com suporte.

Vantagens

• Inicialização rápida: nenhuma compilação JIT necessária no tempo de execução, levando a uma inicialização de aplicativo mais rápida.
• Redução do uso de memória: menor volume de memória em comparação com os aplicativos .NET tradicionais.
• Nenhuma dependência de runtime: o aplicativo é executado sem a necessidade de instalação do runtime do .NET.
• Tamanho de implantação menor: geralmente menor do que a implantação autocontida com o runtime completo.

Desvantagens

• Suporte à estrutura limitada: nem todos os recursos e bibliotecas do .NET são compatíveis com o AOT nativo.
• Tempos de build mais longos: a compilação para o código nativo leva mais tempo do que os builds regulares.
• Específico da plataforma: deve ser compilado separadamente para cada plataforma e arquitetura de destino.
• Limitações de depuração: experiência de depuração mais complexa em comparação com aplicativos .NET regulares.

Para obter mais informações sobre a implantação do AOT nativo, consulte a implantação do AOT nativo.

Publicar

dotnet publish -c Release -r <RID> -p:PublishAot=true

Implantação readyToRun

Quando você publica seu aplicativo com a compilação ReadyToRun, seus assemblies de aplicativo são compilados como formato R2R (ReadyToRun). R2R é uma forma de compilação AOT (antecipada) que melhora o desempenho de inicialização reduzindo a quantidade de trabalho que o compilador just-in-time (JIT) precisa fazer conforme o aplicativo carrega. Essa opção de publicação pode ser usada com modos de implantaçãoindependentes e dependentes da estrutura.

Os binários ReadyToRun contêm código IL (linguagem intermediária) e a versão nativa do mesmo código. Embora os binários R2R sejam maiores que os assemblies regulares, eles fornecem melhor desempenho de inicialização.

Vantagens

• Tempo de inicialização aprimorado: o aplicativo gasta menos tempo executando o compilador JIT durante a inicialização.
• Melhor desempenho de primeiro uso: latência reduzida para execução pela primeira vez de caminhos de código.
• Compatível com o código existente: funciona com a maioria das bibliotecas e estruturas do .NET sem modificação.
• Implantação flexível: pode ser combinada com a implantação dependente da estrutura e os modos de implantação autocontidos .

Desvantagens

• Tamanho maior: o aplicativo é maior em disco devido à inclusão de il e código nativo.
• Tempos de build mais longos: a compilação leva mais tempo do que a publicação padrão.
• Otimizações específicas da plataforma: os melhores ganhos de desempenho exigem o direcionamento de plataformas específicas.

Publicar

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

Para obter mais informações sobre a implantação de ReadyToRun, consulte a compilação ReadyToRun.

Implantação de contêiner

Quando você publica seu aplicativo como um contêiner, o SDK do .NET empacota seu aplicativo e suas dependências em uma imagem de contêiner sem exigir um Dockerfile separado. Esse modo de implantação cria uma imagem de contêiner completa que pode ser executada em qualquer runtime de contêiner, como Docker ou Podman. A implantação de contêiner simplifica o processo de contêinerização eliminando a necessidade de gravar e manter Dockerfiles, fornecendo imagens base otimizadas.

A partir do SDK do .NET 8.0.200, o suporte ao contêiner é incluído por padrão e não requer pacotes NuGet extras. Para aplicativos de console, talvez seja necessário habilitar o suporte de contêiner explicitamente definindo a EnableSdkContainerSupport propriedade como true.

Vantagens

• Contêiner simplificado: não é necessário gravar ou manter Dockerfiles para cenários básicos.
• Imagens base otimizadas: usa imagens base otimizadas e fornecidas pela Microsoft com as atualizações de segurança mais recentes.
• Ambiente consistente: garante um ambiente de runtime consistente em desenvolvimento, teste e produção.
• Distribuição fácil: as imagens de contêiner podem ser facilmente compartilhadas e implantadas em diferentes ambientes.
• Isolamento de plataforma: aplicativos são executados em contêineres isolados, reduzindo conflitos entre aplicativos.

Desvantagens

• Dependência de runtime do contêiner: o ambiente de destino deve ter um runtime de contêiner instalado.
• Tamanho da imagem: normalmente, as imagens de contêiner são maiores do que outros métodos de implantação.
• Curva de aprendizado: requer a compreensão dos conceitos e ferramentas do contêiner.
• Personalização limitada: menos flexibilidade em comparação com dockerfiles personalizados para cenários complexos.

Publicar

dotnet publish -c Release [-r <RID>] /t:PublishContainer

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

Para obter mais informações sobre a implantação de contêiner, consulte a visão geral da criação de contêiner do SDK do .NET.

Consulte também

• Catálogo RID (Identificador de Runtime do .NET)
• Selecione a versão do .NET a ser usada
• Publicação para macOS