Migración de ASP.NET Core 5.0 a 6.0

En este artículo se explica cómo actualizar un proyecto de ASP.NET Core 5.0 existente a ASP.NET Core 6.0. Para obtener instrucciones sobre cómo migrar de ASP.NET Core 3.1 a ASP.NET Core 6.0, consulte Migración de ASP.NET Core 3.1 a 6.0.

Requisitos previos

Actualización de la versión del SDK de .NET en global.json

Si confía en un archivo para tener como global.json destino una versión específica del SDK de .NET, actualice la version propiedad a la versión del SDK de .NET 6.0 instalada. Por ejemplo:

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

Actualización de la plataforma de destino

Actualice el moniker de la plataforma de destino (TFM) del archivo de proyecto a net6.0:

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

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

</Project>

Actualización de las referencias del paquete

En el archivo del proyecto, actualice el atributo de cada Microsoft.AspNetCore.*Microsoft.Extensions.* referencia de Version paquete a 6.0.0 o posterior. Por ejemplo:

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

Nuevo modelo de hospedaje

El nuevo modelo de hospedaje mínimo de .NET 6 para aplicaciones de ASP.NET Core solo requiere un archivo y algunas líneas de código. Las aplicaciones que migran a la versión 6.0 no necesitan usar el nuevo modelo de hospedaje mínimo. Para obtener más información, consulte Aplicaciones que migran a la versión 6.0 no es necesario usar el nuevo modelo de hospedaje mínimo en la sección siguiente.

El código siguiente de la plantilla vacía ASP.NET Core crea una aplicación con el nuevo modelo de hospedaje mínimo:

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

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

app.Run();

El modelo de hospedaje mínimo:

  • Reducen considerablemente la cantidad de archivos y líneas de código que se necesitan para crear una aplicación. Solo se necesita un archivo con cuatro líneas de código.
  • Unifican Startup.cs y Program.cs en un archivo Program.cs único.
  • Utilizan instrucciones de nivel superior a fin de minimizar el código necesario para una aplicación.
  • Utilizan directivas using globales a fin de eliminar o minimizar la cantidad de líneas de instrucción using que se requieren.

En el código siguiente se muestran los Startup.cs archivos y Program.cs de una plantilla de ASP.NET Core 5 Web App (Razor Pages) con instrucciones sin usar using eliminadas:

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

En ASP.NET Core 6, el código anterior se reemplaza por lo siguiente:

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

En el ejemplo anterior ASP.NET Core 6 se muestra cómo:

Más adelante en este documento se proporcionan ejemplos detallados de la migración de código de ASP.NET Core 5 Startup a ASP.NET Core 6 mediante el modelo de hospedaje mínimo.

Hay algunos cambios en los demás archivos generados para la plantilla aplicación web:

- public string RequestId { get; set; }
+ public string? RequestId { get; set; }
  • Los valores predeterminados del nivel de registro han cambiado en appsettings.json y appsettings.Development.json:
- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"

En el código de plantilla core de ASP.NET anterior, "Microsoft": "Warning" se ha cambiado a "Microsoft.AspNetCore": "Warning". Este cambio da como resultado el registro de todos los mensajes informativos del Microsoft espacio de nombres , exceptoMicrosoft.AspNetCore . Por ejemplo, Microsoft.EntityFrameworkCore ahora se registra en el nivel informativo.

Para más información sobre el nuevo modelo de hospedaje, consulte la sección Preguntas más frecuentes . Para obtener más información sobre la adopción de NRT y el análisis de estado nulo del compilador de .NET, consulte la sección Tipos de referencia que aceptan valores NULL (NRT) y análisis estático de estado null del compilador de .NET .

Las aplicaciones que migran a la versión 6.0 no necesitan usar el nuevo modelo de hospedaje mínimo

El uso Startup y el host genérico usado por las plantillas de ASP.NET Core 3.1 y 5.0 son totalmente compatibles.

Uso del inicio con el nuevo modelo de hospedaje mínimo

ASP.NET aplicaciones core 3.1 y 5.0 pueden usar su Startup código con el nuevo modelo de hospedaje mínimo. Tenga en cuenta el código siguiente generado por la plantilla de páginas de ASP.NET Core 3.1 o 5.0 Razor :

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

El código anterior migrado al nuevo modelo de hospedaje 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();
        });
    }
}

En el código anterior, el if (env.IsDevelopment()) bloque se quita porque, en modo de desarrollo, el middleware de la página de excepciones del desarrollador está habilitado de forma predeterminada. Para obtener más información, vea Diferencias entre los modelos de hospedaje de ASP.NET Core 5 y 6 en la sección siguiente.

