Migrer d'ASP.NET Core 5.0 vers 6.0

Article
11/30/2023

Cet article explique comment mettre à jour un projet ASP.NET Core 5.0 existant vers ASP.NET Core 6.0. Pour obtenir des instructions sur la migration d'ASP.NET Core 3.1 vers ASP.NET Core 6.0, consultez Migrer d'ASP.NET Core 3.1 vers 6.0.

Prérequis

Visual Studio 2022 avec la charge de travail Développement web et ASP.NET.
SDK .NET 6.0

Mettre à jour la version du SDK .NET dans global.json

Si vous comptez sur un fichier global.json pour cibler une version spécifique du SDK .NET, mettez à jour la propriété version vers la version du SDK .NET 6.0 qui est 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 chaque attribut de référence de package Microsoft.AspNetCore.* et Microsoft.Extensions.*Version vers 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 nécessite un seul fichier et quelques lignes de code. Les applications migrant vers la version 6.0 n'ont pas besoin d'utiliser le nouveau modèle d'hébergement minimal. Pour plus d'informations, voir Les applications migrant vers la version 6.0 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();

Le modèle d'hébergement minimal :

Réduit considérablement le nombre de fichiers et de lignes de code nécessaires 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 fichier Program.cs.
Utilise des instructions de niveau supérieur pour réduire le code nécessaire pour une application.
Utilise des directives using globales pour éliminer ou réduire le nombre de lignes d’instructionusing nécessaires.

Le code suivant affiche les fichiers Startup.cs et Program.cs d'un modèle d'application Web ASP.NET Core 5 (Razor Pages) avec les instructions inutilisées supprimées using :

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 6, le code précédent est remplacé par le suivant :

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 6 précédent montre comment :

ConfigureServices est remplacé par WebApplication.Services.
builder.Build() renvoie un configuré WebApplication à la variable app. Configure est remplacé par des appels de configuration aux mêmes services à l'aide de app.

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

Quelques modifications ont été 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 dans Error.cshtml est déclaré comme un type de référence nullable (NRT) :

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

Les valeurs par défaut du niveau de journalisation ont changé dans appsettings.json et appsettings.Development.json :

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

Dans le code de modèle ASP.NET Core précédent, "Microsoft": "Warning" a été remplacé par "Microsoft.AspNetCore": "Warning". Cette modification entraîne la journalisation de tous les messages d’information de l’espace de noms Microsoft, à l’exception de Microsoft.AspNetCore. Par exemple, Microsoft.EntityFrameworkCore est désormais journalisé au niveau des informations.

Pour plus de détails sur le nouveau modèle d'hébergement, consultez la section Foire aux questions. Pour plus d'informations sur l'adoption des NRT et de l'analyse de l'état nul du compilateur .NET, consultez la section Types de référence Nullable (NRT) et analyse statique de l'état nul du compilateur .NET.

Les applications migrant vers ou utilisant 6.0 et versions ultérieures n'ont pas besoin d'utiliser le nouveau modèle d'hébergement minimal

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

Utilisez Startup avec le nouveau modèle d'hébergement minimal

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

Aucune réflexion cachée n'est utilisée pour appeler la classe Startup.
Le code asynchrone peut être écrit car le développeur contrôle l'appel à Startup.
Le code peut être écrit qui entrelace ConfigureServices et Configure.

Une limitation mineure dans 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 manuellement.

Considérez le code suivant généré par le modèle Pages Razor ASP.NET Core 3.1 ou 5.0 :

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 blocage if (env.IsDevelopment()) est supprimé car en mode développement, le middleware de la page d'exception développeur est activé par défaut. Pour plus d'informations, consultez Différences entre les modèles d'hébergement ASP.NET Core 5 et 6 dans la section suivante.

Lorsque vous utilisez un conteneur d'injection de dépendance (DI) personnalisé, 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();
        });
    }
}

Lors de l'utilisation du modèle d'hébergement minimal, le middleware de routage du point de terminaison encapsule l'ensemble du pipeline middleware, il n'est donc pas nécessaire d'avoir des appels explicites vers UseRouting ou UseEndpoints pour enregistrer des routes. UseRouting peut toujours être utilisé pour spécifier où la correspondance de route se produit, mais UseRouting n'a pas besoin d'être explicitement appelée si les routes doivent être mises en correspondance au début du pipeline middleware.

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 avec 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 classe Startup.
Tous les services supplémentaires injectés dans la méthode Configure doivent être résolus manuellement par la classe Program.

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

