Migrer de ASP.NET Core dans .NET 5 vers .NET 6

2025-05-28

Cet article explique comment mettre à jour un projet ASP.NET Core existant dans .NET 5 vers .NET 6. Pour obtenir des instructions sur la migration de ASP.NET Core 3.1 vers .NET 6, consultez Migrer de ASP.NET Core 3.1 vers .NET 6.

Conditions préalables

Visual Studio 2022 avec la charge de travail Développement web et ASP.NET.
Kit de développement .NET 6

Mettre à jour la version du Kit de développement logiciel (SDK) .NET dans global.json

Si vous vous appuyez sur un global.json fichier pour cibler une version spécifique du Kit de développement logiciel (SDK) .NET, mettez à jour la version propriété vers la version du SDK .NET 6 installée. Par exemple:

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

Mettre à jour le framework cible

Mettez à jour le moniker de framework cible (TFM) du fichier projet vers net6.0 :

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

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

</Project>

Mettre à jour les références de package

Dans le fichier projet, mettez à jour l’attribut Version de chaque référence de paquet Microsoft.AspNetCore.* et Microsoft.Extensions.* à la version 6.0.0 ou ultérieure. Par exemple:

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

Nouveau modèle d’hébergement

Le nouveau modèle d’hébergement minimal .NET 6 pour les applications ASP.NET Core ne nécessite qu’un seul fichier et quelques lignes de code. Les applications qui migrent vers .NET 6 n’ont pas besoin d’utiliser le nouveau modèle d’hébergement minimal. Pour plus d’informations, consultez Les applications qui migrent vers .NET 6 n’ont pas besoin d’utiliser le nouveau modèle d’hébergement minimal dans la section suivante.

Le code suivant du modèle vide ASP.NET Core crée une application à l’aide du nouveau modèle d’hébergement minimal :

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

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

app.Run();

Modèle d’hébergement minimal :

Réduit considérablement le nombre de fichiers et de lignes de code requis pour créer une application. Un seul fichier est nécessaire avec quatre lignes de code.
Unifie Startup.cs et Program.cs dans un seul Program.cs fichier.
Utilise des instructions de niveau supérieur pour réduire le code requis pour une application.
Utilise des directives globales using pour éliminer ou réduire le nombre de lignes d’instructionusing requises.

Le code suivant affiche les fichiers Startup.cs et Program.cs d’un modèle de projet d’application web .NET 5 (RazorPages), avec les instructions using inutilisées supprimées :

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

Dans ASP.NET Core dans .NET 6, le code précédent est remplacé par les éléments suivants :

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’exemple ASP.NET Core précédent dans .NET 6 montre comment :

ConfigureServices est remplacé par WebApplication.Services.
builder.Build() retourne une valeur configurée WebApplication pour la variable app. Configure est remplacé par des appels de configuration vers les mêmes services à l'aide de app.

Des exemples détaillés de migration ASP.NET Core dans le code .NET 5 Startup vers .NET 6 à l’aide du modèle d’hébergement minimal sont fournis plus loin dans ce document.

Il existe quelques modifications apportées aux autres fichiers générés pour le modèle d’application web :

Index.cshtml et Privacy.cshtml ont les instructions inutilisées using supprimées.
RequestId in Error.cshtml est déclaré en tant que type de référence nullable (NRT) :

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

Les valeurs par défaut des niveaux de journalisation ont changé dans appsettings.json et appsettings.Development.json.

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

Dans le code du modèle ASP.NET Core précédent, "Microsoft": "Warning" a été remplacé par "Microsoft.AspNetCore": "Warning". Cette modification entraîne l'enregistrement de tous les messages d’information de l'espace de noms Microsoft, sauf Microsoft.AspNetCore. Par exemple, Microsoft.EntityFrameworkCore est maintenant enregistré au niveau d'information.

Pour plus d’informations sur le nouveau modèle d’hébergement, consultez la section Foire aux questions. Pour plus d’informations sur l’adoption des nrTs et de l’analyse de l’état null du compilateur .NET, consultez la section relative aux types de référence Nullable (NRTs) et à l’analyse statique de l’état statique du compilateur .NET .

Les applications qui migrent vers ou utilisant la version 6.0 ou ultérieure n’ont pas besoin d’utiliser le nouveau modèle d’hébergement minimal

L’utilisation de Startup ainsi que de l’hôte générique utilisé par les modèles ASP.NET Core 3.1 et 5.0 sont entièrement pris en charge.

