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.
* Replace the package reference for `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>.
* Remove the "Version" attribute on the package reference to `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](#rules-for-projects-targeting-the-shared-framework) section.
* Remove references to **<DotNetCliToolReference>** elements for the following packages. These tools are bundled by default in the .NET Core CLI and don't need to be installed separately.
* Optional: you can remove the **<DotNetCliToolReference>** element for `Microsoft.VisualStudio.Web.CodeGeneration.Tools`. You can replace this tool with a globally installed version by running `dotnet tool install -g dotnet-aspnet-codegenerator`.
* For 2.1, a [Razor Class Library](xref:razor-pages/ui-class) is the recommended solution to distribute Razor files. If your app uses embedded views, or otherwise relies on runtime compilation of Razor files, add `<CopyRefAssembliesToPublishDirectory>true</CopyRefAssembliesToPublishDirectory>` to a `<PropertyGroup>` in your 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](https://natemcmaster.com/blog/2018/08/29/netcore-primitives-2/).
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.
* 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](https://github.com/aspnet/Universe/issues/1180).
* 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`.
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](https://github.com/dotnet/aspnetcore/issues/3156).
In ASP.NET Core 2.1, the Docker images migrated to the [dotnet/dotnet-docker GitHub repository](https://github.com/dotnet/dotnet-docker). The following table shows the Docker image and tag changes:
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](https://github.com/aspnet/Announcements/issues/298).
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](xref:test/integration-tests).
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:
* Many files are moved out of your source tree.
* Any bug fixes or new features to Identity are included in the [Microsoft.AspNetCore.App metapackage](xref:fundamentals/metapackage-app). You automatically get the updated Identity when `Microsoft.AspNetCore.App` is updated.
If you've made non-trivial changes to the template generated Identity code:
* You can keep your ASP.NET Core 2.0 Identity code, it's fully supported.
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:
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`.
* Use the Identity UI 2.0 code with no changes. Using Identity UI 2.0 code is fully supported. This is a good approach when significant changes have been made to the generated Identity code.
* Delete your existing Identity 2.0 code and [Scaffold Identity](xref:security/authentication/scaffold-identity) into your project. Your project will use the [ASP.NET Core Identity](xref:security/authentication/identity) [Razor Class Library](xref:razor-pages/ui-class). You can generate code and UI for any of the Identity UI code that you modified. Apply your code changes to the newly scaffolded UI code.
* Delete your existing Identity 2.0 code and [Scaffold Identity](xref:security/authentication/scaffold-identity) into your project with the option to **Override all files**.
### Replace Identity 2.0 UI with the Identity 2.1 Razor Class Library
This section outlines the steps to replace the ASP.NET Core 2.0 template generated Identity code with the [ASP.NET Core Identity](xref:security/authentication/identity) [Razor Class Library](xref:razor-pages/ui-class). The following steps are for a Razor Pages project, but the approach for an MVC project is similar.
* Verify the [project file is updated to use 2.1 versions](#update-the-project-file-to-use-21-versions)
* Delete the following folders and all the files in them:
* *Controllers*
* *Pages/Account/*
* *Extensions*
* Build the project.
* [Scaffold Identity](xref:security/authentication/scaffold-identity) into your project:
* Select the **+** icon on the right side of the **Data context class**. Accept the default name.
* Select **Add** to create a new Data context class. Creating a new data context is required for to scaffold. You remove the new data context in the next section.
* Update the `<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">`.
<xref:Microsoft.AspNetCore.Mvc.FileResult> no longer processes the [Accept-Ranges](https://developer.mozilla.org/docs/Web/HTTP/Headers/Accept-Ranges) header by default. To enable the `Accept-Ranges` header, set <xref:Microsoft.AspNetCore.Mvc.FileResult.EnableRangeProcessing> to `true`.
### ControllerBase.File and PhysicalFile Range header
The following <xref:Microsoft.AspNetCore.Mvc.ControllerBase> methods no longer processes the [Accept-Ranges](https://developer.mozilla.org/docs/Web/HTTP/Headers/Accept-Ranges) header by default:
