Eseguire la migrazione da ASP.NET Core 5.0 a 6.0

Articolo
11/30/2023

Questo articolo illustra come aggiornare un progetto ASP.NET Core 5.0 esistente a ASP.NET Core 6.0. Per istruzioni su come eseguire la migrazione da ASP.NET Core 3.1 a ASP.NET Core 6.0, vedere Eseguire la migrazione da ASP.NET Core 3.1 a 6.0.

Prerequisiti

Visual Studio 2022 con il carico di lavoro Sviluppo ASP.NET e Web.
.NET 6.0 SDK

Aggiornare la versione di .NET SDK in global.json

Se si fa affidamento su un global.json file per specificare una versione specifica di .NET SDK, aggiornare la version proprietà alla versione di .NET 6.0 SDK installata. Ad esempio:

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

Aggiornare il framework di destinazione

Aggiornare il moniker del framework di destinazione del file di progetto (TFM) a net6.0:

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

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

</Project>

Aggiornare i riferimenti del pacchetto

Nel file di progetto aggiornare l'attributo di Version ogni Microsoft.AspNetCore.* riferimento al pacchetto e Microsoft.Extensions.* alla versione 6.0.0 o successiva. Ad esempio:

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

Nuovo modello di hosting

Il nuovo modello di hosting minimo di .NET 6 per le app ASP.NET Core richiede solo un file e alcune righe di codice. Le app che eseguono la migrazione alla versione 6.0 non devono usare il nuovo modello di hosting minimo. Per altre informazioni, vedere App che eseguono la migrazione alla versione 6.0 non devono usare il nuovo modello di hosting minimo nella sezione seguente.

Il codice seguente del modello vuoto ASP.NET Core crea un'app usando il nuovo modello di hosting minimo:

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

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

app.Run();

Modello di hosting minimo:

Riduce significativamente il numero di file e righe di codice necessari per creare un'app. È necessario un solo file con quattro righe di codice.
Unifica Startup.cs e Program.cs in un singolo Program.cs file.
Usa istruzioni di primo livello per ridurre al minimo il codice necessario per un'app.
Usa direttive globali using per eliminare o ridurre al minimo il numero di righe di using istruzioni necessarie.

Il codice seguente visualizza i Startup.cs file e Program.cs da un modello di ASP.NET app Web Core 5 Core 5 (Razor Pages) con istruzioni inutilizzate using rimosse:

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

In ASP.NET Core 6, il codice precedente viene sostituito da quanto segue:

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

L'esempio precedente ASP.NET Core 6 illustra come:

ConfigureServices è sostituito da WebApplication.Services.
builder.Build() restituisce un oggetto configurato WebApplication per la variabile app. Configure viene sostituito con chiamate di configurazione agli stessi servizi tramite app.

Esempi dettagliati della migrazione del codice ASP.NET Core 5 Startup a ASP.NET Core 6 usando il modello di hosting minimo sono disponibili più avanti in questo documento.

Sono state apportate alcune modifiche agli altri file generati per il modello di app Web:

Index.cshtml e Privacy.cshtml rimuovere le istruzioni inutilizzate using .
RequestId in è dichiarato come un tipo riferimento nullable (NRT):in Error.cshtml is declared as a nullable reference type (NRT):

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

Le impostazioni predefinite a livello di log sono state modificate in appsettings.json e appsettings.Development.json:

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

Nel codice "Microsoft": "Warning" del modello core ASP.NET precedente è stato modificato in "Microsoft.AspNetCore": "Warning". Questa modifica comporta la registrazione di tutti i messaggi informativi dallo spazio dei Microsoft nomi ad eccezione Microsoft.AspNetCoredi . Ad esempio, Microsoft.EntityFrameworkCore viene registrato a livello informativo.

Per altre informazioni sul nuovo modello di hosting, vedere la sezione Domande frequenti . Per altre informazioni sull'adozione di nrT e analisi dello stato null del compilatore .NET, vedere la sezione Tipi di riferimento nullable (NRT) e analisi statica dello stato null del compilatore .NET.

Le app che eseguono la migrazione a o 6.0 e versioni successive non devono usare il nuovo modello di hosting minimo

L'uso Startup di e l'host generico usato dai modelli ASP.NET Core 3.1 e 5.0 sono completamente supportati.

