Migrar do ASP.NET Core 5.0 para 6.0

Artigo
11/30/2023

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

Pré-requisitos

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

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

Se você depender de um arquivo global.json para direcionar uma versão específica do SDK do .NET Core, atualize a propriedade version para a versão do SDK do .NET 6.0 instalada. Por exemplo:

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

Atualizar a estrutura de destino

Atualize o TFM (Moniker da Estrutura de Destino) 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 de cada Microsoft.AspNetCore.* e Microsoft.Extensions.* referência de Version pacote 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 a versão 6.0 não precisam usar o novo modelo de hospedagem mínima. Para obter mais informações, consulte Os aplicativos que migram para o 6.0 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ínimo:

Reduz significativamente o número de arquivos e linhas de código necessário 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 a fim de minimizar o código necessário para um aplicativo.
Usa diretivas using globais para eliminar ou minimizar o número de linhas de instrução using necessárias.

O código a seguir exibe os arquivos Startup.cs e Program.cs de um modelo de aplicativo Web ASP.NET Core 5 (RazorPáginas) com instruções não utilizadas removidasusing:

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 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 ASP.NET Core 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 ASP.NET Core código 5 Startup para ASP.NET Core 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 removam using as instruções não utilizados.
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 de modelo ASP.NET Core anterior, "Microsoft": "Warning" foi alterado para "Microsoft.AspNetCore": "Warning". A alteração resulta no registro em log de todas as mensagens informativas do namespace Microsoft exceto Microsoft.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 análise estática de estado nulo do compilador .NET .

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

O uso de Startup e o Host Genérico usado pelos modelos ASP.NET Core 3.1 e 5.0 é totalmente compatível.

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 gravado porque o desenvolvedor controla a chamada para Startup.
O código pode ser escrito entre as versões ConfigureServices e Configure.

Uma limitação secundária no uso Startup de código com o novo modelo de hospedagem mínima é que, para injetar uma dependência no Configure, o serviço no Program.cs deve ser resolvido manualmente.

Considere o seguinte código gerado pelo modelo de páginas ASP.NET Core 3.1 ou 5.0Razor:

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, 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 ASP.NET Core 5 e 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ínima, tenha em mente a seguinte diferença:

Program.cs controla a instanciação e o tempo de vida da Startup classe.
Todos os 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 5 e 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, 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 maneira. Estamos trabalhando para garantir que as ferramentas sejam atualizadas para usar o novo modelo.
Ao contrário da classe Startup, 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, você precisa 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 a 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 IHostBuilder implementação em WebApplicationBuilder (WebApplicationBuilder.Host), não adia a execução dos métodos ConfigureServices, ConfigureAppConfigurationou 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 adiciona Service1 apenas 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 Service2 e resulta em Service1 ser resolvido para IService.

Compilando bibliotecas para ASP.NET Core 6

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

WebApplication implementa 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 a 98% dos cenários compatíveis com IHostBuilder e o 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 e posteriores, 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 servidor Web ou aplicativo Web.
Onde faço para colocar o estado armazenado como campos na minha classe Program ou Startup?

É 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 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?

Há suporte para contêineres DI personalizados. Para obter um exemplo, consulte 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 nesse artigo para atualizar um aplicativo para 6.0, adote recursos específicos seguindo os links em Novidades no ASP.NET Core 6.0.

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

Crie um novo projeto 6.0 Blazor 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 6.0.

Migrando projetos 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 Docker, atualize suas instruções e scripts Dockerfile FROM. Use uma imagem base que inclua o runtime do ASP.NET Core 6.0. Considere a seguinte docker pull diferença de comando entre ASP.NET Core 5.0 e 6.0:

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

Confira o problema do GitHub Alteração interruptiva: formato de agente de console padrão 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 destinos RazorGenerate e RazorCompile para produzir o código gerado. Esses destinos não são mais válidos. 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 tipo no AppName.Views.dll não poderão fazer a descoberta de tipo no 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 Razor O 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 código aberto 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 Microsoft Azure Active Directory para ASP.NET Core Identity, consulte Identity (repositório Dotnet/aspnetcore do GitHub).

Adicione uma DbSet<Key> propriedade chamada Keys a cada IdentityDbContext para atender a um novo requisito da versão atualizada do 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 6.0

Exemplos de código migrados para o novo modelo de hospedagem mínima no 6.0

Analisar as alterações interruptivas

Consulte os seguintes recursos:

Identity: a versão padrão da interface do usuário do Bootstrap foi alterada
Alterações interruptivas para migração da versão 5.0 para a 6.0: inclui o ASP.NET Core e o Entity Framework Core.
Repositório GitHub de comunicados (aspnet/Announcements, rótulo 6.0.0): 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

ASP.NET Core modelos de projeto usam NRTs (tipos de referência anuláveis) e o compilador do .NET executa 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 ASP.NET Core 6.0 (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 ignorado. 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, consulte 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 migram de HostBuilder ou de WebHostBuilder não compartilham o mesmo nome de aplicativo porque não estão normalizados. Para obter mais informações, consulte SetApplicationName

Recursos adicionais

Exemplos de código migrados para o novo modelo de hospedagem mínima no 6.0

Partilhar via

Migrar do ASP.NET Core 5.0 para 6.0

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

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

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

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

Compilando bibliotecas para ASP.NET Core 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

Modelos de projeto usam o Servidor Duende Identity

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

Analisar as alterações interruptivas

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

Recursos adicionais