ASP .NET Core - Self-contained ou framework-dependent ?

ASP .NET Core - Self-contained, framework-dependent e ReadyToRun

Neste artigo vamos comparar os modos de publicação disponíveis para aplicações ASP .NET Core : self-contained framework-dependent e ReadyToRun(R2R).

A ASP.NET Core tem como modos de publicação principais as abordagens: framework-dependent e self-contained.

O modo framework-dependent ou dependente do framework, produz um aplicativo que inclui somente seu aplicativo e suas dependências. Os usuários do aplicativo precisam instalar o runtime da plataforma .NET separadamente.

O modo self-contained ou independente, inclui o runtime e as bibliotecas do .net, seu aplicativo e suas dependências. Os usuários do aplicativo podem executá-lo em um computador que não tenha o runtime da platafoarma .NET instalado.

Os dois modos de publicação produzem um executável específico da plataforma por padrão. Aplicativos usando a abordagem dependente de framework podem ser criados sem um executável, e esses aplicativos são multiplataforma.

Nota: Quando um executável é produzido, você pode especificar a plataforma de destino com um RID (identificador de tempo de execução)

Os comandos usados para publicar uma aplicação usando essas abordagens, considerando apenas as versões 3.1 e 5.0, são :

Tipo	comando
Criar executável dependente de framework para a plataforma atual	dotnet publish
Criar executável dependente de framework para uma plataforma específica	dotnet publish -r <RID> contained false
Criar binário dependente de framework multiplataforma	dotnet publish
Criar executável independente	dotnet publish -r <RID>

Lembrando que os executáveis não são multiplataforma. Eles são específicos 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 framework.

Os binários multiplataforma são criados quando você publica seu aplicativo como dependente de framework, na forma de um arquivo dll. Se você tiver um aplicativo chamado teste, um arquivo chamado teste.dll será criado. Os aplicativos publicados dessa forma são executados com o comando dotnet run <nome_arquivo.dll> e podem ser executados em qualquer plataforma.

Assim os binários multiplataforma podem ser executados em qualquer sistema operacional, desde que o runtime do .NET de destino já esteja instalado. Se o runtime do .NET de destino não estiver instalado, o aplicativo pode ser executado usando um runtime mais recente se o aplicativo estiver configurado para roll-forward(*).

Quando você executa um aplicativo de uma implantação dependente de framework - dotnet teste.dll, ou de um executável dependente de framework com teste.exe ,o executável dotnet é o host para o aplicativo.

O host escolhe a versão de patch mais recente instalada no computador. Por exemplo, se você especificar net5.0 em seu arquivo de projeto e a versão 5.0.2 for o runtime mais recente do .NET instalado, o runtime 5.0.2 será usado.

Se nenhuma versão 5.0.* aceitável for encontrada, uma nova versão 5.* será usada. Por exemplo, se você especificar net5.0 e só o 5.1.0 estiver instalado, o aplicativo será executado usando o runtime 5.1.0. Esse comportamento é conhecido como "roll forward de versão secundária". As versões inferiores também não serão consideradas. Quando nenhum runtime aceitável estiver instalado, o aplicativo não será executado.

Vantagens e desvantagens da instalação dependente de framework

A publicação de um aplicativo como dependente de framework produz um binário multiplataforma como um arquivo dll e um executável específico de plataforma destinado à sua plataforma atual. A dll é multiplataforma enquanto o executável não é.

A seguir as vantagens em usar esta abordagem (considerando apenas as versões 3.1 e 5.0)

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

Multiplataforma
Seu aplicativo e qualquer biblioteca baseada na plataforma .NET será executada em outros sistemas operacionais. Você não precisa definir uma plataforma de destino para seu aplicativo.

Usa o runtime com patch mais recente
O aplicativo usa o runtime 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 runtime do .NET. Esse comportamento padrão pode ser substituído.

As desvantagens são :

Requer a pré-instalação do runtime para 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.
A versão do .NET pode ser alterada : É possível que as bibliotecas e o runtime do .NET sejam atualizados no computador em que o aplicativo for executado. Em casos raros, isso pode alterar o comportamento do seu aplicativo se você usar as bibliotecas .NET, que a maioria dos aplicativos usa. Você pode configurar como seu aplicativo usa versões mais recentes do .NET.

Vantagens e desvantagens da instalação independente

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 runtime de destino. O aplicativo é isolado de outros aplicativos .NET e não usa um runtime compartilhado localmente instalado.

Vantagens

Controle da versão 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

O tamanho das implantações é maior : Como seu aplicativo inclui o runtime 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 de framework.
É mais difícil atualizar a versão do .NET : O runtime 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.

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 seu tamanho.

O tempo e a latência de inicialização do aplicativo NET podem ser melhorados compilando os assemblies do aplicativo no formato ReadyToRun (R2R). R2R é uma forma de compilação antecipada (AOT).

Os binários R2R melhoram o desempenho de inicialização reduzindo a quantidade de trabalho que o compilador just-in-time (JIT) precisa fazer enquanto seu aplicativo é carregado. Os binários contêm código nativo semelhante ao que o JIT produziria.

No entanto, os binários R2R são maiores porque contêm código de linguagem intermediária (IL), que ainda é necessário para alguns cenários, e a versão nativa do mesmo código. R2R está disponível apenas quando você publica um aplicativo que visa ambientes de tempo de execução específicos (RID), como Linux x64 ou Windows x64.

Para compilar seu projeto como ReadyToRun, o aplicativo deve ser publicado com a propriedade PublishReadyToRun definida como true.

Existem duas maneiras de publicar seu aplicativo como ReadyToRun:

1- Especificar o sinalizador PublishReadyToRun diretamente para o comando dotnet publish.

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

2- Especificar a propriedade no projeto segundo o roteiro:

Incluir a configuração <PublishReadyToRun> no projeto;

Publicar a aplicação sem parâmetros especiais

dotnet publish -c Release -r win-x64

Vantagens

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

Desvantagens

Tamanho maior : O aplicativo será maior em disco.

E estamos conversados.

"Brame o mar e a sua plenitude; o mundo, e os que nele habitam.
Os rios batam as palmas; regozijem-se também as montanhas,
Perante a face do Senhor, porque vem a julgar a terra; com justiça julgará o mundo, e o povo com eqüidade."
Salmos 98:7-9

Referências:

José Carlos Macoratti