aspnetcore/migration/20-to-21.md
See What's new in ASP.NET Core 2.1 for an overview of the new features in ASP.NET Core 2.1.
This article:
A quick way to get an overview of the changes in 2.1 is to:
This article provides an overview on migration to ASP.NET Core 2.1. It doesn't contain a complete list of all changes needed to migrate to version 2.1. Some projects might require more steps depending on the options selected when the project was created and modifications made to the project.
Update the project file:
<TargetFramework>netcoreapp2.1</TargetFramework>.Microsoft.AspNetCore.All with a package reference for Microsoft.AspNetCore.App. You may need to add dependencies that were removed from Microsoft.AspNetCore.All. For more information, see xref:fundamentals/metapackage#migrate and xref:fundamentals/metapackage-app.Microsoft.AspNetCore.App. Projects that use <Project Sdk="Microsoft.NET.Sdk.Web"> don't need to set the version. The version is implied by the target framework and selected to best match the way ASP.NET Core 2.1 works. For more information, see the Rules for projects targeting the shared framework section.dotnet watch)dotnet ef)dotnet sql-cache)dotnet user-secrets)Microsoft.VisualStudio.Web.CodeGeneration.Tools. You can replace this tool with a globally installed version by running dotnet tool install -g dotnet-aspnet-codegenerator.<CopyRefAssembliesToPublishDirectory>true</CopyRefAssembliesToPublishDirectory> to a <PropertyGroup> in your project file.The following markup shows the template-generated 2.0 project file:
The following markup shows the template-generated 2.1 project file:
A shared framework is a set of assemblies (.dll files) that are not in the app's folders. The shared framework must be installed on the machine to run the app. For more information, see The shared framework.
ASP.NET Core 2.1 includes the following shared frameworks:
The version specified by the package reference is the minimum required version. For example, a project referencing the 2.1.1 versions of these packages won't run on a machine with only the 2.1.0 runtime installed.
Known issues for projects targeting a shared framework:
The .NET Core 2.1.300 SDK (first included in Visual Studio 15.6) set the implicit version of Microsoft.AspNetCore.App to 2.1.0 which caused conflicts with Entity Framework Core 2.1.1. The recommended solution is to upgrade the .NET Core SDK to 2.1.301 or later. For more information, see Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions.
All projects that must use Microsoft.AspNetCore.All or Microsoft.AspNetCore.App should add a package reference for the package in the project file, even if they contain a project reference to another project using Microsoft.AspNetCore.All or Microsoft.AspNetCore.App.
Example:
MyApp has a package reference to Microsoft.AspNetCore.App.MyApp.Tests has a project reference to MyApp.csproj.Add a package reference for Microsoft.AspNetCore.App to MyApp.Tests. For more information, see Integration testing is hard to set up and may break on shared framework servicing.
In ASP.NET Core 2.1, the Docker images migrated to the dotnet/dotnet-docker GitHub repository. The following table shows the Docker image and tag changes:
| 2.0 | 2.1 |
|---|---|
| microsoft/aspnetcore:2.0 | microsoft/dotnet:2.1-aspnetcore-runtime |
| microsoft/aspnetcore-build:2.0 | microsoft/dotnet:2.1-sdk |
Change the FROM lines in your Dockerfile to use the new image names and tags in the preceding table's 2.1 column. For more information, see Migrating from aspnetcore docker repos to dotnet.
The following images show the changes made to the templated generated Program.cs file.
The preceding image shows the 2.0 version with the deletions in red.
The following image shows the 2.1 code. The code in green replaced the 2.0 version:
The following code shows the 2.1 version of Program.cs:
The new Main replaces the call to BuildWebHost with xref:Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory%601.CreateWebHostBuilder%2A. xref:Microsoft.AspNetCore.Hosting.IWebHostBuilder was added to support a new integration test infrastructure.
The following code shows the changes to 2.1 template generated code. All changes are newly added code, except that UseBrowserLink has been removed:
The preceding code changes are detailed in:
CookiePolicyOptions and UseCookiePolicy.UseHsts.UseHttpsRedirection.SetCompatibilityVersion(CompatibilityVersion.Version_2_1).ASP.NET Core 2.1 provides ASP.NET Core Identity as a Razor class library (RCL).
The default 2.1 Identity UI doesn't currently provide significant new features over the 2.0 version. Replacing Identity with the RCL package is optional. The advantages to replacing the template generated Identity code with the RCL version include:
Microsoft.AspNetCore.App is updated.If you've made non-trivial changes to the template generated Identity code:
Identity 2.1 exposes endpoints with the Identity area. For example, the follow table shows examples of Identity endpoints that change from 2.0 to 2.1:
| 2.0 URL | 2.1 URL |
|---|---|
| /Account/Login | /Identity/Account/Login |
| /Account/Logout | /Identity/Account/Logout |
| /Account/Manage | /Identity/Account/Manage |
Applications that have code using Identity and replace 2.0 Identity UI with the 2.1 Identity Library need to take into account Identity URLs have /Identity segment prepended to the URIs. One way to handle the new Identity endpoints is to set up redirects, for example from /Account/Login to /Identity/Account/Login.
The following options are available to update Identity to 2.1.
This section outlines the steps to replace the ASP.NET Core 2.0 template-generated Identity code with the ASP.NET Core Identity Razor class library. The following steps are for a Razor Pages project, but the approach for an MVC project is similar.
Delete the Identity scaffolder generated IdentityDbContext derived class in the Areas/Identity/Data/ folder.
Delete Areas/Identity/IdentityHostingStartup.cs.
Update the _LoginPartial.cshtml file:
asp-area="Identity" to the form and anchor links.<form /> element to <form asp-area="Identity" asp-page="/Account/Logout" asp-route-returnUrl="@Url.Page("/Index", new { area = "" })" method="post" id="logoutForm" class="navbar-right">.The following code shows the updated _LoginPartial.cshtml file:
Update ConfigureServices with the following code:
Move Pages/_Layout.cshtml to Pages/Shared/_Layout.cshtml
In Areas/Identity/Pages/_ViewStart.cshtml, change Layout = "/Pages/_Layout.cshtml" to Layout = "/Pages/Shared/_Layout.cshtml".
The _Layout.cshtml file has the following changes:
<partial name="_CookieConsentPartial" /> is added. For more information, see GDPR support in ASP.NET Core.The following files are added:
Privacy.cshtmlPrivacy.cshtml.csSee GDPR support in ASP.NET Core for information on the preceding files.
The Layout.cshtml file has the following changes:
<partial name="_CookieConsentPartial" /> is added.jquery.validate/1.14.0 changes to jquery.validate/1.17.0
The following are added:
Views/Home/Privacy.cshtmlPrivacy action method is added to the Home controller.See GDPR support in ASP.NET Core for information on the preceding files.
As ASP.NET Core apps now use HTTPS by default, the Properties/launchSettings.json file has changed.
The following JSON shows the earlier 2.0 template-generated launchSettings.json file:
The following JSON shows the new 2.1 template-generated launchSettings.json file:
For more information, see xref:security/enforcing-ssl.
Use the articles in Breaking changes in .NET to find breaking changes that might apply when upgrading an app to a newer version of .NET.
xref:Microsoft.AspNetCore.Mvc.FileResult no longer processes the Accept-Ranges header by default. To enable the Accept-Ranges header, set xref:Microsoft.AspNetCore.Mvc.FileResult.EnableRangeProcessing to true.
The following xref:Microsoft.AspNetCore.Mvc.ControllerBase methods no longer processes the Accept-Ranges header by default:
To enable the Accept-Ranges header, set the EnableRangeProcessing parameter to true.