Al usar un contenedor de inserción de dependencias (DI) personalizado, agregue el código resaltado siguiente:

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

Cuando se usa el modelo de hospedaje mínimo, el middleware de enrutamiento de puntos de conexión encapsula toda la canalización de middleware, por lo que no es necesario tener llamadas explícitas a UseRouting ni UseEndpoints para registrar rutas. UseRouting todavía se puede usar para especificar dónde se produce la coincidencia de rutas, pero UseRouting no es necesario llamar explícitamente si las rutas deben coincidir al principio de la canalización de middleware.

En el código siguiente, las llamadas a UseRouting y UseEndpoints se quitan de Startup. MapRazorPages se llama a en 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();

Al usar Startup con el nuevo modelo de hospedaje mínimo, tenga en cuenta la siguiente diferencia:

  • Program.cs controla la creación de instancias y la duración de la Startup clase .
  • Cualquier servicio adicional insertado en el Configure método debe resolverse manualmente por la Program clase .

Diferencias entre los modelos de hospedaje de ASP.NET Core 5 y 6

  • En el modo de desarrollo, el middleware de la página de excepciones del desarrollador está habilitado de forma predeterminada.
  • El nombre de la aplicación tiene como valor predeterminado el nombre del ensamblado del punto de entrada: Assembly.GetEntryAssembly().GetName().FullName. Cuando se usa WebApplicationBuilder en una biblioteca, cambie explícitamente el nombre de la aplicación al ensamblado de la biblioteca para permitir que la detección de elementos de aplicación de MVC funcione. Consulte Cambio de la raíz del contenido, el nombre de la aplicación y el entorno en este documento para obtener instrucciones detalladas.
  • El middleware de enrutamiento de puntos de conexión encapsula toda la canalización de middleware, por lo que no es necesario tener llamadas explícitas a UseRouting ni UseEndpoints registrar rutas. UseRouting todavía se puede usar para especificar dónde se produce la coincidencia de rutas, pero UseRouting no es necesario llamar explícitamente si las rutas deben coincidir al principio de la canalización de middleware.
  • La canalización se crea antes de que IStartupFilter se ejecute, por lo tanto, las excepciones causadas al compilar la canalización no son visibles para la IStartupFilter cadena de llamadas.
  • Algunas herramientas, como las migraciones de EF, usan Program.CreateHostBuilder para acceder a las aplicaciones IServiceProvider para ejecutar lógica personalizada en el contexto de la aplicación. Estas herramientas se han actualizado para usar una nueva técnica para ejecutar lógica personalizada en el contexto de la aplicación. Entity Framework Migrations es un ejemplo de una herramienta que usa Program.CreateHostBuilder de esta manera. Estamos trabajando para asegurarnos de que las herramientas se actualizan para usar el nuevo modelo.
  • No es posible cambiar ninguna configuración de host, como el nombre de la aplicación, el entorno o la raíz del contenido después de la creación de WebApplicationBuilder. Para obtener instrucciones detalladas sobre cómo cambiar la configuración del host, consulte Personalización IHostBuilder o IWebHostBuilder. Las SIGUIENTES API resaltadas producen una excepción:
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();
  • La Startup clase no se puede usar desde WebApplicationBuilder.Host ni WebApplicationBuilder.WebHost. El código resaltado siguiente produce una excepción:

    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();
    
  • La IHostBuilder implementación en WebApplicationBuilder (WebApplicationBuilder.Host), no aplaza la ejecución de los ConfigureServicesmétodos , ConfigureAppConfigurationo ConfigureHostConfiguration . No aplazar la ejecución permite que el código use WebApplicationBuilder para observar los cambios realizados en IServiceCollection y IConfiguration. En el ejemplo siguiente solo se agrega Service1 como :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
    {
    }
    

En el código anterior, la builder.Host.ConfigureServices devolución de llamada se llama insertada en lugar de aplazarse hasta builder.Build que se llama a . Esto significa que Service1 se agrega al IServiceCollection objeto antes Service2 y da como Service1 resultado que se resuelva para IService.

Compilación de bibliotecas para ASP.NET Core 6

El ecosistema de .NET existente creó extensibilidad en torno a IServiceCollection, IHostBuildery IWebHostBuilder. Estas propiedades están disponibles en WebApplicationBuilder como Services, Hosty WebHost.

WebApplication implementa y Microsoft.AspNetCore.Builder.IApplicationBuilderMicrosoft.AspNetCore.Routing.IEndpointRouteBuilder.