Usare Startup con il nuovo modello di hosting minimo

ASP.NET app Core 3.1 e 5.0 possono usare il codice Startup con il nuovo modello di hosting minimo. L'uso Startup con il modello di hosting minimo presenta i vantaggi seguenti:

Non viene usata alcuna reflection nascosta per chiamare la Startup classe .
Il codice asincrono può essere scritto perché lo sviluppatore controlla la chiamata a Startup.
Il codice può essere scritto che interleaves ConfigureServices e Configure.

Una limitazione secondaria nell'uso Startup del codice con il nuovo modello di hosting minimo è che per inserire una dipendenza in Configure, il servizio in Program.cs deve essere risolto manualmente.

Si consideri il codice seguente generato dal modello ASP.NET Core 3.1 o 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();
        });
    }
}

Il codice precedente è stato migrato al nuovo modello di hosting minimo:

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

Nel codice precedente il if (env.IsDevelopment()) blocco viene rimosso perché in modalità di sviluppo il middleware della pagina delle eccezioni per sviluppatori è abilitato per impostazione predefinita. Per altre informazioni, vedere Differenze tra i modelli di hosting ASP.NET Core 5 e 6 nella sezione successiva.

Quando si usa un contenitore DI (Dependency Injection) personalizzato, aggiungere il codice evidenziato seguente:

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

Quando si usa il modello di hosting minimo, il middleware di routing degli endpoint esegue il wrapping dell'intera pipeline middleware, pertanto non è necessario disporre di chiamate esplicite a UseRouting o UseEndpoints per registrare le route. UseRouting può comunque essere usato per specificare dove avviene la corrispondenza delle route, ma UseRouting non deve essere chiamato in modo esplicito se le route devono essere abbinate all'inizio della pipeline middleware.

Nel codice seguente le chiamate a UseRouting e UseEndpoints vengono rimosse da Startup. MapRazorPages viene chiamato in 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();

Quando si usa Startup con il nuovo modello di hosting minimo, tenere presente la differenza seguente:

Program.cs controlla la creazione di istanze e la durata della Startup classe .
Tutti i servizi aggiuntivi inseriti nel Configure metodo devono essere risolti manualmente dalla Program classe .

Differenze tra i modelli di hosting ASP.NET Core 5 e 6

In modalità di sviluppo, il middleware della pagina delle eccezioni per sviluppatori è abilitato per impostazione predefinita.
Il nome dell'app viene impostato per impostazione predefinita sul nome dell'assembly del punto di ingresso: Assembly.GetEntryAssembly().GetName().FullName. Quando si usa in WebApplicationBuilder una libreria, modificare in modo esplicito il nome dell'app nell'assembly della libreria per consentire il funzionamento dell'individuazione delle parti dell'applicazione di MVC. Per istruzioni dettagliate, vedere Modificare la radice del contenuto, il nome dell'app e l'ambiente in questo documento.
Il middleware di routing degli endpoint esegue il wrapping dell'intera pipeline middleware, pertanto non è necessario avere chiamate esplicite a UseRouting o UseEndpoints per registrare le route. UseRouting può comunque essere usato per specificare dove avviene la corrispondenza delle route, ma UseRouting non deve essere chiamato in modo esplicito se le route devono essere abbinate all'inizio della pipeline middleware.
La pipeline viene creata prima di qualsiasi IStartupFilter esecuzione, pertanto le eccezioni causate durante la compilazione della pipeline non sono visibili alla catena di IStartupFilter chiamate.
Alcuni strumenti, ad esempio le migrazioni di Entity Framework, usano Program.CreateHostBuilder per accedere all'app IServiceProvider per eseguire la logica personalizzata nel contesto dell'app. Questi strumenti sono stati aggiornati per usare una nuova tecnica per eseguire logica personalizzata nel contesto dell'app. Entity Framework Migrations è un esempio di uno strumento che usa Program.CreateHostBuilder in questo modo. Microsoft sta lavorando per assicurarsi che gli strumenti vengano aggiornati per usare il nuovo modello.
A differenza della Startup classe, l'host minimo non configura automaticamente un ambito di inserimento delle dipendenze quando si crea un'istanza del provider di servizi. Per i contesti in cui è necessario un ambito, è necessario richiamare IServiceScope con IServiceScopeFactory.CreateScope per creare un'istanza di un nuovo ambito. Per altre informazioni, vedere come risolvere un servizio all'avvio dell'app.
Non è possibile modificare le impostazioni host, ad esempio il nome dell'app, l'ambiente o la radice del contenuto dopo la creazione di WebApplicationBuilder. Per istruzioni dettagliate sulla modifica delle impostazioni host, vedere Personalizzare IHostBuilder o IWebHostBuilder. Le API evidenziate seguenti generano un'eccezione:

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 classe non può essere usata da WebApplicationBuilder.Host o WebApplicationBuilder.WebHost. Il codice evidenziato seguente genera un'eccezione:

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