Démarrez avec le nouveau modèle d'hébergement minimal

ASP.NET applications Core 3.1 et 5.0 peuvent utiliser leur Startup code avec le nouveau modèle d’hébergement minimal. L’utilisation Startup avec le modèle d’hébergement minimal présente les avantages suivants :

Aucune réflexion masquée n’est utilisée pour appeler la Startup classe.
Le code asynchrone peut être écrit, car le développeur contrôle l’appel à Startup.
Du code peut être écrit pour entrelacer ConfigureServices et Configure.

Une limitation mineure de l'utilisation du code Startup avec le nouveau modèle d'hébergement minimal est que pour injecter une dépendance dans Configure, le service dans Program.cs doit être résolu de manière manuelle.

Considérez le code suivant généré par le modèle de pages ASP.NET Core 3.1 ou 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();
        });
    }
}

Le code précédent a migré vers le nouveau modèle d’hébergement minimal :

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

Dans le code précédent, le bloc if (env.IsDevelopment()) est supprimé car, en mode développement, l'intergiciel de la page d'exception du développeur est activé par défaut. Pour plus d’informations, consultez Différences entre les modèles d’hébergement ASP.NET Core dans .NET 5 et .NET 6 dans la section suivante.

Lorsque vous utilisez un conteneur d’injection de dépendances personnalisé ( DI), ajoutez le code en surbrillance suivant :

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

Lorsque vous utilisez le modèle d’hébergement minimal, le middleware de routage des points de terminaison encapsule l’ensemble du pipeline d’intergiciels, donc il n’est pas nécessaire d’avoir des appels explicites vers UseRouting ou UseEndpoints pour mapper les itinéraires. UseRouting peut toujours être utilisé pour spécifier où se produit la correspondance des itinéraires, mais UseRouting n’a pas besoin d’être explicitement appelé si les itinéraires doivent être mis en correspondance au début du pipeline d’intergiciel.

Dans le code suivant, les appels à UseRouting et UseEndpoints sont supprimés de Startup. MapRazorPages est appelé dans 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();

Lorsque vous utilisez Startup le nouveau modèle d’hébergement minimal, gardez à l’esprit la différence suivante :

Program.cs contrôle l’instanciation et la durée de vie de la Startup classe.
Tous les services supplémentaires injectés dans la Configure méthode doivent être résolus manuellement par la Program classe.

Différences entre les modèles d’hébergement ASP.NET Core dans .NET 5 et .NET 6

En mode développement, le middleware de page d’exception de développeur est activé par défaut.
Le nom de l’application correspond par défaut au nom de l’assembly de point d’entrée : Assembly.GetEntryAssembly().GetName().FullName. Lorsque vous utilisez la WebApplicationBuilder bibliothèque, remplacez explicitement le nom de l’application par l’assembly de la bibliothèque pour permettre à la découverte de composants d’application de MVC de fonctionner. Pour obtenir des instructions détaillées , consultez Modifier la racine de contenu, le nom de l’application et l’environnement dans ce document.
Le middleware de routage du point de terminaison encapsule l’intégralité du pipeline d’intergiciels. Il n’est donc pas nécessaire d’effectuer des appels explicites à UseRouting ou UseEndpoints pour enregistrer des itinéraires. UseRouting peut toujours être utilisé pour spécifier où se produit la correspondance des itinéraires, mais UseRouting n’a pas besoin d’être explicitement appelé si les itinéraires doivent être mis en correspondance au début du pipeline d’intergiciel.
Le pipeline est créé avant les IStartupFilter exécutions, par conséquent, les exceptions provoquées lors de la génération du pipeline ne sont pas visibles par la IStartupFilter chaîne d’appels.
Certains outils, tels que les migrations EF, utilisent Program.CreateHostBuilder pour accéder au IServiceProvider de l'application et exécuter la logique personnalisée dans le contexte de l'application. Ces outils ont été mis à jour pour utiliser une nouvelle technique pour exécuter une logique personnalisée dans le contexte de l’application. Entity Framework Migrations est un exemple d’outil qui utilise Program.CreateHostBuilder de cette façon. Nous travaillons à nous assurer que les outils sont mis à jour pour utiliser le nouveau modèle.
Contrairement à la classe Startup, l'hôte minimal ne configure pas automatiquement une portée de DI lors de la création du fournisseur de services. Pour les contextes où une étendue est requise, il est nécessaire d’appeler IServiceScope avec IServiceScopeFactory.CreateScope pour instancier une nouvelle étendue. Pour plus d’informations, consultez comment résoudre un service au démarrage de l’application.
Il n’est pas possible de modifier les paramètres d’hôte tels que le nom de l’application, l’environnement ou la racine de contenu après la création du WebApplicationBuilderfichier . Pour obtenir des instructions détaillées sur la modification des paramètres de l’hôte, consultez Personnaliser IHostBuilder ou IWebHostBuilder. Les API surlignées suivantes lèvent une exception:

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 classe Startup ne peut pas être utilisée depuis WebApplicationBuilder.Host ou WebApplicationBuilder.WebHost. Le code mis en surbrillance suivant lève une exception :

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’implémentation IHostBuilder sur WebApplicationBuilder (WebApplicationBuilder.Host) ne reporte pas l’exécution des méthodes ConfigureServices, ConfigureAppConfiguration ou ConfigureHostConfiguration. Ne pas différer l'exécution permet au code utilisant WebApplicationBuilder d'observer les modifications apportées à IServiceCollection et IConfiguration. L’exemple suivant ajoute Service1 uniquement en tant que 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
{
}