Esperamos que los autores de bibliotecas sigan teniendo como destino IHostBuilder, IWebHostBuilderIApplicationBuilder, y IEndpointRouteBuilder al compilar ASP.NET componentes específicos principales. Esto garantiza que el middleware, el controlador de rutas u otros puntos de extensibilidad sigan funcionando en diferentes modelos de hospedaje.

Preguntas más frecuentes

  • ¿El nuevo modelo de hospedaje mínimo es menos capaz?

    No. El nuevo modelo de hospedaje es funcionalmente equivalente al 98 % de los escenarios admitidos por IHostBuilder y IWebHostBuilder. Hay algunos escenarios avanzados que requieren soluciones alternativas específicas en IHostBuilder, pero esperamos que sean extremadamente poco frecuentes.

  • ¿El modelo de hospedaje genérico está en desuso?

    No. El modelo de hospedaje genérico es un modelo alternativo que se admite indefinidamente. El host genérico respalda el nuevo modelo de hospedaje y sigue siendo la forma principal de hospedar aplicaciones basadas en trabajo.

  • ¿Tengo que migrar al nuevo modelo de hospedaje?

    No. El nuevo modelo de hospedaje es la manera preferida de hospedar nuevas aplicaciones con .NET 6 y versiones posteriores, pero no se le obliga a cambiar el diseño del proyecto en las aplicaciones existentes. Esto significa que las aplicaciones se pueden actualizar de .NET 5 a .NET 6 cambiando la plataforma de destino del archivo de proyecto de net5.0 a net6.0. Para obtener más información, consulte la sección Actualización de la plataforma de destino de este artículo. Sin embargo, recomendamos que las aplicaciones migren al nuevo modelo de hospedaje para aprovechar las nuevas características solo disponibles para el nuevo modelo de hospedaje.

  • ¿Tengo que usar instrucciones de nivel superior?

    No. Todas las plantillas de proyecto nuevas usan instrucciones de nivel superior, pero las nuevas API de hospedaje se pueden usar en cualquier aplicación de .NET 6 para hospedar un servidor web o una aplicación web.

  • ¿Dónde puse el estado que se almacenó como campos en mi Program clase o Startup ?

    Se recomienda encarecidamente usar la inserción de dependencias (DI) para fluir el estado en ASP.NET aplicaciones core.

    Hay dos enfoques para almacenar el estado fuera de la inserción de dependencias:

    • Almacene el estado en otra clase. Almacenar en una clase supone un estado estático al que se puede acceder desde cualquier lugar de la aplicación.

    • Use la Program clase generada por instrucciones de nivel superior para almacenar el estado. El uso Program de para almacenar el estado es el enfoque semántico:

      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; }
      }
      
  • ¿Qué ocurre si estaba usando un contenedor de inserción de dependencias personalizado?

    Se admiten contenedores de di personalizados. Para obtener un ejemplo, consulte Contenedor de inserción de dependencias personalizada (DI).

  • ¿Y WebApplicationFactoryTestServer sigue funcionando?

    Sí. WebApplicationFactory<TEntryPoint> es la manera de probar el nuevo modelo de hospedaje. Para obtener un ejemplo, vea Prueba con WebApplicationFactory o TestServer.

Blazor

Después de seguir las instrucciones anteriores de este artículo para actualizar una aplicación a la versión 6.0, adopte características específicas siguiendo los vínculos de Novedades de ASP.NET Core 6.0.

Para adoptar todas las nuevas características de la versión 6.0 para Blazor las aplicaciones, se recomienda el siguiente proceso:

  • Cree un nuevo proyecto 6.0 Blazor a partir de una de las Blazor plantillas de proyecto. Para más información, vea Herramientas para ASP.NET Core Blazor.
  • Mueva los componentes y el código de la aplicación a la aplicación 6.0 realizando modificaciones para adoptar las nuevas características de la versión 6.0.

Actualización de imágenes de Docker

En el caso de las aplicaciones que usan Docker, actualice las instrucciones y scripts de DockerfileFROM . Use una imagen base que incluya el entorno de ejecución de ASP.NET Core 6.0. Tenga en cuenta la siguiente docker pull diferencia de comandos entre ASP.NET Core 5.0 y 6.0:

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

Consulte Problema de GitHub Cambio importante: formato predeterminado del registrador de consola establecido JSen ACTIVADO.

Cambios en el SDK de ASP.NET Core Razor

