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

Os aplicativos criados com o .NET podem ser publicados em dois modos diferentes, e o modo afeta a forma como um usuário executa seu aplicativo.

Publicar seu aplicativo como independente produz um aplicativo que inclui o tempo de execução e as bibliotecas do .net e seu aplicativo e suas dependências. Os usuários do aplicativo podem executá-lo em um computador que não tenha o runtime do .NET instalado.

Publicar seu aplicativo como dependente de estrutura produz um aplicativo que inclui somente seu aplicativo e suas dependências. Os usuários do aplicativo precisam instalar o tempo de execução do .NET separadamente.

Os dois modos de publicação produzem um executável específico da plataforma por padrão. Aplicativos dependentes de estrutura podem ser criados sem um executável, e esses aplicativos são de plataforma cruzada.

Quando um executável é produzido, você pode especificar a plataforma de destino com um RID (identificador de tempo de execução). Para obter mais informações sobre RIDs, consulte Catálogo de RID do .net.

A tabela a seguir descreve os comandos usados para publicar um aplicativo como dependente da estrutura ou independente, por versão do SDK:

Type SDK 2.1 SDK 3,1 SDK 5,0 Comando
executável dependente de estrutura para a plataforma atual. ✔️ ✔️ dotnet publish
executável dependente de estrutura para uma plataforma específica. ✔️ ✔️ dotnet publish -r <RID> --self-contained false
binário de plataforma cruzada dependente de estrutura. ✔️ ✔️ ✔️ dotnet publish
executável independente. ✔️ ✔️ ✔️ dotnet publish -r <RID>

Para obter mais informações, consulte o comando .net dotnet Publish.

Produzir um executável

Os executáveis não são de plataforma cruzada. Elas são específicas para um sistema operacional e arquitetura de CPU. Ao publicar seu aplicativo e criar um executável, você pode publicar o aplicativo como independente ou dependente de estrutura. A publicação de um aplicativo como independente inclui o tempo de execução do .NET com o aplicativo, e os usuários do aplicativo não precisam se preocupar em instalar o .NET antes de executar o aplicativo. Os aplicativos publicados como dependentes da estrutura não incluem o tempo de execução e as bibliotecas do .NET; somente o aplicativo e as dependências de terceiros são incluídos.

Os comandos a seguir produzem um executável:

Type SDK 2.1 SDK 3,1 SDK 5,0 Comando
executável dependente de estrutura para a plataforma atual. ✔️ ✔️ dotnet publish
executável dependente de estrutura para uma plataforma específica. ✔️ ✔️ dotnet publish -r <RID> --self-contained false
executável independente. ✔️ ✔️ ✔️ dotnet publish -r <RID>

Produzir um binário de plataforma cruzada

Binários de plataforma cruzada são criados quando você publica seu aplicativo como dependente de estrutura, na forma de um arquivo dll . O arquivo dll é nomeado após o seu projeto. Por exemplo, se você tiver um aplicativo chamado word_reader, um arquivo chamado word_reader.dll será criado. Os aplicativos publicados dessa maneira são executados com o dotnet <filename.dll> comando e podem ser executados em qualquer plataforma.

Os binários de plataforma cruzada podem ser executados em qualquer sistema operacional, desde que o tempo de execução do .NET de destino já esteja instalado. Se o tempo de execução do .NET de destino não estiver instalado, o aplicativo poderá ser executado usando um tempo de execução mais recente se o aplicativo estiver configurado para o avanço. Para obter mais informações, consulte roll forward de aplicativos dependentes da estrutura.

O comando a seguir produz um binário de plataforma cruzada:

Type SDK 2.1 SDK 3. x SDK 5,0 Comando
binário de plataforma cruzada dependente de estrutura. ✔️ ✔️ ✔️ dotnet publish

Publicar a estrutura dependente

Os aplicativos publicados como dependentes da estrutura são de plataforma cruzada e não incluem o tempo de execução do .NET. O usuário do seu aplicativo é necessário para instalar o tempo de execução do .NET.