L'implementazione IHostBuilder in WebApplicationBuilder (WebApplicationBuilder.Host) non rinvia l'esecuzione ConfigureServicesdei metodi , ConfigureAppConfigurationo ConfigureHostConfiguration . Non rinviare l'esecuzione consente al codice di WebApplicationBuilder usare per osservare le modifiche apportate a IServiceCollection e IConfiguration. Nell'esempio seguente viene aggiunto Service1 solo come :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
{
}

Nel codice precedente, il builder.Host.ConfigureServices callback viene chiamato inline anziché essere posticipato fino a quando builder.Build non viene chiamato. Ciò significa che Service1 viene aggiunto a IServiceCollection prima Service2 e comporta la Service1 risoluzione per IService.

Compilazione di librerie per ASP.NET Core 6

L'ecosistema .NET esistente ha creato l'estendibilità intorno a IServiceCollection, IHostBuildere IWebHostBuilder. Queste proprietà sono disponibili in WebApplicationBuilder come Services, Hoste WebHost.

WebApplication implementa sia Microsoft.AspNetCore.Builder.IApplicationBuilder che Microsoft.AspNetCore.Routing.IEndpointRouteBuilder.

Si prevede che gli autori di librerie continuino a usare come destinazione IHostBuilder, IWebHostBuilder, IApplicationBuildere IEndpointRouteBuilder durante la compilazione di componenti specifici di ASP.NET Core. Ciò garantisce che il middleware, il gestore di route o altri punti di estendibilità continuino a funzionare tra modelli di hosting diversi.

Domande frequenti

Il nuovo modello di hosting minimo è meno in grado di supportare?

No. Il nuovo modello di hosting è funzionalmente equivalente per il 98% degli scenari supportati da IHostBuilder e .IWebHostBuilder Esistono alcuni scenari avanzati che richiedono soluzioni alternative specifiche in IHostBuilder, ma si prevede che questi siano estremamente rari.
Il modello di hosting generico è deprecato?

No. Il modello di hosting generico è un modello alternativo supportato a tempo indeterminato. L'host generico è alla base del nuovo modello di hosting ed è ancora il modo principale per ospitare applicazioni basate sul ruolo di lavoro.
È necessario eseguire la migrazione al nuovo modello di hosting?

No. Il nuovo modello di hosting è il modo migliore per ospitare nuove app usando .NET 6 e versioni successive, ma non è necessario modificare il layout del progetto nelle app esistenti. Ciò significa che le app possono eseguire l'aggiornamento da .NET 5 a .NET 6 modificando il framework di destinazione nel file di progetto da net5.0 a net6.0. Per altre informazioni, vedere la sezione Aggiornare il framework di destinazione in questo articolo. È tuttavia consigliabile eseguire la migrazione delle app al nuovo modello di hosting per sfruttare le nuove funzionalità disponibili solo per il nuovo modello di hosting.
È necessario usare istruzioni di primo livello?

No. I nuovi modelli di progetto usano tutte istruzioni di primo livello, ma le nuove API di hosting possono essere usate in qualsiasi app .NET 6 per ospitare un server Web o un'app Web.
Dove si inserisce lo stato archiviato come campi nella classe Program o Startup ?

È consigliabile usare l'inserimento delle dipendenze (DI) per eseguire il flusso dello stato nelle app ASP.NET Core.

Esistono due approcci per archiviare lo stato all'esterno dell'inserimento delle dipendenze:
- Archiviare lo stato in un'altra classe. L'archiviazione in una classe presuppone uno stato statico accessibile da qualsiasi posizione dell'app.
- Usare la Program classe generata dalle istruzioni di primo livello per archiviare lo stato. L'uso Program di per archiviare lo stato è l'approccio semantico:
```
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; }
}
```
Cosa accade se si usasse un contenitore di inserimento delle dipendenze personalizzato?