En mode développement, le middleware de la page d'exception développeur est activé par défaut.
Le nom de l'application est par défaut le nom de l'assemblée du point d'entrée : Assembly.GetEntryAssembly().GetName().FullName. Lors de l'utilisation de WebApplicationBuilder dans une bibliothèque, remplacez explicitement le nom de l'application par l'assemblée de la bibliothèque pour permettre à la découverte de composants d'application de MVC de fonctionner. Voir Modifier la racine du contenu, le nom de l'application et l'environnement dans ce document pour des instructions détaillées.
Le middleware de routage de point de terminaison encapsule l'ensemble du pipeline middleware, il n'est donc pas nécessaire d'avoir des appels explicites vers UseRouting ou UseEndpoints pour enregistrer des routes. UseRouting peut toujours être utilisé pour spécifier où la correspondance de route se produit, mais UseRouting n'a pas besoin d'être explicitement appelée si les routes doivent être mises en correspondance au début du pipeline middleware.
Le pipeline est créé avant toute exécution IStartupFilter. Par conséquent, les exceptions provoquées lors de la construction du pipeline ne sont pas visibles pour la chaîne d'appel IStartupFilter.
Certains outils, tels que les migrations EF, permettent d'accéder Program.CreateHostBuilder à l'application IServiceProvider pour exécuter une 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 manière. Nous nous efforçons de 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 étendue DI pendant l’instanciation du fournisseur de services. Pour les contextes où une étendue est nécessaire, vous devez 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 de l'hôte tels que le nom de l'application, l'environnement ou la racine du contenu après la création du fichierWebApplicationBuilder. Pour obtenir des instructions détaillées sur la modification des paramètres de l'hôte, consultez Personnaliser IHostBuilder ou IWebHostBuilder. Les API en surbrillance suivantes génèrent 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 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 diffère pas l'exécution des méthodes ConfigureServices, ConfigureAppConfiguration ou ConfigureHostConfiguration. Ne pas différer l'exécution permet au code WebApplicationBuilder d'observer les modifications apportées aux IServiceCollection et IConfiguration. L'exemple suivant ajoute uniquement Service1 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 rappel builder.Host.ConfigureServices est appelé en ligne plutôt que d'être différé jusqu'à ce que builder.Build soit appelé. Cela signifie que Service1 s'ajoute à IServiceCollection d'avant Service2 et se traduit par Service1 en étant une résolution pour IService.

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

L'écosystème .NET existant a construit l'extensibilité autour de IServiceCollection, IHostBuilder et IWebHostBuilder. Ces propriétés sont disponibles sur WebApplicationBuilder comme Services, Host, et WebHost.

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

Nous nous attendons à ce que les auteurs de bibliothèques continuent de cibler IHostBuilder, IWebHostBuilder, IApplicationBuilder, et IEndpointRouteBuilder lors de la création de composants spécifiques à ASP.NET Core. Cela garantit que votre middleware, votre gestionnaire de routage ou d'autres points d'extensibilité continuent de fonctionner sur différents modèles d'hébergement.

Forum Aux Questions (FAQ)

Le nouveau modèle d'hébergement minimal est-il moins performant ?

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

Non. Le modèle d'hébergement générique est un modèle alternatif pris en charge indéfiniment. L'hôte générique sous-tend le nouveau modèle d'hébergement et reste le principal moyen d'héberger des applications basées sur les travailleurs.
Dois-je migrer vers le nouveau modèle d'hébergement ?

Non. Le nouveau modèle d'hébergement est le moyen privilégié pour héberger de nouvelles applications à l'aide de .NET 6 et versions ultérieures, mais vous n'êtes pas obligé de modifier la disposition du projet dans les applications existantes. Cela signifie que les applications peuvent passer de .NET 5 à .NET 6 en modifiant le framework cible dans le fichier projet de net5.0 à net6.0. Pour plus d'informations, consultez la section Mettre à jour le framework cible de cet article. Cependant, nous recommandons aux applications de migrer vers le nouveau modèle d'hébergement pour profiter 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 a été stocké sous forme de champs dans ma classe Program ou Startup ?

Nous vous recommandons vivement d'utiliser l'injection de dépendance (DI) pour l'état du flux dans les applications ASP.NET Core.