A publicação de um aplicativo como dependente de estrutura produz um binário de plataforma cruzada como um arquivo dll e um executável específico da plataforma destinado à sua plataforma atual. A dll é de plataforma cruzada enquanto o executável não está. por exemplo, se você publicar um aplicativo chamado word_reader e Windows de destino, um word_reader.exe executável será criado junto com word_reader.dll. Ao direcionar para Linux ou macOS, um word_reader executável é criado junto com word_reader.dll. Para obter mais informações sobre RIDs, consulte Catálogo de RID do .net.

Importante

O SDK do .NET 2,1 não produz executáveis específicos da plataforma quando você publica um dependente do App Framework.

O binário de plataforma cruzada do seu aplicativo pode ser executado com o dotnet <filename.dll> comando e pode ser executado em qualquer plataforma. se o aplicativo usar um pacote de NuGet que tenha implementações específicas de plataforma, as dependências de todas as plataformas serão copiadas para a pasta de publicação junto com o aplicativo.

Você pode criar um executável para uma plataforma específica passando os -r <RID> --self-contained false parâmetros para o dotnet publish comando. Quando o -r parâmetro é omitido, um executável é criado para sua plataforma atual. todos os pacotes de NuGet que têm dependências específicas da plataforma para a plataforma de destino são copiados para a pasta de publicação. Se você não precisar de um executável específico da plataforma, poderá especificar <UseAppHost>False</UseAppHost> no arquivo de projeto. para obter mais informações, consulte referência de MSBuild para projetos do SDK do .net.

Vantagens

  • Implantação pequena
    Somente seu aplicativo e suas dependências são distribuídos. O tempo de execução e as bibliotecas do .NET são instalados pelo usuário e todos os aplicativos compartilham o tempo de execução.

  • Plataforma cruzada
    Seu aplicativo e qualquer. A biblioteca baseada em rede é executada em outros sistemas operacionais. Você não precisa definir uma plataforma de destino para seu aplicativo. Para obter informações sobre o formato de arquivo .NET, consulte formato de arquivo de assembly .net.

  • Usa o tempo de execução com patch mais recente
    O aplicativo usa o tempo de execução mais recente (dentro da família principal-secundária do .NET) instalada no sistema de destino. Isso significa que seu aplicativo usa automaticamente a versão mais recente com patches do tempo de execução do .NET. Esse comportamento padrão pode ser substituído. Para obter mais informações, consulte roll forward de aplicativos dependentes da estrutura.

Desvantagens

  • Requer a pré-instalação do tempo de execução
    Seu aplicativo só poderá ser executado se a versão do .NET de destino do seu aplicativo já estiver instalada no sistema host. Você pode configurar o comportamento de roll-forward para que o aplicativo exija uma versão específica do .NET ou permitir uma versão mais recente do .NET. Para obter mais informações, consulte roll forward de aplicativos dependentes da estrutura.

  • O .NET pode ser alterado
    É possível que as bibliotecas e o tempo de execução do .NET sejam atualizados no computador em que o aplicativo é executado. Em casos raros, isso pode alterar o comportamento do seu aplicativo se você usar as bibliotecas .NET, que a maioria dos aplicativos faz. Você pode configurar como seu aplicativo usa versões mais recentes do .NET. Para obter mais informações, consulte roll forward de aplicativos dependentes da estrutura.

A desvantagem a seguir se aplica somente ao SDK do .NET Core 2,1.

  • Use o dotnet comando para iniciar o aplicativo
    Os usuários devem executar o dotnet <filename.dll> comando para iniciar seu aplicativo. O SDK do .NET Core 2,1 não produz executáveis específicos da plataforma para aplicativos que dependem da estrutura publicada.

Exemplos

Publicar um aplicativo dependente da estrutura de plataforma cruzada. Um executável que se destina à sua plataforma atual é criado junto com o arquivo dll .

