Migrar do ASP.NET Core no .NET 5 para o .NET 6

Este artigo explica como atualizar um projeto existente do ASP.NET Core no .NET 5 para o .NET 6. Para obter instruções sobre como migrar do ASP.NET Core 3.1 para o .NET 6, consulte Migrar do ASP.NET Core 3.1 para o .NET 6.

Pré-requisitos

Visual Studio 2022 com a carga de trabalho de desenvolvimento Web e do ASP.NET.
SDK do .NET 6

Atualizar a versão do SDK do .NET Core no global.json

Se você recorrer a um arquivo global.json para apontar para uma versão específica do SDK .NET, atualize a propriedade version para a versão do SDK .NET 6 que está instalada. Por exemplo:

{
  "sdk": {
-    "version": "5.0.100"
+    "version": "6.0.100"
  }
}

Atualizar a estrutura de destino

Atualize o TFM (Target Framework Moniker) do arquivo de projeto para net6.0:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
-    <TargetFramework>net5.0</TargetFramework>
+    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

</Project>

Referências do pacote de atualização

No arquivo de projeto, atualize o atributo Microsoft.AspNetCore.* de cada referência de pacote Microsoft.Extensions.* e Version para 6.0.0 ou posterior. Por exemplo:

<ItemGroup>
-    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="5.0.3" />
-    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="5.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="6.0.0" />
+    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="6.0.0" />
</ItemGroup>

Novo modelo de hospedagem

O novo modelo de hospedagem mínima do .NET 6 para aplicativos ASP.NET Core requer apenas um arquivo e algumas linhas de código. Os aplicativos que migram para o .NET 6 não precisam usar o novo modelo de hospedagem mínimo. Para obter mais informações, consulte Os aplicativos que migram para o .NET 6 não precisam usar o novo modelo de hospedagem mínimo na seção a seguir.

O código a seguir do modelo vazio ASP.NET Core cria um aplicativo usando o novo modelo de hospedagem mínimo:

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

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

app.Run();

O modelo de hospedagem mínimo:

Reduz significativamente o número de arquivos e linhas de código necessários para criar um aplicativo. Apenas um arquivo é necessário com quatro linhas de código.
Unifica Startup.cs e Program.cs em um único arquivo Program.cs.
Usa instruções de nível superior para minimizar o código necessário para um aplicativo.
Usa diretivas globais using para eliminar ou minimizar o número de linhas de using instrução necessárias.

O código a seguir exibe os arquivos Startup.cs e Program.cs de um modelo de aplicativo Web do .NET 5 (páginas Razor) com instruções using não utilizadas removidas.

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

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

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddRazorPages();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

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

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
            });
        }
    }
}

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

namespace WebAppRPv5
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

No ASP.NET Core no .NET 6, o código anterior é substituído pelo seguinte:

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

O exemplo anterior do ASP.NET Core no .NET 6 mostra como:

ConfigureServicesserá substituída porWebApplication.Services.
builder.Build() retorna um configurado WebApplication para a variável app. Configure é substituído por chamadas de configuração para os mesmos serviços usando app.

Exemplos detalhados de migração do código ASP.NET Core no .NET 5 Startup para o .NET 6 usando o modelo de hospedagem mínimo são fornecidos posteriormente neste documento.

Há algumas alterações nos outros arquivos gerados para o modelo de Aplicativo Web:

Index.cshtml e Privacy.cshtml tiveram as instruções using não utilizadas removidas.
RequestId in Error.cshtml é declarado como um tipo de referência anulável (NRT):

- public string RequestId { get; set; }
+ public string? RequestId { get; set; }

Os padrões de nível de log foram alterados nos appsettings.json e appsettings.Development.json:

- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"

No código de modelo do ASP.NET Core anterior, "Microsoft": "Warning" foi alterado para "Microsoft.AspNetCore": "Warning". Essa alteração resulta no registro em log de todas as mensagens informativas do Microsoft namespace , excetoMicrosoft.AspNetCore. Por exemplo, Microsoft.EntityFrameworkCore agora está registrado no nível informativo.

