Eseguire la migrazione da ASP.NET Core 5.0 a 6.0

Questo articolo illustra come aggiornare un progetto esistente ASP.NET Core 5.0 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

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

Visual Studio Code

• Visual Studio Code
• C# per Visual Studio Code (versione più recente)
• .NET 6.0 SDK

Le istruzioni di Visual Studio Code usano l'interfaccia della riga di comando di .NET per le funzioni di sviluppo di ASP.NET Core, ad esempio la creazione di progetti. È possibile seguire queste istruzioni in macOS, Linux o Windows e con qualsiasi editor di codice. Se si usa un editor diverso da Visual Studio Code potrebbero essere necessarie alcune modifiche minime.

Visual Studio per Mac

• Visual Studio 2022 per Mac (anteprima più recente)

Aggiornare la versione di .NET SDK in global.json

Se si fa affidamento su un global.json file per indirizzare 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 (TFM) del file di progetto 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 riferimento a ogni Microsoft.AspNetCore.* pacchetto e Microsoft.Extensions.* a 6.0.0 o versione 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 dal modello ASP.NET Core vuoto 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 istruzione necessarie.

Il codice seguente visualizza i Startup.cs file e Program.cs da un modello di app Web ASP.NET 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 dal codice seguente:

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 viene sostituito con WebApplication.Services.
• builder.Build() restituisce un oggetto configurato WebApplication per la variabile app. Configure viene sostituito con chiamate di configurazione agli stessi servizi usando app.

Esempi dettagliati della migrazione di codice ASP.NET Core 5 Startup a ASP.NET Core 6 usando il modello di hosting minimo vengono forniti 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 hanno le istruzioni inutilizzate using rimosse.
• RequestIdin Error.cshtml viene dichiarato come tipo di riferimento nullable (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" modello di ASP.NET Core precedente è stato modificato in "Microsoft.AspNetCore": "Warning". Questa modifica comporta la registrazione di tutti i messaggi informativi dallo Microsoft spazio dei nomi tranneMicrosoft.AspNetCore. Ad esempio, Microsoft.EntityFrameworkCore è ora registrato a livello informativo.

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

Le app che eseguono la migrazione alla versione 6.0 non devono usare il nuovo modello di hosting minimo

L'uso Startup 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 Core app 3.1 e 5.0 possono usare Startup il codice con il nuovo modello di hosting minimo. L'uso Startup con il modello di hosting minimo presenta i vantaggi seguenti:

• Nessuna reflection nascosta viene usata 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.

Prendere in considerazione 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 blocco viene rimosso perché in modalità di sviluppo, il if (env.IsDevelopment()) 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 dell'endpoint esegue il wrapping dell'intera pipeline middleware, pertanto non è necessario avere chiamate esplicite a UseRouting o UseEndpoints per registrare route. UseRouting può comunque essere usato per specificare dove avviene la corrispondenza della route, ma UseRouting non deve essere chiamato in modo esplicito se le route devono essere corrispondenti 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 l'istanza Startup e la durata della 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 per le eccezioni per sviluppatori è abilitato per impostazione predefinita.
• Il nome dell'app viene predefinito per il 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 della parte dell'applicazione MVC. Per istruzioni dettagliate , vedere Modificare la radice del contenuto, il nome dell'app e l'ambiente in questo documento.
• Il middleware di routing dell'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 della route, ma UseRouting non deve essere chiamato in modo esplicito se le route devono essere corrispondenti all'inizio della pipeline middleware.
• La pipeline viene creata prima di qualsiasi IStartupFilter esecuzione, pertanto le eccezioni causate durante la compilazione della IStartupFilter pipeline non sono visibili alla catena di chiamate.
• Alcuni strumenti, ad esempio le migrazioni ef, usano Program.CreateHostBuilder per accedere alla logica personalizzata dell'app IServiceProvider 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. Stiamo lavorando per assicurarsi che gli strumenti vengano aggiornati per usare il nuovo modello.
• 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 dei ConfigureServicesmetodi , ConfigureAppConfigurationo ConfigureHostConfiguration . Non rinviare l'esecuzione consente al codice di usare WebApplicationBuilder per osservare le modifiche apportate a IServiceCollection e IConfiguration. L'esempio seguente aggiunge 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 all'oggetto 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 IServiceCollectiona , 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 scegliere come destinazione IHostBuilder, IWebHostBuilder, IApplicationBuildere IEndpointRouteBuilder durante la compilazione di ASP.NET Core componenti specifici. 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 per un periodo illimitato. L'host generico supporta il 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 preferito 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 per lo stato del flusso 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 di Program 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.

• Funziona WebApplicationFactory ancora?TestServer

  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 Blazor modelli di progetto. Per altre informazioni, vedere Strumenti per ASP.NET Core Blazor.
• Spostare i componenti e il codice dell'app nella versione 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 da estensioni SPA

Vedere Migrazione di applicazioni React da 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 ASP.NET Core 6.0. Si consideri 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 logger della console predefinito impostato su JSON.

Modifiche all'SDK di ASP.NET Core Razor

Il Razor compilatore ora sfrutta la nuova funzionalità generatori di origine per generare file C# compilati dalle viste e dalle Razor 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 la generazione e la compilazione del codice 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 AppName.Views.dllseparato Razor 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 dei tipi in AppName.Views.dll non potranno eseguire l'individuazione dei tipi in AppName.dll. Di seguito viene 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 a passaggio singolo.
  • 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 a 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 Core Identity, vedere Identity (repository GitHub dotnet/aspnetcore).

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

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

Esaminare 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 label): include informazioni di rilievo e non di rilievo.

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

ASP.NET Core modelli di progetto usano tipi di riferimento nullable e il compilatore .NET esegue l'analisi statica con stato Null. Queste funzionalità sono state rilasciate con C# 8 e sono abilitate per impostazione predefinita per le app generate usando 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 Nullable su 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 file NRT, la proprietà MSBuild Nullable e l'aggiornamento delle app (incluse #pragma le linee guida), vedere le risorse seguenti nella documentazione di C#:

• Tipi riferimento nullable
• Tipi riferimento nullable (riferimenti per C#)
• Informazioni sulle tecniche per risolvere gli avvisi relativi ai valori Null
• Aggiornare una codebase con tipi riferimento nullable per migliorare gli avvisi di diagnostica Null
• Attributi per l'analisi statica dello stato Null

modulo ASP.NET Core (ANCM)

Se l'ASP.NET Core Module (ANCM) non è stato selezionato quando è stato installato Visual Studio o se è stata installata una versione precedente di ANCM nel sistema, scaricare il programma di installazione più recente 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 ha 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