Sono supportati contenitori di inserimento delle dipendenze personalizzati. Per un esempio, vedere Contenitore di inserimento delle dipendenze personalizzato.For an example, see Custom dependency injection (DI) container.
TestServer E WebApplicationFactory continuano a funzionare?

Sì. WebApplicationFactory<TEntryPoint> è il modo per testare il nuovo modello di hosting. Per un esempio, vedere Test con WebApplicationFactory o TestServer.

Blazor

Dopo aver seguito le indicazioni riportate in precedenza in questo articolo per aggiornare un'app alla versione 6.0, adottare funzionalità specifiche seguendo i collegamenti in Novità di ASP.NET Core 6.0.

Per adottare tutte le nuove funzionalità 6.0 per Blazor le app, è consigliabile eseguire il processo seguente:

Creare un nuovo progetto 6.0 Blazor da uno dei modelli di Blazor progetto. Per altre informazioni, vedere Strumenti per ASP.NET Core Blazor.
Spostare i componenti e il codice dell'app nell'app 6.0 apportando modifiche per adottare le nuove funzionalità 6.0.

Migrazione di progetti SPA

Migrazione di app Angular da estensioni SPA

Vedere questo problema di GitHub

Migrazione di app React dalle estensioni SPA

Vedere Migrazione di applicazioni React dalle estensioni spa in questo problema di GitHub

Aggiornare le immagini Docker

Per le app che usano Docker, aggiornare le istruzioni e gli script DockerfileFROM. Usare un'immagine di base che include il runtime di ASP.NET Core 6.0. Considerare la differenza di comando seguente docker pull tra 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

Vedere Problema di GitHub Modifica che causa un'interruzione : formato del logger della console predefinito impostato su JSON.

Modifiche apportate a ASP.NET Core Razor SDK

Il Razor compilatore ora sfrutta la nuova funzionalità generatori di origine per generare file C# compilati dalle Razor visualizzazioni e dalle pagine di un progetto. Nelle versioni precedenti:

La compilazione si basava sulle RazorGenerate destinazioni e RazorCompile per produrre il codice generato. Queste destinazioni non sono più valide. In .NET 6, sia la generazione del codice che la compilazione sono supportate da una singola chiamata al compilatore. RazorComponentGenerateDependsOn è ancora supportato per specificare le dipendenze necessarie prima dell'esecuzione della compilazione.
È stato generato un assembly separato Razor , AppName.Views.dll, che conteneva i tipi di visualizzazione compilati in un'applicazione. Questo comportamento è stato deprecato e viene generato un singolo assembly AppName.dll che contiene sia i tipi di app che le visualizzazioni generate.
I tipi di app in AppName.Views.dll erano pubblici. In .NET 6 i tipi di app sono in AppName.dll ma sono internal sealed. Le app che eseguono l'individuazione del tipo in AppName.Views.dll non saranno in grado di individuare il tipo in AppName.dll. Di seguito è illustrata la modifica dell'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>

Apportare le modifiche seguenti:

Le proprietà seguenti non sono più applicabili al modello di compilazione in un unico passaggio.
- RazorTargetAssemblyAttribute
- RazorTargetName
- EnableDefaultRazorTargetAssemblyInfoAttributes
- UseRazorBuildServer
- GenerateRazorTargetAssemblyInfo
- GenerateMvcApplicationPartsAssemblyAttributes

Per altre informazioni, vedere Razor il compilatore non produce più un assembly Views.

I modelli di progetto usano Duende Identity Server

I modelli di progetto ora usano Duende Identity Server. Per indicazioni sulla migrazione, vedere IdentityServer4 v4.1 to Duende IdentityServer v5.For migration guidance, see IdentityServer v4.1 to Duende IdentityServer v5.

Importante

Duende Identity Server è un prodotto open source con un contratto di licenza reciproco. Se si prevede di usare Duende Identity Server in produzione, potrebbe essere necessario ottenere una licenza commerciale da Duende Software e pagare una tariffa di licenza. Per altre informazioni, vedere Duende Software: Licenze.