Para obter mais detalhes sobre o novo modelo de hospedagem, consulte a seção perguntas frequentes . Para obter mais informações sobre a adoção de NRTs e análise de estado nulo do compilador .NET, consulte a seção NRTs (tipos de referência anuláveis) e a seção de análise estática de estado nulo do compilador .NET .

Aplicativos migrando para ou usando o 6.0 ou posterior não precisam usar o novo modelo de hospedagem mínimo

O uso de Startup e do Host Genérico, utilizados pelos modelos do ASP.NET Core 3.1 e 5.0, é totalmente suportado.

Usar Inicialização com o novo modelo de hospedagem mínima

ASP.NET Core aplicativos 3.1 e 5.0 podem usar seu Startup código com o novo modelo de hospedagem mínima. Usar Startup com o modelo de hospedagem mínimo tem as seguintes vantagens:

Nenhuma reflexão oculta é usada para chamar a Startup classe.
O código assíncrono pode ser escrito porque o desenvolvedor tem controle sobre a chamada para Startup.
Pode-se escrever o código que intercala ConfigureServices e Configure.

Uma pequena limitação ao usar Startup com o novo modelo de hospedagem mínimo é que, para injetar uma dependência em Configure, o serviço em Program.cs deve ser resolvido manualmente.

Considere o seguinte código gerado pelo modelo ASP.NET Core 3.1 ou 5.0 Razor Pages:

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

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

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

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

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

O código anterior migrou para o novo modelo de hospedagem mínimo:

using Microsoft.AspNetCore.Builder;

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();

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

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

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

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

No código anterior, o if (env.IsDevelopment()) bloco é removido porque, no modo de desenvolvimento, o middleware da página de exceção do desenvolvedor está habilitado por padrão. Para obter mais informações, consulte Diferenças entre os modelos de hospedagem do ASP.NET Core no .NET 5 e do .NET 6 na próxima seção.

Ao usar um contêiner de DI (injeção de dependência personalizada), adicione o seguinte código realçado:

using Autofac;
using Autofac.Extensions.DependencyInjection;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

// Using a custom DI container.
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Host.ConfigureContainer<ContainerBuilder>(startup.ConfigureContainer);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

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

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    //  Using a custom DI container
    public void ConfigureContainer(ContainerBuilder builder)
    {
        // Configure custom container.
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

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

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

Ao usar o modelo de hospedagem mínima, o middleware de roteamento de ponto de extremidade encapsula todo o pipeline de middleware, portanto, não é necessário ter chamadas explícitas para UseRouting ou UseEndpoints para registrar rotas. UseRouting ainda pode ser usado para especificar em que local ocorre a correspondência de rotas, mas UseRouting não precisa ser chamado explicitamente se as rotas devem ser correspondidas no início do pipeline do middleware.

No código a seguir, as chamadas para UseRouting e UseEndpoints são removidas de Startup. MapRazorPages é chamado em Program.cs:

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

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        //app.UseRouting();

        //app.UseEndpoints(endpoints =>
        //{
        //    endpoints.MapRazorPages();
        //});
    }
}

using Microsoft.AspNetCore.Builder;

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.MapRazorPages();

app.Run();

Ao usar Startup com o novo modelo de hospedagem mínimo, tenha em mente a seguinte diferença:

Program.cs controla a instanciação e o tempo de vida da Startup classe.
Quaisquer serviços adicionais injetados no Configure método precisam ser resolvidos manualmente pela Program classe.

Diferenças entre os modelos de hospedagem do ASP.NET Core no .NET 5 e no .NET 6

