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

Este artigo explica como atualizar um ASP.NET Core existente no projeto .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 ASP.NET e desenvolvimento web .
SDK do .NET 6

Atualize a versão do SDK do .NET em global.json

Se confiar num global.json arquivo para direcionar uma versão específica do SDK .NET, atualize a version propriedade para a versão do SDK .NET 6 instalada. Por exemplo:

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

Atualizar a estrutura de destino

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

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

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

</Project>

Atualizar referências de pacotes

No ficheiro de projeto, atualize o atributo Microsoft.AspNetCore.* de cada referência de pacote Microsoft.Extensions.* e Version para 6.0.0 ou uma versão 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ínima. Para obter mais informações, consulte Os aplicativos que migram para o .NET 6 não precisam usar o novo modelo de hospedagem mínima 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ínima:

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

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

app.Run();

O modelo de hospedagem mínima:

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 uma aplicação.
Usa diretivas globais using para eliminar ou minimizar o número necessário de linhas de instruçãousing.

O código a seguir exibe os ficheiros Startup.cs e Program.cs de um modelo de Aplicação Web do .NET 5 (Razor Pages) com as 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 de ASP.NET Core no .NET 6 anterior mostra como:

ConfigureServices é substituído por WebApplication.Services.
builder.Build() retorna um WebApplication configurado 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 ASP.NET Core no código .NET 5 Startup para o .NET 6 usando o modelo de hospedagem mínima 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 têm as declarações não utilizadas using 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 em appsettings.json e appsettings.Development.json.

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

No código do modelo anterior de ASP.NET Core, o "Microsoft": "Warning" foi alterado para "Microsoft.AspNetCore": "Warning". Essa alteração resulta no registro de todas as mensagens informativas do Microsoft namespace, excetoMicrosoft.AspNetCore. Por exemplo, Microsoft.EntityFrameworkCore agora é 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 Nullable reference types (NRTs) e .NET compiler null-state static analysis .

Os aplicativos que migram para ou usam a versão 6.0 ou posterior não precisam usar o novo modelo de hospedagem mínima

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

Use a inicialização com o novo modelo de hospedagem mínima

ASP.NET aplicativos Core 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ínima tem as seguintes vantagens:

Nenhum reflexo oculto é usado para chamar a Startup classe.
O código assíncrono pode ser escrito porque o desenvolvedor controla a chamada para Startup.
Código pode ser escrito que intercala ConfigureServices e Configure.

Uma pequena limitação no uso de Startup com o novo modelo de hospedagem mínima é que, para injetar uma dependência no 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ínima:

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, a middleware da página de exceção do desenvolvedor é habilitada por padrão. Para obter mais informações, consulte Diferenças entre o ASP.NET Core nos modelos de hospedagem .NET 5 e .NET 6 na próxima seção.

Ao usar um contêiner de injeção de dependência (DI) personalizado, 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 endpoints envolve todo o pipeline de middleware; portanto, não há necessidade de ter chamadas explícitas para UseRouting ou UseEndpoints para registrar rotas. UseRouting ainda pode ser usado para especificar onde a combinação de rotas ocorre, mas UseRouting não precisa ser explicitamente chamada se as rotas devem ser combinadas no início do pipeline de middleware.

No código a seguir, as chamadas para UseRouting e UseEndpoints são removidas do 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ínima, tenha em mente a seguinte diferença:

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

Diferenças entre o ASP.NET Core nos modelos de hospedagem .NET 5 e .NET 6

No modo de desenvolvimento, o middleware da página de exceção do desenvolvedor é habilitado por padrão.
O nome do aplicativo assume como padrão o nome do assembly do ponto de entrada: Assembly.GetEntryAssembly().GetName().FullName. Ao usar o WebApplicationBuilder numa biblioteca, altere explicitamente o nome da aplicação para o assembly da biblioteca para permitir que a descoberta de partes da aplicação 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 endpoint encapsula todo o pipeline de middleware, portanto, não há necessidade de chamadas explícitas a `UseRouting` ou `UseEndpoints` para registrar rotas. UseRouting ainda pode ser usado para especificar onde a combinação de rotas ocorre, mas UseRouting não precisa ser explicitamente chamada se as rotas devem ser combinadas no início do pipeline de middleware.
O pipeline é criado antes de qualquer IStartupFilter execução, portanto, as exceções causadas durante a construção do pipeline não são visíveis para a IStartupFilter cadeia de chamadas.
Algumas ferramentas, como as migrações EF, usam Program.CreateHostBuilder para aceder à aplicação IServiceProvider e executar lógica personalizada no contexto da aplicação. Essas ferramentas foram atualizadas para usar uma nova técnica para executar lógica personalizada no contexto do aplicativo. O Entity Framework Migrations é um exemplo de uma ferramenta que usa Program.CreateHostBuilder dessa maneira. 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 onde um escopo é necessário, é necessário invocar IServiceScope com IServiceScopeFactory.CreateScope para instanciar um novo escopo. Para obter mais informações, consulte como resolver um serviço na inicialização do aplicativo.
Não é possível alterar 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 lançam 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 a partir 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 IHostBuilder implementação 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 usando WebApplicationBuilder observe as alterações feitas no IServiceCollection e no 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 callback de builder.Host.ConfigureServices é chamado diretamente em vez de ser adiado até builder.Build ser chamado. Isso significa que Service1 é adicionado ao IServiceCollection antes de Service2 e resulta em Service1 a ser resolvido para IService.

Criando bibliotecas para o ASP.NET Core no .NET 6

O ecossistema .NET existente criou extensibilidade em torno de IServiceCollection, IHostBuildere IWebHostBuilder. Essas propriedades estão disponíveis em WebApplicationBuilder como Services, Hoste WebHost.

WebApplication implementa tanto Microsoft.AspNetCore.Builder.IApplicationBuilder como Microsoft.AspNetCore.Routing.IEndpointRouteBuilder.

Esperamos que os autores de bibliotecas continuem direcionando IHostBuilder, IWebHostBuilder, IApplicationBuilder, e IEndpointRouteBuilder ao criar componentes específicos do ASP.NET Core. Isso garante que seu middleware, manipulador de rotas ou outros pontos de extensibilidade continuem a funcionar em diferentes modelos de hospedagem.

Perguntas frequentes (FAQ)

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

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

Não. O modelo de hospedagem genérico é um modelo alternativo que é suportado indefinidamente. O host genérico sustenta o novo modelo de hospedagem e ainda é a principal maneira de hospedar aplicativos baseados em trabalhadores.
Tenho que 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.
Tenho que 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 servidor Web ou aplicativo Web.
Onde coloco o estado que foi armazenado como campos na minha Program classe OR Startup ?

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

Há duas abordagens para armazenar o estado fora da 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 Program classe gerada por instruções de nível superior para armazenar o 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?

Contêineres DI personalizados são suportados. Para obter um exemplo, consulte Contêiner de injeção de dependência (DI) personalizado.
Fazem WebApplicationFactory e TestServer ainda trabalham?

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 orientações anteriores neste artigo para atualizar um aplicativo para o .NET 6, adote recursos específicos seguindo os links em O que há de novo no ASP.NET Core no .NET 6.

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

Crie um novo projeto 6.0 Blazor a partir de um dos Blazor modelos de projeto. Para obter mais informações, consulte 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 SPA

Migrando aplicativos Angular de extensões SPA

Veja este problema do GitHub

Migrando aplicativos React de extensões SPA

Consulte Migrando aplicações React de extensões de SPAnesta questão 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 tempo de execução 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 a questão do GitHub Breaking Change (mudança disruptiva): formato padrão do registo do console definido como JSON.

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

O Razor compilador agora aproveita o novo recurso de geradores de código-fonte para gerar arquivos C# compilados a partir das visualizações e páginas em um projeto. Nas versões anteriores:

A compilação dependia dos alvos RazorGenerate e RazorCompile para produzir o código gerado. Estas metas já não são válidas. No .NET 6, a geração de código e a compilação são suportadas por uma única chamada para o compilador. RazorComponentGenerateDependsOn ainda é suportado para especificar dependências que são necessárias antes da execução da compilação.
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 aplicações eram AppName.Views.dll públicos. No .NET 6, os tipos de aplicativo estão em AppName.dll , mas são internal sealed. Os aplicativos que fazem descoberta de tipo em AppName.Views.dll não poderão fazer descoberta de tipo em AppName.dll. A seguir 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, consulte Razor o compilador não produz mais uma assemblagem Views.

Os modelos de projeto usam o Duende Identity Servidor

Os modelos de projeto agora usam o Duende Identity Server.

Importante

Duende Identity Server é um produto de código aberto com um acordo de licença recíproca. Se você planeja usar o Duende Server em produção, talvez seja necessário obter uma licença comercial da Identity e pagar uma taxa de licença. Para obter mais informações, consulte Duende Software: Licenças.

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

Adicione uma DbSet<Key> propriedade nomeada Keys a cada IdentityDbContext para satisfazer um novo requisito da versão atualizada do IPersistedGrantDbContext. As chaves são necessárias como parte do contrato com as lojas do Duende Identity Server.

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

Observação

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

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ínima em 6.0

Alterações de grande impacto

Use os artigos em Alterações significativas no .NET para encontrar alterações significativas que podem ser aplicadas ao atualizar um aplicativo para uma versão mais recente do .NET.

Para obter mais informações, consulte Anúncios repositório GitHub (aspnet/Announcements, 6.0.0 label): Inclui informações ininterruptas e ininterruptas.

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

Modelos de projeto do ASP.NET Core usam tipos de referência anuláveis e o compilador .NET realiza a 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 o ASP.NET Core no .NET 6 (C# 10) ou posterior.

Os avisos de análise estática de estado nulo do compilador .NET podem servir como um guia para atualizar um exemplo de documentação ou aplicativo de exemplo localmente ou ser ignorados. A análise estática de estado nulo pode ser desativada configurando Nullable como disable no ficheiro de projeto da aplicação, o que apenas recomendamos para exemplos de documentação e aplicações de exemplo se os avisos do compilador forem distractores ao estar a aprender sobre .NET. Não recomendamos desativar 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 orientações), consulte os seguintes recursos na documentação do C#:

Módulo ASP.NET Core (ANCM)

Se o ASP.NET Core Module (ANCM) não era um componente selecionado quando o Visual Studio foi instalado ou se uma versão anterior do ANCM foi instalada no sistema, baixe o instalador mais recente do .NET Core Hosting Bundle (download direto) e execute o instalador. Para obter mais informações, consulte Pacote de hospedagem.

Alteração do nome do aplicativo

No .NET 6, o WebApplicationBuilder normaliza o caminho raiz do conteúdo para terminar com um DirectorySeparatorChar. A maioria dos aplicativos que migram do HostBuilder ou WebHostBuilder não terá o mesmo nome de aplicativo porque eles 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ínima em 6.0

Feedback

Esta página foi útil?

Last updated on 2026-01-09

Partilhar via

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

Pré-requisitos

Atualize a versão do SDK do .NET em global.json

Atualizar a estrutura de destino

Atualizar referências de pacotes

Novo modelo de hospedagem

Os aplicativos que migram para ou usam a versão 6.0 ou posterior não precisam usar o novo modelo de hospedagem mínima

Use a inicialização com o novo modelo de hospedagem mínima

Diferenças entre o ASP.NET Core nos modelos de hospedagem .NET 5 e .NET 6

Criando bibliotecas para o ASP.NET Core no .NET 6

Perguntas frequentes (FAQ)

Blazor

Migrando projetos 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

Os modelos de projeto usam o Duende Identity Servidor

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

Alterações de grande impacto

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

Módulo ASP.NET Core (ANCM)

Alteração do nome do aplicativo

Recursos adicionais

Feedback

Recursos adicionais