Partager via

Migrer d'ASP.NET Core 2.1 vers 2.2

  • Article

Par Scott Addie

Cet article explique comment mettre à jour un projet ASP.NET Core 2.1 existant vers ASP.NET Core 2.2.

Prérequis

Avertissement

Si vous utilisez Visual Studio 2017, consultez le problème no 3124 dotnet/sdk pour plus d’informations sur les versions du Kit SDK .NET Core qui ne fonctionnent pas avec Visual Studio.

Mettre à jour le Moniker du Framework cible

Les projets ciblant .NET Core doivent utiliser le TFM d'une version supérieure ou égale à .NET Core 2.2. Dans le fichier projet, mettez à jour le <TargetFramework>texte interne du nœud avec netcoreapp2.2 :

<TargetFramework>netcoreapp2.2</TargetFramework>

Les projets ciblant .NET Framework peuvent continuer à utiliser le TFM d'une version supérieure ou égale à .NET Framework 4.6.1 :

<TargetFramework>net461</TargetFramework>

Adoptez le modèle d'hébergement en cours de processus IIS

Pour adopter le modèle d'hébergement in-process pour IIS , ajoutez la propriété <AspNetCoreHostingModel> avec une valeur de InProcess à <PropertyGroup> dans le fichier projet :

<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>

Le modèle d'hébergement in-process n'est pas pris en charge pour les applications ASP.NET Core ciblant .NET Framework.

Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

Mettre à jour un fichier web.config personnalisé

Pour les projets qui utilisent un fichier web.config personnalisé à la racine du projet pour générer leur fichier web.config publié :

  • Dans l'entrée <handlers> qui ajoute le module ASP.NET Core (name="aspNetCore"), modifiez la valeur de l'attribut modules de AspNetCoreModule à AspNetCoreModuleV2.
  • Dans l'élément <aspNetCore>, ajoutez l'attribut de modèle d'hébergement (hostingModel="InProcess").

Pour plus d'informations et des exemples de fichiers web.config, consultez Module ASP.NET Core (ANCM) pour IIS.

Mettre à jour les références de package

Si vous ciblez .NET Core, supprimez l'attribut de référence Version du métapackage dans le fichier projet. L'inclusion d'un attribut Version entraîne l'avertissement suivant :

A PackageReference to 'Microsoft.AspNetCore.App' specified a Version of `2.2.0`. Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs

Pour plus d'informations, consultez Métapackage Microsoft.AspNetCore.App pour ASP.NET Core.

La référence du métapackage doit ressembler au nœud suivant <PackageReference /> :

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

Si vous ciblez .NET Framework, mettez à jour l'attribut Version de chaque référence de package vers la version 2.2.0 ou ultérieure. Voici les références de package dans un projet ASP.NET Core 2.2 typique ciblant .NET Framework :

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
  <PackageReference Include="Microsoft.AspNetCore.CookiePolicy" Version="2.2.0" />
  <PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.2.0" />
  <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
  <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
</ItemGroup>

Si vous faites référence à Microsoft.AspNetCore.Razor.Design package, mettez à jour son attribut Version vers la version 2.2.0 ou ultérieure. Si vous ne le faites pas, l'erreur suivante se produit :

Detected package downgrade: Microsoft.AspNetCore.Razor.Design from 2.2.0 to 2.1.2. Reference the package directly from the project to select a different version.

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

Si votre solution repose sur un fichier global.json pour cibler une version spécifique du SDK .NET Core, mettez à jour sa propriété version vers la version 2.2 installée sur votre ordinateur :

{
  "sdk": {
    "version": "2.2.100"
  }
}

Mettre à jour les paramètres de lancement

Si vous utilisez Visual Studio Code, mettez à jour le fichier de paramètres de lancement du projet (.vscode/launch.json). Le chemin program doit faire référence au nouveau TFM :

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (web)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/netcoreapp2.2/test-app.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart",
            "launchBrowser": {
                "enabled": true,
                "args": "${auto-detect-url}",
                "windows": {
                    "command": "cmd.exe",
                    "args": "/C start ${auto-detect-url}"
                },
                "osx": {
                    "command": "open"
                },
                "linux": {
                    "command": "xdg-open"
                }
            },
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "sourceFileMap": {
                "/Views": "${workspaceFolder}/Views"
            }
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        }
    ]
}

Mettre à jour la configuration Kestrel