dotnet publish

Publicar um aplicativo dependente da estrutura de plataforma cruzada. Um executável de 64 bits do Linux é criado junto com o arquivo dll . Este comando não funciona com SDK do .NET Core 2,1.

dotnet publish -r linux-x64 --self-contained false

Publicar autocontido

Publicar seu aplicativo como independente produz um executável específico da plataforma. A pasta de publicação de saída contém todos os componentes do aplicativo, incluindo as bibliotecas .NET e o tempo de execução de destino. O aplicativo é isolado de outros aplicativos .NET e não usa um tempo de execução compartilhado localmente instalado. O usuário do seu aplicativo não é necessário para baixar e instalar o .NET.

O binário executável é produzido para a plataforma de destino especificada. por exemplo, se você tiver um aplicativo chamado word_reader e publicar um executável independente para Windows, um arquivo de word_reader.exe será criado. Publicação para Linux ou macOS, um arquivo de word_reader é criado. A plataforma e a arquitetura de destino são especificadas com o -r <RID> parâmetro para o dotnet publish comando. Para obter mais informações sobre RIDs, consulte Catálogo de RID do .net.

se o aplicativo tiver dependências específicas da plataforma, como um pacote de NuGet que contém dependências específicas da plataforma, eles serão copiados para a pasta de publicação junto com o aplicativo.

Vantagens

  • Versão do controle do .NET
    Você controla qual versão do .NET é implantada com seu aplicativo.

  • Direcionamento específico da plataforma
    Como você precisa publicar seu aplicativo para cada plataforma, você sabe onde seu aplicativo será executado. Se o .NET apresentar uma nova plataforma, os usuários não poderão executar seu aplicativo nessa plataforma até que você libere uma versão direcionada a essa plataforma. Você pode testar seu aplicativo para problemas de compatibilidade antes que os usuários executem seu aplicativo na nova plataforma.

Desvantagens

  • Implantações maiores
    Como seu aplicativo inclui o tempo de execução do .NET e todas as suas dependências de aplicativo, o tamanho do download e o espaço do disco rígido necessários são maiores que uma versão dependente da estrutura .

    Dica

    Você pode reduzir o tamanho da implantação em sistemas Linux em aproximadamente 28 MB usando o modo invariável de globalizaçãodo .net. Isso força seu aplicativo a tratar todas as culturas como a cultura invariável.

    Dica

    A remoção de Il pode reduzir ainda mais o tamanho da sua implantação.

  • Mais difícil de atualizar a versão do .NET
    O tempo de execução do .NET (distribuído com seu aplicativo) só pode ser atualizado com a liberação de uma nova versão do seu aplicativo. No entanto, o .NET atualizará os patches de segurança críticos conforme necessário para a biblioteca do Framework no computador em que seu aplicativo é executado. Você é responsável pela validação de ponta a ponta deste cenário de patch de segurança.

Exemplos

Publicar um aplicativo independente. Um executável macOS 64-bit é criado.

dotnet publish -r osx-x64

Publicar um aplicativo independente. um Windows executável de 64 bits é criado.

dotnet publish -r win-x64

Publicar com imagens ReadyToRun

A publicação com imagens ReadyToRun melhorará o tempo de inicialização do seu aplicativo com o custo de aumentar o tamanho do seu aplicativo. Para publicar com ReadyToRun, consulte ReadyToRun para obter mais detalhes.

Vantagens

  • Tempo de inicialização melhorado
    O aplicativo passará menos tempo executando o JIT.

Desvantagens

  • Tamanho maior
    O aplicativo será maior em disco.

Exemplos

Publicar um aplicativo independente e ReadyToRun. Um executável macOS 64-bit é criado.

dotnet publish -c Release -r osx-x64 -p:PublishReadyToRun=true

Publicar um aplicativo independente e ReadyToRun. um Windows executável de 64 bits é criado.

dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true

Confira também