NET 6 - Migrando para ASP .NET Core 6

NET 6 - Migrando para ASP .NET Core 6 - I

Hoje vou apresentar um roteiro básico de migração para ASP .NET Core no NET 6.

O NET 6 já esta na versão RC2, e, em novembro, será lançado a versão final de produção. Até lá pouca coisa deve mudar no que já temos implementado até agora. (É isso que esperamos...)

A seguir vou apresentar um roteiro básico e resumido das alterações feitas que afetam as aplicações ASP .NET Core e que devem ser consideradas para migrar uma aplicação da versão anterior para a nova versão. (Essas informações foram obtidas deste link )

Usando WebApplication e WebApplicationBuilder

O .NET 6 apresenta um novo modelo de hospedagem para aplicativos ASP.NET Core. Este modelo é simplificado e reduz a quantidade de código padrão necessário para colocar um aplicativo ASP.NET Core básico em funcionamento. (veja meu artigo sobre as Minimal APIs)

O código gerado pelo template ASP .NET Core Empty, apresenta o código abaixo no arquivo Program:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World");

app.Run();

Este modelo unifica o Startup.cs e Program.cs em uma experiência de arquivo único que tira proveito de instruções de nível superior para remover qualquer código clichê.

Assim os projetos ASP .NET Core não possuem mais o arquivo Startup e o arquivo Program agora contém todo o código necessário para inicialização da aplicação.

Assim o código existente nos métodos ConfigureServices e Configure da extinta classe Startup estão presentes no arquivo Program conforme exemplo a seguir:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Neste exemplo vemos que ConfigureServices(IServiceCollection) pode ser configurado usando WebApplicationBuilder.Services e Configure (IApplicationBuilder ...) pode ser configurado usando WebApplication.

Diferenças no modelo de hospedagem

As principais diferenças no NET 6 são:

O middleware da página de exceção do desenvolvedor é ativado quando o ambiente é Development;
O nome da aplicação sempre é padronizado como o nome do assembly do ponto de entrada Assembly.GetEntryAssembly().GetName().FullName. Ao usar o WebApplicationBuilder em uma biblioteca, você precisará alterar explicitamente o nome do aplicativo para o assembly da biblioteca para permitir que a descoberta de parte do aplicativo MVC funcione (localizando controladores, visualizações etc.)
O middleware de roteamento de endpoint envolve todo o pipeline de middleware. Isso significa que não há necessidade de chamadas explícitas para UseEndpoints para registrar rotas. UseRouting ainda pode ser usado para mover onde ocorre a correspondência de rota.
O pipeline final é criado antes que qualquer IStartupFilter seja executado. Isso significa que as exceções causadas durante a construção do pipeline principal não serão visíveis para a cadeia de chamadas IStartupFilter.
Algumas ferramentas (como migrações EF) usam Program.CreateHostBuilder para acessar o IServiceProvider do aplicativo para executar a lógica personalizada no contexto do aplicativo. Essas ferramentas foram atualizadas para usar uma nova técnica para conseguir o mesmo resultado.
Não é possível alterar nenhuma configuração de host (nome do aplicativo, ambiente ou raiz do conteúdo) após a criação do WebApplicationBuilder.
Não é possível usar a classe Startup por meio de WebApplicationBuilder.Host ou WebApplicationBuilder.WebHost.
A implementação de IHostBuilder em WebApplicationBuilder (WebApplicationBuilder.Host) não adia a execução dos métodos ConfigureServices, ConfigureAppConfiguration ou ConfigureHostConfiguration. Isso permite que o código usando WebApplicationBuilder observe as alterações feitas em IServiceCollection e IConfiguration.

Com essas alterações o novo modelo de hospedagem deve ser funcionalmente equivalente em 98% ao que você pode fazer com o IHostBuilder e o IWebHostBuilder. Existem cenários mais avançados (os 2%) que exigirão recursos específicos no IHostBuilder, mas espera-se que isso seja extremamente raro.

O modelo de host genérico é um modelo alternativo que continuará funcionando para sempre. O host genérico ainda sustenta o novo modelo de hospedagem e ainda é a principal forma de hospedar aplicativos.

Este novo modelo deverá ser a forma preferida de hospedar aplicativos ASP.NET Core do .NET 6 em diante, mas você não é forçado a alterar o layout do projeto. Isso significa que você pode atualizar do .NET 5 para o .NET 6.0, alterando a tag target framework em seu arquivo de projeto de net5.0 para net6.0.

Se você quiser pode também manter a classe Startup nos seus projetos. A seguir um exemplo de como fazer isso no código de migração :

1- Program.cs

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

2- Startup.cs

class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

public IConfiguration Configuration { get; }

public void ConfigureServices(IServiceCollection services)
{ }

public void Configure(IApplicationBuilder app, IWebHostEnvironment environment)
{ }
}

Existem algumas diferenças aqui:

Você controla a instanciação e o tempo de vida da classe Startup;
Quaisquer serviços adicionais injetados no método Configure precisam ser resolvidos manualmente por sua classe Program;

Na próxima parte do artigo vou apresentar como realizar as principais tarefas relacionadas com os novos recursos e o código de migração usado para isto.

"E, ao pôr do sol, todos os que tinham enfermos de várias doenças lhos traziam; e, pondo as mãos sobre cada um deles, 'Jesus' os curava."
Lucas 4:40

Referências:

José Carlos Macoratti