Dans le code précédent, le builder.Host.ConfigureServices rappel est appelé directement plutôt que différé jusqu’à ce que builder.Build soit appelé. Cela signifie que Service1 est ajouté à IServiceCollection avant Service2 et que cela entraîne la résolution de Service1 pour IService.

Création de bibliothèques pour ASP.NET Core dans .NET 6

L’écosystème .NET existant a généré l’extensibilité autour IServiceCollection, IHostBuilderet IWebHostBuilder. Ces propriétés sont disponibles sous WebApplicationBuilder , ServicesHostet WebHost.

WebApplication implémente à la fois Microsoft.AspNetCore.Builder.IApplicationBuilder et Microsoft.AspNetCore.Routing.IEndpointRouteBuilder.

Nous nous attendons à ce que les auteurs de bibliothèque continuent de ciblerIHostBuilder, IWebHostBuilderIApplicationBuilderet IEndpointRouteBuilder lors de la génération de composants spécifiques ASP.NET Core. Cela garantit que votre intergiciel, gestionnaire de routage ou d’autres points d’extensibilité continuent de fonctionner sur différents modèles d’hébergement.

Questions fréquemment posées (FAQ)

Le nouveau modèle d’hébergement minimal est-il moins capable ?

Non. Le nouveau modèle d’hébergement est fonctionnellement équivalent pour 98% de scénarios pris en charge par IHostBuilder et le IWebHostBuilder. Certains scénarios avancés nécessitent des solutions de contournement spécifiques, mais nous nous attendons IHostBuilderà ce que ces solutions soient extrêmement rares.
Le modèle d’hébergement générique est-il déconseillé ?

Non. Le modèle d’hébergement générique est un autre modèle pris en charge indéfiniment. L'hôte générique assure la base du nouveau modèle d'hébergement et reste le moyen principal pour héberger des applications basées sur des travailleurs.
Dois-je migrer vers le nouveau modèle d’hébergement ?

Non. Le nouveau modèle d’hébergement est le moyen préféré d’héberger de nouvelles applications à l’aide de .NET 6 ou version ultérieure, mais vous n’êtes pas obligé de modifier la disposition du projet dans les applications existantes. Cela signifie que les applications peuvent effectuer une mise à niveau de .NET 5 vers .NET 6 en modifiant le framework cible dans le fichier projet de net5.0 vers net6.0. Pour plus d’informations, consultez la section Mettre à jour l’infrastructure cible dans cet article. Toutefois, nous recommandons aux applications de migrer vers le nouveau modèle d’hébergement pour tirer parti des nouvelles fonctionnalités uniquement disponibles pour le nouveau modèle d’hébergement.
Dois-je utiliser des instructions de niveau supérieur ?

Non. Les nouveaux modèles de projet utilisent tous des instructions de niveau supérieur, mais les nouvelles API d’hébergement peuvent être utilisées dans n’importe quelle application .NET 6 pour héberger un serveur web ou une application web.
Où dois-je mettre l'état qui était stocké en tant que champs dans ma classe Program ou Startup ?

Nous vous recommandons vivement d’utiliser l’injection de dépendances (DI) pour transmettre l’état dans les applications ASP.NET Core.