No modo de desenvolvimento, o middleware da página de exceção do desenvolvedor é habilitado por padrão.
O nome do aplicativo usa como padrão o nome do assembly do ponto de entrada: Assembly.GetEntryAssembly().GetName().FullName. Ao usar o WebApplicationBuilder em uma biblioteca, altere explicitamente o nome do aplicativo para o assembly da biblioteca para permitir que a descoberta de parte do aplicativo do MVC funcione. Consulte Alterar a raiz do conteúdo, o nome do aplicativo e o ambiente neste documento para obter instruções detalhadas.
O middleware de roteamento de ponto de extremidade encapsula todo o pipeline de middleware, portanto, não é necessário ter chamadas explícitas para UseRouting ou UseEndpoints para registrar rotas. UseRouting ainda pode ser usado para especificar em que local ocorre a correspondência de rotas, mas UseRouting não precisa ser chamado explicitamente se as rotas devem ser correspondidas no início do pipeline do middleware.
O pipeline é criado antes de qualquer IStartupFilter execução, portanto, as exceções causadas durante a criação do pipeline não são visíveis para a IStartupFilter cadeia de chamadas.
Algumas ferramentas, como migrações de EF, usam Program.CreateHostBuilder para acessar o do IServiceProvider aplicativo para executar a lógica personalizada no contexto do aplicativo. Essas ferramentas foram atualizadas para usar uma nova técnica para executar a lógica personalizada no contexto do aplicativo. As Migrações do Entity Framework são um exemplo de uma ferramenta que usa Program.CreateHostBuilder dessa forma. Estamos trabalhando para garantir que as ferramentas sejam atualizadas para usar o novo modelo.
Ao contrário da Startup classe, o host mínimo não configura automaticamente um escopo DI ao instanciar o provedor de serviços. Para contextos em que um escopo é necessário, é necessário invocar IServiceScope com IServiceScopeFactory.CreateScope para criar uma instância de um novo escopo. Para obter mais informações, confira como resolver um serviço na inicialização do aplicativo.
Não é possívelalterar nenhuma configuração de host, como nome do aplicativo, ambiente ou raiz de conteúdo após a criação do WebApplicationBuilder. Para obter instruções detalhadas sobre como alterar as configurações do host, consulte Personalizar IHostBuilder ou IWebHostBuilder. As seguintes APIs realçadas geram uma exceção:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

// WebHost