Si l'application appelle UseKestrel en appelant CreateDefaultBuilder la méthode CreateWebHostBuilder de la classe Program, appelez ConfigureKestrel pour configurer le serveur Kestrel au lieu de UseKestrel afin d'éviter les conflits avec le modèle d'hébergement en cours IIS :

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureKestrel((context, options) =>
        {
            // Set properties and call methods on options
        });

Si l’application n’appelle pas CreateDefaultBuilder et crée l’hôte manuellement dans la classe Program, appelez UseKestrel avant d’appeler ConfigureKestrel :

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseKestrel()
        .UseIISIntegration()
        .UseStartup<Startup>()
        .ConfigureKestrel((context, options) =>
        {
            // Set properties and call methods on options
        })
        .Build();

    host.Run();
}

Pour plus d'informations, consultez serveur Kestrelweb dans ASP.NET Core.

Mettre à jour la version de compatibilité

Mettez à jour la version de compatibilité dans Startup.ConfigureServices à Version_2_2 :

services.AddMvc()
        .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

Mettre à jour la politique CORS

Dans ASP.NET Core 2.2, le middleware CORS répond avec une origine générique (*) si une stratégie autorise n'importe quelle origine et autorise les informations d'identification. Les informations d'identification ne sont pas prises en charge lorsqu'une origine générique (*) est spécifiée et les navigateurs interdisent la requête CORS. Pour plus d'informations, y compris les options de correction du problème sur le client, consultez la documentation Web MDN.

Pour corriger ce problème sur le serveur, effectuez l'une des actions suivantes :

  • Modifiez la stratégie CORS pour ne plus autoriser les informations d'identification. Autrement dit, supprimez l'appel à AllowCredentials lors de la configuration de la stratégie.
  • Si des informations d'identification sont requises pour que la requête CORS réussisse, modifiez la stratégie pour spécifier les hôtes autorisés. Par exemple, utilisez builder.WithOrigins("https://api.example1.com", "https://example2.com") au lieu d'utiliser AllowAnyOrigin.

Mettre à jour les images Docker

Le tableau suivant montre les modifications apportées à la balise d'image Docker :

2.1 2.2
microsoft/dotnet:2.1-aspnetcore-runtime mcr.microsoft.com/dotnet/core/aspnet:2.2
microsoft/dotnet:2.1-sdk mcr.microsoft.com/dotnet/core/sdk:2.2

Modifiez les lignes FROM de votre Dockerfile pour utiliser les nouvelles balises d'image dans la colonne 2.2 du tableau précédent.

Générer manuellement dans Visual Studio lors de l'utilisation de l'hébergement en cours IIS

Visual Studio Auto build sur l'expérience de requête du navigateur ne fonctionne pas avec le modèle d'hébergement en processus IIS. Vous devez reconstruire manuellement le projet lorsque vous utilisez l'hébergement in-process. Des améliorations de cette expérience sont prévues pour une future version de Visual Studio.

Mettre à jour le code de journalisation

Le code de configuration de journalisation recommandé n'a pas changé de 2.1 à 2.2, mais certains modèles de codage 1.x qui fonctionnaient encore dans 2.1 ne fonctionnent plus dans 2.2.

Si votre application effectue l'initialisation, le filtrage et le chargement de la configuration du fournisseur de journalisation dans la classe Startup, déplacez ce code vers Program.Main :

  • Initialisation du fournisseur :

    Exemple 1.x :

    public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole();
}

    2.2 exemple :

    
public static void Main(string[] args)
{
    var webHost = new WebHostBuilder()
        // ...
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
        })
        // ...
}

  • Filtrage :

    Exemple 1.x :

    public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(LogLevel.Information);
    // or
    loggerFactory.AddConsole((category, level) => 
        category == "A" || level == LogLevel.Critical);
}

    2.2 exemple :

    public static void Main(string[] args)
{
    var webHost = new WebHostBuilder()
        // ...
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole()
                   .AddFilter<ConsoleLoggerProvider>
                       (category: null, level: LogLevel.Information)
                   // or
                   .AddFilter<ConsoleLoggerProvider>
                       ((category, level) => category == "A" ||
                           level == LogLevel.Critical)
            );
        })
        // ...
}

  • Chargement de la configuration :

    Exemple 1.x :

    public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration);
}

    2.2 exemple :

    public static void Main(string[] args)
{
    var webHost = new WebHostBuilder()
        // ...
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
            logging.AddConsole();
        })
        // ...
}

Pour plus d’informations, consultez Journalisation dans .NET Core et ASP.NET Core

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.

Ressources supplémentaires