Il existe deux approches pour stocker l’état en dehors de l’id de disponibilité :
- Stockez l’état dans une autre classe. Le stockage dans une classe suppose un état statique accessible n’importe où dans l’application.
- Utilisez la Program classe générée par les instructions de niveau supérieur pour stocker l’état. L'utilisation de Program pour stocker l'état est l'approche sémantique :
```
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; }
}
```
Que se passe-t-il si j’utilisais un conteneur d’injection de dépendances personnalisé ?

Les conteneurs DI personnalisés sont pris en charge. Pour obtenir un exemple, consultez le conteneur d’injection de dépendances personnalisé (DI).
Est-ce que WebApplicationFactory et TestServer fonctionnent toujours ?

Oui. WebApplicationFactory<TEntryPoint> est le moyen de tester le nouveau modèle d’hébergement. Pour obtenir un exemple, consultez Test avec WebApplicationFactory ou TestServer.

Blazor

Après avoir suivi les instructions décrites plus haut dans cet article pour mettre à jour une application vers .NET 6, adoptez des fonctionnalités spécifiques en suivant les liens dans Les nouveautés de ASP.NET Core dans .NET 6.

Pour adopter toutes les nouvelles fonctionnalités 6.0 pour Blazor les applications, nous vous recommandons le processus suivant :

Créez un projet 6.0 Blazor à partir de l’un Blazor des modèles de projet. Pour plus d’informations, consultez Outils pour ASP.NET Core Blazor.
Déplacez les composants et le code de l’application vers l’application 6.0 en apportant des modifications pour adopter les nouvelles fonctionnalités .NET 6.

Migration de projets SPA

Migration d’applications Angular à partir d’extensions SPA

Voir ce problème GitHub

Migration d’applications React à partir d’extensions SPA

Consultez La migration d’applications React à partir d’extensions Spa dans ce problème GitHub

Mettre à jour les images Docker

Pour les applications utilisant Docker, mettez à jour vos instructions et scripts DockerfileFROM. Utilisez une image de base qui inclut le ASP.NET Core dans le runtime .NET 6. Considérez la différence de commande suivante docker pull entre ASP.NET Core dans .NET 5 et .NET 6 :

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

Consultez le problème GitHub Changement cassant : format d’enregistreur d’événements de console par défaut défini sur JSON.

Modifications apportées au Kit de développement logiciel (SDK) ASP.NET Core Razor

Le Razor compilateur tire désormais parti de la nouvelle fonctionnalité de générateurs sources pour générer des fichiers C# compilés à partir des Razor vues et des pages d’un projet. Dans les versions précédentes :

La compilation s'est basée sur les cibles RazorGenerate et RazorCompile pour produire le code généré. Ces cibles ne sont plus valides. Dans .NET 6, la génération de code et la compilation sont prises en charge par un seul appel au compilateur. RazorComponentGenerateDependsOn est toujours pris en charge pour spécifier les dépendances requises avant l’exécution de la build.
Un assembly distinct Razor , AppName.Views.dlla été généré qui contenait les types d’affichage compilés dans une application. Ce comportement a été déconseillé et un assembly AppName.dll unique est produit qui contient les types d’application et les vues générées.
Les types d'applications étaient AppName.Views.dll publics. Dans .NET 6, les types d’application se trouvent dans AppName.dll et sont internal sealed. Les applications qui effectuent une découverte de type sur AppName.Views.dll ne pourront pas faire de découverte de type sur AppName.dll. Les éléments suivants illustrent la modification de l’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>

Apportez les modifications suivantes :

Les propriétés suivantes ne s’appliquent plus au modèle de compilation en une seule étape.
- RazorTargetAssemblyAttribute
- RazorTargetName
- EnableDefaultRazorTargetAssemblyInfoAttributes
- UseRazorBuildServer
- GenerateRazorTargetAssemblyInfo
- GenerateMvcApplicationPartsAssemblyAttributes

Pour plus d’informations, consultez Razor le compilateur ne produit plus d’assembly Views.

Les modèles de projet utilisent Duende Identity Server

Les modèles de projet utilisent désormais Duende Identity Server.

Important

Duende Identity Server est un produit open source avec un contrat de licence réciproque. Si vous envisagez d’utiliser Duende Identity Server en production, vous devrez peut-être obtenir une licence commerciale auprès de Duende Software et payer des frais de licence. Pour plus d’informations, consultez Duende Software : Licences.

