Partilhar via

Visão geral da publicação de aplicações .NET

Este artigo explica as diferentes formas de publicar uma aplicação .NET. Ele aborda os modos de publicação, como produzir executáveis e binários entre plataformas e o impacto de cada abordagem em ambientes de implantação e tempo de execução. Pode publicar aplicações .NET usando tanto a CLI .NET como o Visual Studio.

Para um breve tutorial sobre publicação, veja Tutorial: Publique uma aplicação de consola .NET.

Para um breve tutorial sobre publicação, veja Tutorial: Publique uma aplicação de consola .NET.

O que é publicar

Publicar uma aplicação .NET significa compilar código-fonte para criar um executável ou binário, juntamente com as suas dependências e ficheiros 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 esta decisão incluem se o ambiente de implementação tem o tempo de execução .NET apropriado instalado e se precisa de funcionalidades específicas de compilação que exijam agrupar o tempo de execução com a sua aplicação. Os dois modos de publicação são:

  • Publicar como autônomo
    Este modo produz uma pasta de publicação que inclui um executável específico da plataforma usado para iniciar a aplicação, um binário compilado contendo código da aplicação, quaisquer dependências da aplicação e o runtime .NET necessário para executar a aplicação. O ambiente que executa a aplicação não precisa de ter o runtime .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 contendo o código do aplicativo e quaisquer dependências do aplicativo. O ambiente que executa a aplicação deve ter uma versão do runtime .NET instalada que a aplicação possa usar.

Importante

Você especifica a plataforma de destino com um identificador de tempo de execução (RID). Para mais informações sobre RIDs, consulte .NET RID Catalog.

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 Target Framework Moniker (TFM) válido. Por exemplo, se o seu projeto usar <TargetFramework>net9.0</TargetFramework>, cria-se um binário que tem como alvo .NET 9.

Se quiser direcionar mais do que uma estrutura, o utilizador pode definir a <TargetFrameworks> configuração para vários valores de TFM, separados por ponto e vírgula. Quando você cria seu aplicativo, ele é 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 compilação 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 estrutura de pastas para todas as saídas de compilação. Para mais informações, consulte Esquema de saída de artefatos.

No Visual Studio, crie perfis de publicação separados para cada framework alvo.

Binários portáteis

Quando publica uma aplicação .NET, pode direcionar uma plataforma específica ou criar um binário portátil. Por defeito, mesmo ao criar um binário portátil, o .NET publica um executável específico da plataforma ("apphost") juntamente com a DLL portátil, a menos que desative explicitamente este comportamento.

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

O benefício de segmentar 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 seu aplicativo tiver dependências nativas, ele pode não ser executado em um sistema operacional diferente se publicado como um binário portátil. Por exemplo, aplicações que dependem da API do Windows não correm nativamente no macOS ou Linux. Você precisaria fornecer 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 pode 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

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 para a 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

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>]
Implantação dependente do framework (DLL) dotnet publish -c Release -p:UseAppHost=false
Implantação independente dotnet publish -c Release [-r <RID>] --self-contained true
Desdobramento de arquivo único dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Implementação de AOT Nativa dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Implantação do 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 implementação dependente do framework é o modo padrão quando publicas a partir 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 tem um nome semelhante a myapp.exe no Windows ou simplesmente myapp noutras plataformas.

A sua aplicação está configurada para direcionar uma versão específica do .NET. Esse tempo de execução .NET direcionado deve estar presente no ambiente onde a sua aplicação é executada. Por exemplo, se a sua aplicação tem como alvo o .NET 9, qualquer ambiente onde a sua aplicação corra deve ter o runtime do .NET 9 instalado.

Publicar uma implementação dependente do framework cria uma aplicação que avança automaticamente para o último patch de segurança .NET disponível no ambiente que executa a aplicação. Para mais informações sobre a ligação de versões em tempo de compilação, veja Selecione a versão .NET a utilizar.

Vantagens

  • Pequena implantação: somente o aplicativo e suas dependências são distribuídos. O ambiente onde a aplicação é executada deve já ter o runtime .NET instalado.
  • Cross-platform: A aplicação e qualquer biblioteca baseada em .NET corre noutros sistemas operativos.
  • Usa o tempo de execução corrigido mais recente: o aplicativo usa o tempo de execução mais recente instalado no ambiente.

Desvantagens

  • Requer pré-instalação do runtime: A aplicação só pode correr se a versão alvo do .NET já estiver instalada no ambiente.
  • .NET pode mudar: O ambiente onde a aplicação é executada pode usar um tempo de execução .NET mais recente, o que pode alterar o comportamento da aplicação.

Iniciar aplicações 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, que ainda é uma maneira aceitável de executar o aplicativo. Sempre que possível, recomenda-se usar o apphost. Há uma série de 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 dos processos, 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 disponíveis mitigações de segurança de baixo nível aplicadas por padrão que o tornam mais seguro. Por exemplo, a shadow stack da Control-flow Enforcement Technology (CET) está ativada por defeito a partir do .NET 9. As mitigações aplicadas a dotnet são o menor denominador comum de todos os ambientes de execução suportados.

Publicar

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

  • -c Release

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

Ou explicitamente:

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

  • --self-contained false

    Este switch indica explicitamente ao SDK .NET que crie um desdobramento dependente do framework.

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 (esse é o padrão).
  6. Defina Target Runtime para a plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Selecione Salvar e, em seguida, Publicar.

Configurar o comportamento de procura da instalação .NET

Por padrão, o apphost descobre e utiliza um .NET runtime instalado globalmente, com locais de instalação que variam consoante a plataforma. Para obter mais informações sobre a descoberta de tempo de execução e locais de instalação, consulte Solucionar problemas de falhas de inicialização de aplicativos.

O caminho de execução .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 mais informações sobre todas as opções de configuração DOTNET_ROOT, veja .NET variáveis de ambiente.

Em geral, a melhor prática de utilização DOTNET_ROOT consiste em:

  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" alvo.

Nas versões .NET 9 e posteriores, pode configurar os caminhos de pesquisa da instalação do .NET do executável publicado, através das propriedades AppHostDotNetSearch e AppHostRelativeDotNet.

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

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

Para obter mais informações, consulte AppHostDotNetSearch, AppHostRelativeDotNete instalar opções de localização no apphost.

Implantação de DLL entre plataformas

Como alternativa, você pode publicar seu aplicativo como uma DLL de plataforma cruzada 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

  • -c Release

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

  • -p:UseAppHost=false

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

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 Target Runtime como Portable (ou deixe em branco).
  8. Selecione Salvar e, em seguida, Publicar.

Implantação independente

Quando você publica uma implantação independente (SCD), o processo de publicação cria um executável específico da plataforma. Publicar um SCD inclui todos os ficheiros .NET necessários para correr a sua aplicação, mas não inclui as dependências nativas do .NET. Essas dependências devem estar presentes no ambiente antes que o aplicativo seja executado.

Publicar um SCD cria uma aplicação que não avança para o último patch de segurança .NET disponível. Para mais informações sobre a ligação de versões em tempo de compilação, veja Selecione a versão .NET a utilizar.

Vantagens

  • Control .NET versão: Controla qual versão do .NET é implementada com a aplicação.
  • Segmentação específica da plataforma: como o aplicativo deve ser publicado para cada plataforma, fica claro onde o aplicativo é executado.

Desvantagens

  • Implementações maiores: Como a aplicação inclui o runtime .NET e todas as dependências, o tamanho do download e o espaço no disco rígido necessários são superiores aos de uma implementação dependente do framework.
  • Difícil atualizar a versão .NET: O tempo de execução .NET só pode ser atualizado lançando uma nova versão da aplicação.

Dica

Você pode reduzir o tamanho total de aplicativos autônomos compatíveis publicando com redução ou habilitando o modo de globalização invariante. Para mais informações sobre o modo invariante da globalização, veja .NET Modo Invariante da Globalização.

Publicar

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

  • -c Release

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  • --self-contained true

    Este switch instrui o SDK .NET a criar um executável como uma implementação autónoma (SCD).

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 Autônomo.
  6. Defina Target Runtime para a plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Selecione Salvar e, em seguida, Publicar.

Desdobramento 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 dependentes da estrutura e autônomos, fornecendo uma opção atraente para implantar e distribuir seu aplicativo como um único arquivo.

Os aplicativos de arquivo único são sempre específicos do sistema operacional e da arquitetura. Tens de 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 desorganização de arquivos: todas as dependências são agrupadas, eliminando a necessidade de gerenciar vários arquivos.
  • Fácil implantação: copie um único arquivo para implantar o aplicativo.

Desvantagens

  • Tamanho de arquivo maior: o arquivo único inclui todas as dependências, tornando-o maior do que arquivos individuais.
  • Arranque mais lento: Os ficheiros têm de ser extraídos em tempo de execução, o que pode afetar o desempenho do arranque.
  • Específico da plataforma: Deve publicar arquivos separados para cada plataforma de destino.

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

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

Publicar

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

  • -c Release

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  • -p:PublishSingleFile=true

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

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 Autônomo ou dependente da Estrutura.
  6. Defina Target Runtime para a plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Marque Produzir arquivo único.
  8. Selecione Salvar e, em seguida, Publicar.

Implementação de AOT Nativa

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

Vantagens

  • Arranque rápido: Não é necessária compilação JIT em tempo de execução, o que leva a um arranque da aplicação mais rápido.
  • Redução do uso de memória: Menor área de memória comparada com aplicações tradicionais de .NET.
  • Sem dependência em tempo de execução: A aplicação é executada sem necessitar da instalação do runtime do .NET.
  • Tamanho de implantação menor: geralmente menor do que a implantação autônoma com o tempo de execução completo.

Desvantagens

  • Suporte limitado para frameworks: Nem todas as funcionalidades e bibliotecas de .NET são compatíveis com o AOT nativo.
  • Tempos de compilação mais longos: a compilação para código nativo leva mais tempo do que as compilações normais.
  • Específico da plataforma: Deve compilar separadamente para cada plataforma e arquitetura de destino.
  • Limitações de depuração: Experiência de depuração mais complexa comparada com aplicações .NET normais.

Para obter mais informações sobre a implantação de AOT nativa, consulte Implantação de AOT nativa.

Publicar

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

  • -c Release

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  • -p:PublishAot=true

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

A publicação AOT nativa deve ser configurada no arquivo de projeto. Não podes ativá-lo através da interface de publicação do Visual Studio.

  1. Em Solution Explorer, clique com o botão direito no seu projeto e selecione Editar Ficheiro do Projeto.

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

    <PublishAot>true</PublishAot>

  3. Salve o arquivo de projeto.

  4. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.

  5. Se esta for a primeira vez que publica, selecione Pasta como 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 Autônomo.

  9. Defina Target Runtime para a 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 de AOT nativa, consulte Implantação de AOT nativa.

Implantação do ReadyToRun

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

Os binários ReadyToRun contêm código de linguagem intermediária (IL) e a versão nativa do mesmo código. Embora os binários R2R sejam maiores do que os assemblies regulares, eles fornecem um 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 primeira utilização: latência reduzida para a primeira execução de caminhos de código.
  • Compatível com código existente: Funciona com a maioria das bibliotecas e frameworks .NET sem modificações.
  • Implantação flexível: pode ser combinada com a implantação dependente da estrutura e com os modos de implantação independente .

Desvantagens

  • Tamanho maior: o aplicativo é maior no disco devido à inclusão de IL e código nativo.
  • Tempos de compilação 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 a segmentação de plataformas específicas.

Publicar

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

  • -c Release

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  • -p:PublishReadyToRun=true

    Essa propriedade permite a compilação ReadyToRun, que melhora o desempenho de inicialização pré-compilando assemblies.

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Se esta for a primeira vez que publica, selecione Pasta como 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 Autônomo ou dependente da Estrutura.
  6. Defina Target Runtime para a plataforma desejada (por exemplo, win-x64 para Windows de 64 bits).
  7. Selecione Ativar a compilação ReadyToRun.
  8. Selecione Salvar e, em seguida, Publicar.

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

Implantação de contêiner

Quando publica a sua aplicação como um contentor, o SDK .NET empacota a sua aplicação e as suas dependências numa imagem de contentor sem precisar de um Dockerfile separado. Esse modo de implementação cria uma imagem de contentor completa que pode ser executada em qualquer runtime de contentor, como Docker ou Podman. A implantação de contêineres simplifica o processo de conteinerização, eliminando a necessidade de escrever e manter Dockerfiles enquanto fornece imagens de base otimizadas.

A partir do .NET SDK 8.0.200, o suporte a contentores está incluído por defeito e não requer pacotes NuGet adicionais. Para aplicativos de console, talvez seja necessário habilitar o suporte a contêineres explicitamente definindo a EnableSdkContainerSupport propriedade como true.

Dica

Para mais informações sobre as definições do projeto relacionadas com containers, veja Containerize a .NET app reference.

Vantagens

  • Contentorização simplificada: Não há necessidade de escrever ou manter Dockerfiles para cenários básicos.
  • Imagens base otimizadas: usa imagens base otimizadas fornecidas pela Microsoft com as atualizações de segurança mais recentes.
  • Ambiente consistente: garante um ambiente de tempo de execução consistente em todo o desenvolvimento, teste e produção.
  • Fácil distribuição: as imagens de contêiner podem ser facilmente compartilhadas e implantadas em diferentes ambientes.
  • Isolamento da plataforma: os aplicativos são executados em contêineres isolados, reduzindo conflitos entre aplicativos.

Desvantagens

  • Dependência de tempo de execução de contêiner: O ambiente de destino deve ter um tempo de execução de contêiner instalado.
  • Tamanho da imagem: as imagens de contêiner geralmente são maiores do que outros métodos de implantação.
  • Curva de aprendizagem: Requer compreensão de conceitos de contêiner e ferramentas.
  • 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

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

  • -r <RID>

    Essa opção usa um identificador de tempo de execução (RID) 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 tempo de execução, consulte Catálogo de identificador de tempo de execução (RID).

  • -t:PublishContainer

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

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

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

  • -p:PublishProfile=DefaultContainer

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

  1. Clique com o botão direito no projeto em Solution Explorer e selecione Publicar.
  2. Selecione Registro de contêiner como o destino de publicação e selecione Avançar.
  3. Escolha o seu registo de contentores de destino (como Azure Container Registry, Docker Hub ou Generic Registry) e selecione Next.
  4. Configure os detalhes da conexão do 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 Autônomo ou Dependente da Estrutura com base em suas necessidades.
  7. Defina o Target Runtime para a plataforma desejada (por exemplo, linux-x64 para contêineres Linux).
  8. Configure configurações específicas do contêiner, como nome da imagem e tags.
  9. Selecione Salvar e, em seguida, Publicar.

Para mais informações sobre a implementação de contentores, consulte .NET SDK creation overview.

Ver também

  • Last updated on