El Razor compilador ahora aprovecha la nueva característica de generadores de origen para generar archivos C# compilados a partir de las Razor vistas y páginas de un proyecto. En versiones anteriores:

  • La compilación se basaba en los RazorGenerate destinos y RazorCompile para generar el código generado. Estos destinos ya no son válidos. En .NET 6, tanto la generación de código como la compilación son compatibles con una sola llamada al compilador. RazorComponentGenerateDependsOn todavía se admite para especificar las dependencias necesarias antes de que se ejecute la compilación.
  • Se generó un ensamblado independiente Razor , AppName.Views.dll, que contenía los tipos de vista compilados en una aplicación. Este comportamiento ha quedado en desuso y se genera un único ensamblado AppName.dll que contiene los tipos de aplicación y las vistas generadas.
  • Los tipos de aplicación en AppName.Views.dll eran públicos. En .NET 6, los tipos de aplicación están en AppName.dll , pero son internal sealed. Las aplicaciones que realizan la detección de tipos en AppName.Views.dll no podrán realizar la detección de tipos en AppName.dll. A continuación se muestra el cambio de 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>

Se han realizado los siguientes cambios:

  • Las propiedades siguientes ya no son aplicables con el modelo de compilación de un solo paso.
    • RazorTargetAssemblyAttribute
    • RazorTargetName
    • EnableDefaultRazorTargetAssemblyInfoAttributes
    • UseRazorBuildServer
    • GenerateRazorTargetAssemblyInfo
    • GenerateMvcApplicationPartsAssemblyAttributes

Para obtener más información, vea Razor El compilador ya no genera un ensamblado Views.

Las plantillas de proyecto usan Duende Identity Server

Las plantillas de proyecto ahora usan Duende Identity Server. Para obtener instrucciones de migración, consulte IdentityServer4 v4.1 a Duende IdentityServer v5.

Importante

Duende Identity Server es un producto de código abierto con un contrato de licencia recíproca. Si tiene previsto usar Duende Identity Server en producción, es posible que tenga que obtener una licencia comercial de Duende Software y pagar una cuota de licencia. Para obtener más información, consulte Duende Software: Licencias.

Para obtener información sobre cómo usar Microsoft Azure Active Directory para ASP.NET Core Identity, consulte Identity (repositorio dotnet/aspnetcore de GitHub).

Agregue una DbSet<Key> propiedad denominada Keys a cada IdentityDbContext para satisfacer un requisito nuevo a partir de la versión actualizada de IPersistedGrantDbContext. Las claves son necesarias como parte del contrato con los almacenes de Duende Identity Server.

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

Nota

Las migraciones existentes deben volver a crearse para Duende Identity Server.

Ejemplos de código migrados a ASP.NET Core 6.0

Ejemplos de código migrados al nuevo modelo de hospedaje mínimo en 6.0

Revisión de los cambios importantes

Consulte los siguientes recursos:

Tipos de referencia que aceptan valores NULL (NRT) y análisis estático de estado NULL del compilador de .NET

ASP.NET las plantillas de proyecto de Core usan tipos de referencia que aceptan valores NULL (NRT) y el compilador de .NET realiza análisis estáticos de estado NULL. Estas características se publicaron con C# 8 y están habilitadas de forma predeterminada para las aplicaciones generadas con ASP.NET Core 6.0 (C# 10) o versiones posteriores.

Las advertencias de análisis estático de estado NULL del compilador de .NET pueden servir como guía para actualizar un ejemplo de documentación o una aplicación de ejemplo localmente o omitirse. El análisis estático de estado NULL se puede deshabilitar estableciendo Nullable en disable en el archivo de proyecto de la aplicación, algo que solo se recomienda para ejemplos de documentación y aplicaciones de ejemplo si las advertencias del compilador distraen durante el aprendizaje sobre .NET. No se recomienda deshabilitar la comprobación de estado NULL en los proyectos de producción.

Para obtener más información sobre las NRT, la propiedad Nullable de MSBuild y las aplicaciones de actualización (incluidas las instrucciones #pragma), consulte los siguientes recursos en la documentación de C#:

módulo principal de ASP.NET (ANCM)

Si el módulo principal (ANCM) de ASP.NET no era un componente seleccionado cuando Se instaló Visual Studio o si se instaló una versión anterior de ANCM en el sistema, descargue el instalador de agrupación de hospedaje de .NET Core más reciente (descarga directa) y ejecute el instalador. Para obtener más información, vea Hospedaje de lote.

Cambio del nombre de la aplicación

En .NET 6, WebApplicationBuilder normaliza la ruta de acceso raíz del contenido para finalizar con .DirectorySeparatorChar La mayoría de las aplicaciones que se migran desde HostBuilder o WebHostBuilder no tendrán el mismo nombre de aplicación porque no se normalizan. Para obtener más información, consulte SetApplicationName.

Recursos adicionales