Pour savoir comment utiliser Microsoft Azure Active Directory pour ASP.NET Core Identity, consultez Identity (dépôt GitHub dotnet/aspnetcore).

Ajoutez une DbSet<Key> propriété nommée Keys à chaque IdentityDbContext pour répondre à une nouvelle exigence de la version mise à jour de IPersistedGrantDbContext. Les clés sont requises dans le cadre du contrat avec les magasins Duende Identity Server.

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

Remarque

Les migrations existantes doivent être recréées pour Duende Identity Server.

Exemples de code migrés vers ASP.NET Core dans .NET 6

Exemples de code migrés vers le nouveau modèle d’hébergement minimal dans la version 6.0

Examiner les changements avec rupture

Consultez les ressources suivantes :

Identity: Version par défaut de Bootstrap de l'interface utilisateur modifiée
Changements cassants pour la migration de la version .NET 5 vers .NET 6 : inclut ASP.NET Core et Entity Framework Core.
Dépôt GitHub d’Annonces (aspnet/Annonces, 6.0.0 étiquette) : inclut des informations cassantes et non cassantes.

Types de référence annulables (TRA) et analyse statique de l'état de nullité du compilateur .NET

ASP.NET modèles de projet Core utilisent des types de référence nullables (NRT) et le compilateur .NET effectue une analyse statique à état null. Ces fonctionnalités ont été publiées avec C# 8 et sont activées par défaut pour les applications générées à l’aide de ASP.NET Core dans .NET 6 (C# 10) ou version ultérieure.

Les avertissements d’analyse statique à état null du compilateur .NET peuvent servir de guide pour mettre à jour un exemple de documentation ou un exemple d’application localement ou être ignorés. L’analyse statique à état Null peut être désactivée en définissant Nullabledisable sur le fichier projet de l’application, ce qui est recommandé uniquement pour les exemples de documentation et les exemples d’applications si les avertissements du compilateur sont distraits lors de l’apprentissage de .NET. Nous vous déconseillons de désactiver la vérification de l’état Null dans les projets de production.

Pour plus d’informations sur les NRTs, la propriété MSBuild Nullable et la mise à jour des applications, y compris des indications #pragma, consultez les ressources suivantes dans la documentation C# :

Module de base ASP.NET (ANCM)

Si le module ASP.NET Core (ANCM) n'était pas un composant sélectionné lors de l'installation de Visual Studio ou si une version antérieure de l'ANCM était installée sur le système, téléchargez le dernier programme d'installation du pack .NET Core Hosting (téléchargement direct) et exécutez l'installateur. Pour plus d'informations, consultez Pack d'hébergement.

Modification du nom de l’application

Dans .NET 6, WebApplicationBuilder normalise le chemin racine du contenu pour qu'il se termine par un DirectorySeparatorChar. La plupart des applications qui migrent depuis HostBuilder ou WebHostBuilder n’auront pas le même nom d’application, car elles ne sont pas normalisées. Pour plus d’informations, consultez SetApplicationName

Ressources supplémentaires

Exemples de code migrés vers le nouveau modèle d’hébergement minimal dans la version 6.0

Partager via

Migrer de ASP.NET Core dans .NET 5 vers .NET 6

Conditions préalables

Mettre à jour la version du Kit de développement logiciel (SDK) .NET dans global.json

Mettre à jour le framework cible

Mettre à jour les références de package

Nouveau modèle d’hébergement

Les applications qui migrent vers ou utilisant la version 6.0 ou ultérieure n’ont pas besoin d’utiliser le nouveau modèle d’hébergement minimal

Démarrez avec le nouveau modèle d'hébergement minimal

Différences entre les modèles d’hébergement ASP.NET Core dans .NET 5 et .NET 6

Création de bibliothèques pour ASP.NET Core dans .NET 6

Questions fréquemment posées (FAQ)

Blazor

Migration de projets SPA

Migration d’applications Angular à partir d’extensions SPA

Migration d’applications React à partir d’extensions SPA

Mettre à jour les images Docker

Modifications apportées au Kit de développement logiciel (SDK) ASP.NET Core Razor

Les modèles de projet utilisent Duende Identity Server

Exemples de code migrés vers ASP.NET Core dans .NET 6

Examiner les changements avec rupture

Types de référence annulables (TRA) et analyse statique de l'état de nullité du compilateur .NET

Module de base ASP.NET (ANCM)

Modification du nom de l’application

Ressources supplémentaires

Ressources supplémentaires