Eseguire la migrazione da ASP.NET Core 2.1 a 2.2
Di Scott Addie
Questo articolo illustra come aggiornare un progetto ASP.NET Core 2.1 esistente a ASP.NET Core 2.2.
Prerequisiti
- Visual Studio 2019 con il carico di lavoro Sviluppo ASP.NET e Web
- .NET Core SDK 2.2 o versione successiva
Avviso
Se si usa Visual Studio 2017, vedere dotnet/sdk issue #3124 per informazioni sulle versioni di .NET Core SDK che non funzionano con Visual Studio.
Aggiornare Moniker della versione di .NET Framework di destinazione (TFM, Target Framework Moniker)
I progetti destinati a .NET Core devono usare il TFM di una versione successiva o uguale a .NET Core 2.2. Nel file di progetto aggiornare il <TargetFramework> testo interno del nodo con netcoreapp2.2:
<TargetFramework>netcoreapp2.2</TargetFramework>
I progetti destinati a .NET Framework possono continuare a usare il TFM di una versione successiva o uguale a .NET Framework 4.6.1:
<TargetFramework>net461</TargetFramework>
Adottare il modello di hosting in-process di IIS
Per adottare il modello di hosting in-process per IIS, aggiungere la <AspNetCoreHostingModel> proprietà con un valore di InProcess a nel <PropertyGroup> file di progetto:
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
Il modello di hosting in-process non è supportato per le app ASP.NET Core destinate a .NET Framework.
Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.
Aggiornare un file web.config personalizzato
Per i progetti che usano un file web.config personalizzato nella radice del progetto per generare il file web.config pubblicato:
<handlers>Nella voce che aggiunge l'ASP.NET Core Module (name="aspNetCore"), modificare il valore dell'attributomodulesdaAspNetCoreModuleaAspNetCoreModuleV2.- Nell'elemento
<aspNetCore>aggiungere l'attributo del modello di hosting (hostingModel="InProcess").
Per altre informazioni ed esempi di file web.config , vedere ASP.NET Core Module (ANCM) per IIS.
Aggiornare i riferimenti del pacchetto
Se la destinazione è .NET Core, rimuovere l'attributo del riferimento al metapacchetto nel file di Version progetto. L'inclusione di un Version attributo genera l'avviso seguente:
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
Per altre informazioni, vedere Microsoft.AspNetCore.App metapacchetto per ASP.NET Core.
Il riferimento al metapacchetto dovrebbe essere simile al nodo seguente <PackageReference /> :
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
Se la destinazione è .NET Framework, aggiornare l'attributo di ogni riferimento al Version pacchetto alla versione 2.2.0 o successiva. Ecco i riferimenti ai pacchetti in un tipico progetto ASP.NET Core 2.2 destinato a .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>
Se si fa riferimento a Microsoft.AspNetCore.Razor. Progettare il pacchetto, aggiornarne Version l'attributo alla versione 2.2.0 o successiva. In caso contrario, si verifica l'errore seguente:
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.
Aggiornare la versione di .NET Core SDK in global.json
Se la soluzione si basa su un global.json file per specificare una versione specifica di .NET Core SDK, aggiornarne version la proprietà alla versione 2.2 installata nel computer:
{
"sdk": {
"version": "2.2.100"
}
}
Aggiornare le impostazioni di avvio
Se si usa Visual Studio Code, aggiornare il file delle impostazioni di avvio del progetto (.vscode/launch.json). Il program percorso deve fare riferimento al nuovo 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}"
}
]
}
Aggiornare la Kestrel configurazione
Se l'app chiama UseKestrel il metodo CreateWebHostBuilder della Program classe , chiamare ConfigureKestrel per configurare Kestrel il server anziché per evitare conflitti con il modello di UseKestrel hosting in-process iis: CreateDefaultBuilder
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureKestrel((context, options) =>
{
// Set properties and call methods on options
});
Se l'app non chiama CreateDefaultBuilder e compila manualmente l'host nella Program classe , chiamare prima di chiamare ConfigureKestrelUseKestrel :
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();
}
Per altre informazioni, vedere Kestrel Server Web in ASP.NET Core.
Aggiornare la versione di compatibilità
Aggiornare la versione di compatibilità in Startup.ConfigureServices in :Version_2_2
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
Aggiornare i criteri CORS
In ASP.NET Core 2.2, il middleware CORS risponde con un'origine con caratteri jolly (*) se un criterio consente qualsiasi origine e consente le credenziali. Le credenziali non sono supportate quando viene specificata un'origine con caratteri jolly (*) e i browser non consentono la richiesta CORS. Per altre informazioni, incluse le opzioni per correggere il problema nel client, vedere la documentazione Web mdn.
Per risolvere il problema nel server, eseguire una delle azioni seguenti:
- Modificare i criteri CORS per non consentire più le credenziali. In altri casi, rimuovere la chiamata a AllowCredentials quando si configurano i criteri.
- Se le credenziali sono necessarie affinché la richiesta CORS abbia esito positivo, modificare i criteri per specificare gli host consentiti. Ad esempio, usare
builder.WithOrigins("https://api.example1.com", "https://example2.com")anziché usare AllowAnyOrigin.
Aggiornare le immagini Docker
La tabella seguente mostra le modifiche apportate al tag immagine 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 |
Modificare le FROM righe nel Dockerfile per usare i nuovi tag immagine nella colonna 2.2 della tabella precedente.
Compilare manualmente in Visual Studio quando si usa l'hosting in-process di IIS
La compilazione automatica di Visual Studio nell'esperienza di richiesta del browser non funziona con il modello di hosting in-process di IIS. È necessario ricompilare manualmente il progetto quando si usa l'hosting in-process. I miglioramenti apportati a questa esperienza sono pianificati per una versione futura di Visual Studio.
Aggiornare il codice di registrazione
Il codice di configurazione della registrazione consigliato non è stato modificato da 2.1 a 2.2, ma alcuni modelli di codifica 1.x ancora funzionanti nella versione 2.1 non funzionano più nella versione 2.2.
Se l'app registra l'inizializzazione, il filtro e il caricamento della configurazione del Startup provider nella classe , spostare il codice in Program.Main:
Inizializzazione del provider:
Esempio 1.x:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(); }2.2 esempio:
public static void Main(string[] args) { var webHost = new WebHostBuilder() // ... .ConfigureLogging((hostingContext, logging) => { logging.AddConsole(); }) // ... }Filtro:
Esempio 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 esempio:
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) ); }) // ... }Caricamento della configurazione:
Esempio 1.x:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(Configuration); }2.2 esempio:
public static void Main(string[] args) { var webHost = new WebHostBuilder() // ... .ConfigureLogging((hostingContext, logging) => { logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); logging.AddConsole(); }) // ... }
Per altre informazioni, vedere Registrazione in .NET Core e ASP.NET Core
modulo ASP.NET core (ANCM)
Se la ASP.NET Core Module (ANCM) non è un componente selezionato quando Visual Studio è stato installato o se è stata installata una versione precedente di ANCM nel sistema, scaricare l'ultimo programma di installazione del bundle di hosting .NET Core (download diretto) ed eseguire il programma di installazione. Per altre informazioni, vedere Bundle di hosting.