Per informazioni su come usare Microsoft Azure Active Directory per ASP.NET CoreIdentity, vedere Identity (repository GitHub dotnet/aspnetcore).

Aggiungere una DbSet<Key> proprietà denominata Keys a ogni IdentityDbContext per soddisfare un nuovo requisito dalla versione aggiornata di IPersistedGrantDbContext. Le chiavi sono necessarie come parte del contratto con gli archivi di Duende Identity Server.

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

Nota

Le migrazioni esistenti devono essere ricreate per Duende Identity Server.

Esempi di codice migrati a ASP.NET Core 6.0

Esempi di codice migrati al nuovo modello di hosting minimo nella versione 6.0

Rivedere le modifiche che causano un'interruzione

Vedere le risorse seguenti:

Identity: versione predefinita di Bootstrap dell'interfaccia utente modificata
Modifiche di rilievo per la migrazione dalla versione 5.0 alla 6.0: include ASP.NET Core ed Entity Framework Core.
Repository GitHub annunci (aspnet/Announcements, 6.0.0 etichetta): include informazioni di rilievo e non di rilievo.

Tipi di riferimento nullable (NRT) e analisi statica dello stato null del compilatore .NET

ASP.NET modelli di progetto Core usano tipi di riferimento nullable e il compilatore .NET esegue l'analisi statica dello stato Null. Queste funzionalità sono state rilasciate con C# 8 e sono abilitate per impostazione predefinita per le app generate con ASP.NET Core 6.0 (C# 10) o versioni successive.

Gli avvisi di analisi statica dello stato Null del compilatore .NET possono fungere da guida per aggiornare un esempio di documentazione o un'app di esempio in locale o essere ignorata. L'analisi statica con stato Null può essere disabilitata impostando su Nullable disable nel file di progetto dell'app, che è consigliabile solo per esempi di documentazione e app di esempio se gli avvisi del compilatore distraggono durante l'apprendimento di .NET. Non è consigliabile disabilitare il controllo dello stato Null nei progetti di produzione.

Per altre informazioni sui valori NRT, la proprietà MSBuild Nullable e l'aggiornamento delle app (incluse #pragma le indicazioni), vedere le risorse seguenti nella documentazione di C#:

modulo ASP.NET core (ANCM)

Se la ASP.NET Core Module (ANCM) non è un componente selezionato quando Visual Studio è stato installato o se è stata installata una versione precedente di ANCM nel sistema, scaricare l'ultimo programma di installazione del bundle di hosting .NET Core (download diretto) ed eseguire il programma di installazione. Per altre informazioni, vedere Bundle di hosting.

Modifica del nome dell'applicazione

In .NET 6 WebApplicationBuilder normalizza il percorso radice del contenuto per terminare con un oggetto DirectorySeparatorChar. La maggior parte delle app che eseguono la migrazione da HostBuilder o WebHostBuilder non avrà lo stesso nome dell'app perché non sono normalizzate. Per altre informazioni, vedere SetApplicationName

Risorse aggiuntive

Esempi di codice migrati al nuovo modello di hosting minimo nella versione 6.0

Condividi tramite

Eseguire la migrazione da ASP.NET Core 5.0 a 6.0

Prerequisiti

Aggiornare la versione di .NET SDK in global.json

Aggiornare il framework di destinazione

Aggiornare i riferimenti del pacchetto

Nuovo modello di hosting

Le app che eseguono la migrazione a o 6.0 e versioni successive non devono usare il nuovo modello di hosting minimo

Usare Startup con il nuovo modello di hosting minimo

Differenze tra i modelli di hosting ASP.NET Core 5 e 6

Compilazione di librerie per ASP.NET Core 6

Domande frequenti

Blazor

Migrazione di progetti SPA

Migrazione di app Angular da estensioni SPA

Migrazione di app React dalle estensioni SPA

Aggiornare le immagini Docker

Modifiche apportate a ASP.NET Core Razor SDK

I modelli di progetto usano Duende Identity Server

Esempi di codice migrati a ASP.NET Core 6.0

Rivedere le modifiche che causano un'interruzione

Tipi di riferimento nullable (NRT) e analisi statica dello stato null del compilatore .NET

modulo ASP.NET core (ANCM)

Modifica del nome dell'applicazione

Risorse aggiuntive

Risorse aggiuntive