Il existe deux approches pour stocker l'état en dehors de DI :
- Stocke l'état dans une autre classe. Le stockage dans une classe suppose un état statique accessible depuis n'importe où dans l'application.
- Utilisez la classe Program générée par les instructions de niveau supérieur pour stocker l'état. Utiliser 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; }
}
```
Et 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 Conteneur d'injection de dépendance (DI) personnalisé.
Est-ce que WebApplicationFactory et TestServer travaillent encore ?

Oui. WebApplicationFactory<TEntryPoint> est le moyen de tester le nouveau modèle d'hébergement. Pour un exemple, voir Tester avec WebApplicationFactory ou TestServer.

Blazor

Après avoir suivi les instructions plus haut dans cet article pour mettre à jour une application vers la version 6.0, adoptez des fonctionnalités spécifiques en suivant les liens dans Nouveautés d'ASP.NET Core 6.0.

Pour adopter toutes les nouvelles fonctionnalités 6.0 pour les Blazor applications , nous vous recommandons de suivre la procédure suivante :

Créez un nouveau projet 6.0 Blazor à partir de l'un des modèles de projet Blazor. 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 6.0.

Migration de projets SPA

Migrer des applications angulaires à partir d'extensions SPA

Voir ce problème GitHub

Migrer des applications React à partir d'extensions SPA

Voir Migration des applications React à partir des extensions Spa dans ce numéro GitHub

Mettre à jour les images Docker

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

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

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

Modifications apportées au Razor SDK ASP.NET Core

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

La compilation s'est appuyée sur les cibles RazorGenerate et RazorCompile pour produire le code généré. Ces objectifs ne sont plus valables. Dans .NET 6, la génération et la compilation de code 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 génération.
Une assemblée séparée Razor,AppName.Views.dll, a été généré et contient les types de vue compilés dans une application. Ce comportement a été déprécié et une seule assemblée AppName.dll est produite qui contient à la fois les types d'application et les vues générées.
Les types d'applications dans AppName.Views.dll étaient publics. Dans .NET 6, les types d'application sont dans AppName.dll mais sont internal sealed. Les applications effectuant la découverte de type sur AppName.Views.dll ne pourront pas effectuer de découverte de type sur AppName.dll. Voici 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 changements suivants :

Les propriétés suivantes ne sont plus applicables avec le 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’assemblée Views.

Les modèles de projet utilisent Duende Server Identity

Les modèles de projet utilisent désormais Duende Identity Server. Pour obtenir des conseils sur la migration, consultez la section IdentityServer4 v4.1 vers Duende IdentityServer v5.

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, voir Logiciel Duende : Licences.

Pour savoir comment utiliser Microsoft Azure Active Directory pour ASP.NET Core Identity, consultez Identity (dotnet/aspnetcore GitHub repository).

Ajoutez une propriété DbSet<Key> 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 Server Identity.

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

Notes

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

Échantillons de code migrés vers ASP.NET Core 6.0

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

Examiner les changements avec rupture

Consultez les ressources suivantes :

Identity : La version Bootstrap par défaut de l'interface utilisateur a été modifiée
Modifications avec rupture pour la migration de la version 5.0 vers la version 6.0 : Inclut ASP.NET Core et Entity Framework Core.
Référentiel GitHub d'annonces (aspnet/Annonces, 6.0.0 étiquette) : inclut des informations de rupture et ininterrompues.

Analyse statique des types de référence nullables (NRT) et de l’état null du compilateur .NET

Les modèles de projet ASP.NET Core utilisent des types de référence nullables (NRT) et le compilateur .NET effectue une analyse statique à l'état nul. 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 d'ASP.NET Core 6.0 (C# 10) ou version ultérieure.

Les avertissements d'analyse statique à l'état nul du compilateur .NET peuvent soit servir de guide pour mettre à jour un exemple de documentation ou un exemple d'application localement, soit être ignorés. L'analyse statique à l'état nul peut être désactivée en définissant Nullable sur disable dans le fichier de projet de l'application, ce que nous recommandons uniquement pour les exemples de documentation et les exemples d'applications si les avertissements du compilateur dérangent lors de l'apprentissage de .NET. Nous vous déconseillons de désactiver la vérification de l'état nul dans les projets de production.

Pour plus d'informations sur les NRT, la propriété MSBuild Nullable et la mise à jour des applications (y compris des conseils #pragma), consultez les ressources suivantes dans la documentation C# :

Module ASP.NET Core (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.

Changement de 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 migrées depuis HostBuilder ou WebHostBuilder n'auront pas le même nom d'application car elles ne sont pas normalisées. Pour plus d'informations, voir SetApplicationName

Ressources supplémentaires

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

Partager via

Migrer d'ASP.NET Core 5.0 vers 6.0

Prérequis

Mettre à jour la version du 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 migrant vers ou utilisant 6.0 et versions ultérieures n'ont pas besoin d'utiliser le nouveau modèle d'hébergement minimal

Utilisez Startup avec le nouveau modèle d'hébergement minimal

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

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

Forum Aux Questions (FAQ)

Blazor

Migration de projets SPA

Migrer des applications angulaires à partir d'extensions SPA

Migrer des applications React à partir d'extensions SPA

Mettre à jour les images Docker

Modifications apportées au Razor SDK ASP.NET Core

Les modèles de projet utilisent Duende Server Identity

Échantillons de code migrés vers ASP.NET Core 6.0

Examiner les changements avec rupture

Analyse statique des types de référence nullables (NRT) et de l’état null du compilateur .NET

Module ASP.NET Core (ANCM)

Changement de nom de l'application

Ressources supplémentaires

Ressources supplémentaires