Compartilhar via

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 .NET ou Visual Studio.

Para obter um breve tutorial sobre publicação, consulte Tutorial: Publicar um aplicativo de console .NET.

Para obter um breve tutorial sobre publicação, consulte Tutorial: Publicar um aplicativo de console .NET.

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 .NET Runtime 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 como autônomo
    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 do aplicativo, quaisquer dependências de aplicativo e o .NET runtime necessário para executar o aplicativo. O ambiente que executa o aplicativo não precisa ter o .NET runtime 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 .NET runtime instalada que o aplicativo pode usar.

Importante

Especifique a plataforma de destino com um RID (identificador de runtime). Para obter mais informações sobre RIDs, consulte .NET Catálogo RID.

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 plataforma de destino para qualquer TFM (Target Framework Moniker) válido. Por exemplo, se o projeto utilizar <TargetFramework>net9.0</TargetFramework>, será criado um binário direcionado para o .NET 9.

Se você quiser direcionar mais de um framework, poderá definir a <TargetFrameworks> definiçã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:

O modo de configuração de build padrão é Release, a menos que seja alterado com o -c parâmetro.

dotnet publish -c Release -f net9.0

O diretório de saída padrão do dotnet publish comando é ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Por exemplo, dotnet publish -c Release -f net9.0 publica em ./bin/Release/net9.0/publish/. No entanto, você pode optar por um caminho de saída simplificado e uma estrutura de pastas para todas as saídas de build. Para obter mais informações, consulte o layout de saída do Artifacts.

Em Visual Studio, crie perfis de publicação separados para cada estrutura de destino.

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, .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 UseAppHost, que é padrão true. Para publicar apenas a DLL portátil sem o executável específico da plataforma, configure UseAppHost na linha de comando (false) ou como uma -p:UseAppHost=false.

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 de 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>

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  6. Selecione Salvar e , em seguida, Publicar.

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

Referência rápida

A tabela a seguir fornece exemplos rápidos de como publicar seu aplicativo.

Modo de Publicação Comando
Implantação dependente de framework dotnet publish -c Release [-r <RID>]
DLL (implantação dependente de estrutura) dotnet publish -c Release -p:UseAppHost=false
Implantação autônoma dotnet publish -c Release [-r <RID>] --self-contained true
Distribuição de arquivo único dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Implantação do AOT nativo dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Implantação ReadyToRun dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true
Implantação de contêiner dotnet publish -c Release [-r <RID>] -t:PublishContainer

Implantação dependente de framework

A implantação dependente de framework é o modo padrão quando você publica pela CLI ou pelo 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 a myapp.exe em Windows ou apenas myapp em outras plataformas.

Seu aplicativo está configurado para direcionar uma versão específica do .NET. O runtime de .NET necessário precisa estar presente no ambiente onde seu aplicativo é executado. Por exemplo, se o seu aplicativo direcionar .NET 9, qualquer ambiente onde ele seja executado deverá ter o runtime .NET 9 instalado.

A publicação de uma implantação dependente de estrutura cria um aplicativo que avança automaticamente para o patch de segurança de .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 Selecione a versão .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 .NET runtime instalado.
  • Cross-platform: o aplicativo e qualquer biblioteca baseada em .NET são executados em outros sistemas operacionais.
  • Usa o runtime corrigido mais recente: o aplicativo usa o runtime mais recente instalado no ambiente.

Desvantagens

  • Requer pré-instalação do runtime: O aplicativo só poderá ser executado se a versão do .NET que ele requer já estiver instalada no ambiente.
  • .NET pode mudar: o ambiente em que o aplicativo é executado pode usar um runtime .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 da Tecnologia de Aplicação de Controle de Fluxo (Control-flow Enforcement Technology - CET) é habilitada por padrão, começando com .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>]

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

Ou explicitamente:

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

  • --self-contained false

    Essa opção informa explicitamente ao SDK do .NET que deve criar uma implantação dependente de framework.

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina o Modo de Implantaçãocomo dependente da Estrutura (esse é o padrão).
  6. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Selecione Salvar e , em seguida, Publicar.

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

Por padrão, o apphost descobre e usa um runtime de .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 .NET também pode ser personalizado para cada 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 opções de configuração DOTNET_ROOT, consulte .NET variáveis de ambiente.

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.

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

AppHostDotNetSearch permite especificar um ou mais locais em que o executável procurará uma instalação .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 AppHostDotNetSearch, AppHostRelativeDotNet e opções de localização de instalaçã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 arquivo myapp.dll é 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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -p:UseAppHost=false

    Essa propriedade desabilita a criação de um executável específico da plataforma, produzindo apenas a DLL portátil.

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina o modo de implantação como dependente da estrutura.
  6. Desmarque Produzir arquivo único.
  7. Defina o Ambiente de Execução Destino como Portátil (ou deixe em branco).
  8. Selecione Salvar e , em seguida, Publicar.

Implantação autônoma

Quando você publica uma implantação autossuficiente (SCD), o processo de publicação cria um executável específico para a plataforma. A publicação de um SCD inclui todos os arquivos de .NET necessários para executar seu aplicativo, mas não inclui as dependências nativas de .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 é atualizado para o patch de segurança mais recente disponível do .NET. Para obter mais informações sobre a associação de versão no momento da compilação, consulte Selecione a versão .NET a ser usada.