try
{
    builder.WebHost.UseContentRoot(Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseEnvironment(Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.ApplicationKey, "ApplicationName2");
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.ContentRootKey, Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.EnvironmentKey, Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

// Host
try
{
    builder.Host.UseEnvironment(Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    // TODO: This does not throw
    builder.Host.UseContentRoot(Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

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();

A Startup classe não pode ser usada de WebApplicationBuilder.Host ou WebApplicationBuilder.WebHost. O código realçado a seguir gera uma exceção:

var builder = WebApplication.CreateBuilder(args);

try
{
    builder.Host.ConfigureWebHostDefaults(webHostBuilder =>
    {
        webHostBuilder.UseStartup<Startup>();
    });
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    throw;    
}

builder.Services.AddRazorPages();

var app = builder.Build();

var builder = WebApplication.CreateBuilder(args);

try
{
    builder.WebHost.UseStartup<Startup>();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    throw;    
}

builder.Services.AddRazorPages();

var app = builder.Build();

A implementação de IHostBuilder em WebApplicationBuilder (WebApplicationBuilder.Host) não adia a execução dos métodos ConfigureServices, ConfigureAppConfiguration ou ConfigureHostConfiguration. Não adiar a execução permite que o código use WebApplicationBuilder para observar as alterações feitas no IServiceCollection e IConfiguration. O exemplo a seguir só adiciona Service1 como um IService:

using Microsoft.Extensions.DependencyInjection.Extensions;

var builder = WebApplication.CreateBuilder(args);

builder.Host.ConfigureServices(services =>
{
    services.TryAddSingleton<IService, Service1>();
});

builder.Services.TryAddSingleton<IService, Service2>();

var app = builder.Build();

// Displays Service1 only.
Console.WriteLine(app.Services.GetRequiredService<IService>());

app.Run();

class Service1 : IService
{
}

class Service2 : IService
{
}

interface IService
{
}

No código anterior, o builder.Host.ConfigureServices retorno de chamada é chamado embutido em vez de ser adiado até builder.Build ser chamado. Isso significa que Service1 é adicionado ao IServiceCollection antes do Service2 e resulta na resolução de Service1 para IService.

Compilando bibliotecas para ASP.NET Core no .NET 6

O ecossistema do .NET existente criou extensibilidade em torno de IServiceCollection, IHostBuilder e IWebHostBuilder. Essas propriedades estão disponíveis como WebApplicationBuilderServices, Hoste WebHost.

WebApplication implementa ambos Microsoft.AspNetCore.Builder.IApplicationBuilder e Microsoft.AspNetCore.Routing.IEndpointRouteBuilder.

Esperamos que os autores da biblioteca continuem direcionando IHostBuilder, IWebHostBuilder, IApplicationBuildere IEndpointRouteBuilder ao criar ASP.NET Core componentes específicos. Isso garante que o middleware, o manipulador de rotas ou outros pontos de extensibilidade continuem funcionando em diferentes modelos de hospedagem.

Perguntas frequentes (FAQ)

O novo modelo de hospedagem mínimo é menos capaz?

Não. O novo modelo de hospedagem é funcionalmente equivalente em 98% dos cenários suportados pelo IHostBuilder e pelo IWebHostBuilder. Há alguns cenários avançados que exigem soluções alternativas específicas em IHostBuilder, mas esperamos que sejam extremamente raros.
O modelo de hospedagem genérico foi preterido?

Não. O modelo de hospedagem genérico é um modelo alternativo que tem suporte indefinidamente. O host genérico sustenta o novo modelo de hospedagem e ainda é a principal maneira de hospedar aplicativos baseados em trabalho.
Preciso migrar para o novo modelo de hospedagem?

Não. O novo modelo de hospedagem é a maneira preferida de hospedar novos aplicativos usando o .NET 6 ou posterior, mas você não é forçado a alterar o layout do projeto em aplicativos existentes. Isso significa que os aplicativos podem atualizar do .NET 5 para o .NET 6 alterando a estrutura de destino no arquivo de projeto de net5.0 para net6.0. Para obter mais informações, consulte a seção Atualizar a estrutura de destino neste artigo. No entanto, recomendamos que os aplicativos migrem para o novo modelo de hospedagem para aproveitar os novos recursos disponíveis apenas para o novo modelo de hospedagem.
Preciso usar instruções de nível superior?

Não. Todos os novos modelos de projeto usam instruções de nível superior, mas as novas APIs de hospedagem podem ser usadas em qualquer aplicativo .NET 6 para hospedar um webserver ou aplicativo Web.
Onde eu coloco o estado que foi armazenado como campos na minha Program ou Startup classe?

É altamente recomendável usar a DI (injeção de dependência) para fluir o estado em aplicativos ASP.NET Core.

Há duas abordagens para armazenar o estado fora do DI:
- Armazene o estado em outra classe. O armazenamento em uma classe pressupõe um estado estático que pode ser acessado de qualquer lugar no aplicativo.
- Use a classe gerada por instruções de nível superior para armazenar o Program estado. Usar Program para armazenar o estado é a abordagem semântica:
```
var builder = WebApplication.CreateBuilder(args);

ConfigurationValue = builder.Configuration["SomeKey"] ?? "Hello";

var app = builder.Build();

app.MapGet("/", () => ConfigurationValue);

app.Run();

partial class Program
{
    public static string? ConfigurationValue { get; private set; }
}
```
E se eu estivesse usando um contêiner de injeção de dependência personalizado?

Há suporte para contêineres de DI personalizados. Para obter um exemplo, consulte o contêiner de DI (injeção de dependência personalizada).
WebApplicationFactory e TestServer ainda funcionam?

Sim. WebApplicationFactory<TEntryPoint> é a maneira de testar o novo modelo de hospedagem. Para obter um exemplo, consulte Testar com WebApplicationFactory ou TestServer.

Blazor

Depois de seguir as diretrizes anteriores neste artigo para atualizar um aplicativo para o .NET 6, adote recursos específicos seguindo os links no What's new no ASP.NET Core no .NET 6.

Para adotar todos os novos recursos 6.0 para Blazor aplicativos, recomendamos o seguinte processo:

Crie um projeto 6.0 Blazor novo a partir de um dos modelos de projeto Blazor. Para obter mais informações, confira Ferramentas para ASP.NET Core Blazor.
Mova os componentes e o código do aplicativo para o aplicativo 6.0 fazendo modificações para adotar os novos recursos do .NET 6.

Migrando projetos do SPA

Migrando aplicativos Angular de extensões SPA

Consulte este problema do GitHub

Migrando aplicativos React de extensões SPA

Consulte Migrando aplicativos React de Extensões de Spaneste problema do GitHub

Atualizar imagens do Docker

Para aplicativos que usam o Docker, atualize suas instruções e scripts do DockerfileFROM. Use uma imagem base que inclua o ASP.NET Core no runtime do .NET 6. Considere a seguinte docker pull diferença de comando entre ASP.NET Core no .NET 5 e no .NET 6:

- docker pull mcr.microsoft.com/dotnet/aspnet:5.0
+ docker pull mcr.microsoft.com/dotnet/aspnet:6.0

Consulte o problema do GitHub Alteração significativa: formato padrão do logger do console definido como JSON.

Alterações no SDK do ASP.NET Core Razor

O Razor compilador agora aproveita o novo recurso geradores de origem para gerar arquivos C# compilados das Razor exibições e páginas em um projeto. Em versões anteriores:

A compilação dependia dos alvos RazorGenerate e RazorCompile para produzir o código gerado. Essas metas não são mais válidas. No .NET 6, a geração de código e a compilação têm suporte por uma única chamada para o compilador. RazorComponentGenerateDependsOn ainda há suporte para especificar dependências que são necessárias antes da execução do build.
Um assembly separado Razor, AppName.Views.dll, foi gerado que continha os tipos de exibição compilados em um aplicativo. Esse comportamento foi preterido e um único assembly AppName.dll é produzido que contém os tipos de aplicativo e as exibições geradas.
Os tipos de aplicativo em AppName.Views.dll eram públicos. No .NET 6, os tipos de aplicativo estão no AppName.dll, mas são internal sealed. Os aplicativos que fazem a descoberta de tipos em AppName.Views.dll não serão capazes de fazer a descoberta de tipos em AppName.dll. O seguinte mostra a alteração da API:

- public class Views_Home_Index : global::Microsoft.AspNetCore.Mvc.Razor.RazorPage<dynamic>
+ internal sealed class Views_Home_Index : global::Microsoft.AspNetCore.Mvc.Razor.RazorPage<dynamic>

Faça as seguintes alterações:

As propriedades a seguir não são mais aplicáveis com o modelo de compilação de etapa única.
- RazorTargetAssemblyAttribute
- RazorTargetName
- EnableDefaultRazorTargetAssemblyInfoAttributes
- UseRazorBuildServer
- GenerateRazorTargetAssemblyInfo
- GenerateMvcApplicationPartsAssemblyAttributes

Para obter mais informações, confira RazorO compilador não produz mais um assembly Views.

Modelos de projeto usam o Servidor Duende Identity

Os modelos de projeto agora usam o Servidor DuendeIdentity.

Importante

O Duende Identity Server é um produto de software livre com um contrato de licença recíproco. Se você planeja usar o Duende Identity Server em produção, talvez seja necessário obter uma licença comercial do Duende Software e pagar uma taxa de licença. Para obter mais informações, consulte Duende Software: Licenses.

Para saber como usar o Microsoft Azure Active Directory para ASP.NET Core Identity, consulte Identity (repositório GitHub do dotnet/aspnetcore).

Adicione uma propriedade DbSet<Key>, nomeada Keys, a cada IdentityDbContext para atender à nova exigência da versão atualizada de IPersistedGrantDbContext. As chaves são necessárias como parte do contrato com os repositórios do Duende Identity Server.

public DbSet<Key> Keys { get; set; }

Observação

As migrações existentes devem ser recriadas para o Servidor Duende Identity .

Exemplos de código migrados para o ASP.NET Core no .NET 6

Exemplos de código migrados para o novo modelo de hospedagem mínimo em 6.0

Alterações da falha

Use os artigos sobre alterações interruptivas no .NET para encontrar alterações significativas que podem se aplicar ao atualizar um aplicativo para uma versão mais recente do .NET.

Para obter mais informações, consulte o repositório GitHub de Comunicados (aspnet/Announcements, 6.0.0 rótulo): inclui informações interruptivas e não interruptivas.

NRTs (tipos de referência anuláveis) e análise estática de estado nulo do compilador do .NET

os modelos de projeto do ASP.NET Core usam NRTs (tipos de referência anuláveis) e o compilador do .NET executa uma análise estática de estado nulo. Esses recursos foram lançados com o C# 8 e são habilitados por padrão para aplicativos gerados usando ASP.NET Core no .NET 6 (C# 10) ou posterior.

Os avisos de análise estática de estado nulo do compilador do .NET podem servir como um guia para atualizar um exemplo de documentação ou um aplicativo de exemplo localmente ou ser ignorados. A análise estática de estado nulo pode ser desabilitada definindo Nullable como disable no arquivo de projeto do aplicativo, o que recomendamos apenas para exemplos de documentação e aplicativos de exemplo se os avisos do compilador estiverem distraindo ao aprender sobre o .NET. Não recomendamos desabilitar a verificação de estado nulo em projetos de produção.

Para obter mais informações sobre NRTs, a propriedade MSBuild Nullable e a atualização de aplicativos (incluindo #pragma diretrizes), consulte os seguintes recursos na documentação do C#:

Módulo do ASP.NET Core (ANCM)

Se o Módulo do ASP.NET Core (ANCM) não foi um componente selecionado quando o Visual Studio foi instalado ou se uma versão anterior do ANCM foi instalada no sistema, baixe o Instalador de Pacote de Hospedagem do .NET Core (download direto) mais recente e execute o instalador. Para obter mais informações, confira Pacote de Hospedagem.

Alteração do nome do aplicativo

No .NET 6, WebApplicationBuilder normaliza o caminho raiz do conteúdo para terminar com um DirectorySeparatorChar. A maioria dos aplicativos que estão migrando de HostBuilder ou WebHostBuilder não terão o mesmo nome de aplicativo porque não são normalizados. Para obter mais informações, consulte SetApplicationName

Recursos adicionais

Exemplos de código migrados para o novo modelo de hospedagem mínimo em 6.0

Comentários

Esta página foi útil?

Last updated on 2026-01-09

Compartilhar via

Migrar do ASP.NET Core no .NET 5 para o .NET 6

Pré-requisitos

Atualizar a versão do SDK do .NET Core no global.json

Atualizar a estrutura de destino

Referências do pacote de atualização

Novo modelo de hospedagem

Aplicativos migrando para ou usando o 6.0 ou posterior não precisam usar o novo modelo de hospedagem mínimo

Usar Inicialização com o novo modelo de hospedagem mínima

Diferenças entre os modelos de hospedagem do ASP.NET Core no .NET 5 e no .NET 6

Compilando bibliotecas para ASP.NET Core no .NET 6

Perguntas frequentes (FAQ)

Blazor

Migrando projetos do SPA

Migrando aplicativos Angular de extensões SPA

Migrando aplicativos React de extensões SPA

Atualizar imagens do Docker

Alterações no SDK do ASP.NET Core Razor

Modelos de projeto usam o Servidor Duende Identity

Exemplos de código migrados para o ASP.NET Core no .NET 6

Alterações da falha

NRTs (tipos de referência anuláveis) e análise estática de estado nulo do compilador do .NET

Módulo do ASP.NET Core (ANCM)

Alteração do nome do aplicativo

Recursos adicionais

Comentários

Recursos adicionais