Vantagens

  • Controlar a versão do .NET: Especifique 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

  • Larger deployments: como o aplicativo inclui o tempo de execução 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 os de uma implantação dependente de framework.
  • Mais difícil atualizar a versão do .NET: O runtime do .NET só pode ser atualizado liberando uma nova versão do aplicativo.

Dica

Você pode reduzir o tamanho total de aplicativos autocontidos compatíveis publicando com recortes ou habilitando o modo de globalização invariável. Para obter mais informações sobre o modo invariável de globalização, consulte .NET Modo Invariável de Globalização.

Publicar

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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  • --self-contained true

    Essa opção informa ao SDK do .NET que deve criar um executável como uma implantação autossuficiente (SCD).

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina o modo de implantação como autocontido.
  6. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Selecione Salvar e , em seguida, Publicar.

Distribuiçã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 runtime, 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 redução 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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  • -p:PublishSingleFile=true

    Essa propriedade agrupa todos os arquivos dependentes do aplicativo em um único binário.

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina o modo de implantação como autocontido ou dependente da estrutura.
  6. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Marque Produzir arquivo único.
  8. Selecione Salvar e , em seguida, Publicar.

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 runtime, levando a uma inicialização de aplicativo mais rápida.
  • Reduzido uso de memória: menor volume de memória em comparação com aplicativos .NET tradicionais.
  • Nenhuma dependência de runtime: o aplicativo é executado sem a necessidade de runtime do .NET.
  • Tamanho de implantação menor: geralmente menor do que implantação autocontida com o tempo de execução completo.

Desvantagens

  • Suporte limitado a frameworks : nem todos os recursos e bibliotecas .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 comuns.

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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  • -p:PublishAot=true

    Essa propriedade habilita a compilação AOT nativa, que compila o aplicativo diretamente para o código nativo.

A publicação AOT nativa deve ser configurada no arquivo de projeto. Você não pode habilitá-lo por meio da interface do usuário de publicação Visual Studio.

  1. Em Solution Explorer, clique com o botão direito do mouse em seu projeto e selecione Edit Project File.

  2. Adicione a seguinte propriedade a um <PropertyGroup>:

    <PublishAot>true</PublishAot>

  3. Salve o arquivo de projeto.

  4. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.

  5. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.

  6. Escolha um local de pasta ou aceite o padrão e selecione Concluir.

  7. No perfil de publicação, selecione Mostrar todas as configurações.

  8. Defina o modo de implantação como autocontido.

  9. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).

  10. Selecione Salvar e , em seguida, Publicar.

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

Implantação ReadyToRun

Quando você publica seu aplicativo com a compilação ReadyToRun, os assemblies do aplicativo são compilados no 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ção dependente de estrutura e auto-contido.

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 .NET bibliotecas e estruturas sem modificação.
  • Implantação flexível: pode ser combinada tanto com implantação dependente de framework quanto com implantação autocontida.

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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  • -p:PublishReadyToRun=true

    Essa propriedade habilita a compilação ReadyToRun, que melhora o desempenho de inicialização por meio da pré-compilação de assemblies.

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Se esta for sua primeira publicação, selecione Pasta como o destino de publicação e selecione Avançar.
  3. Escolha um local de pasta ou aceite o padrão e selecione Concluir.
  4. No perfil de publicação, selecione Mostrar todas as configurações.
  5. Defina o modo de implantação como autocontido ou dependente da estrutura.
  6. Defina Target Runtime à plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Verifique a opção Habilitar compilação ReadyToRun.
  8. Selecione Salvar e , em seguida, Publicar.

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 a necessidade de 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 .NET SDK 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.

Dica

Para obter mais informações sobre as configurações de projeto relacionadas a contêineres, consulte Containerize uma referência de aplicativo .NET.

Vantagens

  • Contêinerização simplificada: não é necessário escrever 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

  • -c Release

    Este switch define a configuração de build como Release, que é otimizada para implantação em produção.

  • -r <RID>

    Essa opção usa um RID (identificador de runtime) para especificar a plataforma de destino e garante que as dependências nativas sejam incluídas (se necessário). Para obter uma lista de identificadores de runtime, consulte o catálogo RID (Runtime Identifier).

  • -t:PublishContainer

    Esse destino publica o aplicativo como uma imagem de contêiner.

Você também pode usar a abordagem do perfil de publicação:

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

  • -p:PublishProfile=DefaultContainer

    Este perfil aciona o processo de publicação do contêiner.

  1. Clique com o botão direito do mouse no projeto em Solution Explorer e selecione Publish.
  2. Selecione o Registro de Contêiner como o destino de publicação e selecione Avançar.
  3. Escolha o registro de contêiner de destino (como Azure Container Registry, Docker Hub ou RegistroGeneric) e selecione Next.
  4. Configure os detalhes da conexão de registro e a autenticação.
  5. No perfil de publicação, selecione Mostrar todas as configurações.
  6. Defina o modo de implantação como autocontido ou dependente da estrutura com base em suas necessidades.
  7. Defina Target Runtime para a plataforma desejada (por exemplo, linux-x64 para contêineres do Linux).
  8. Defina configurações específicas do contêiner, como o nome da imagem e as marcas.
  9. Selecione Salvar e , em seguida, Publicar.

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

Consulte também

  • Last updated on