ASP.NET Core 1.x에서 2.0으로 마이그레이션
작성자: Scott Addie
이 문서에서는 기존 ASP.NET Core 1.x 프로젝트를 ASP.NET Core 2.0으로 업데이트하는 과정을 안내합니다. 애플리케이션을 ASP.NET Core 2.0으로 마이그레이션하면 여러 가지 새로운 기능 및 향상된 성능을 활용할 수 있습니다.
기존 ASP.NET Core 1.x 애플리케이션은 버전별 프로젝트 템플릿을 기반으로 합니다. ASP.NET Core 프레임워크가 진화함에 따라 프로젝트 템플릿 및 포함된 시작 코드도 함께 진화합니다. ASP.NET Core 프레임워크를 업데이트하는 것 외에도 애플리케이션에 대한 코드를 업데이트해야 합니다.
필수 조건
ASP.NET Core 시작을 참조하세요.
TFM(대상 프레임워크 모니커) 업데이트
.NET Core를 대상으로 하는 프로젝트는 .NET Core 2.0보다 크거나 같은 버전의 TFM을 사용해야 합니다. 파일에서 노드를 <TargetFramework> .csproj 검색하고 내부 텍스트를 다음으로 netcoreapp2.0바꿉다.
<TargetFramework>netcoreapp2.0</TargetFramework>
.NET Framework를 대상으로 하는 프로젝트는 .NET Framework 4.6.1보다 크거나 같은 버전의 TFM을 사용해야 합니다. 파일에서 노드를 <TargetFramework> .csproj 검색하고 내부 텍스트를 다음으로 net461바꿉다.
<TargetFramework>net461</TargetFramework>
참고 항목
.NET Core 2.0은 .NET Core 1.x보다 훨씬 더 큰 노출 영역을 제공합니다. .NET Core 1.x에 API가 없기 때문에 전적으로 .NET Framework를 대상으로 하는 경우 .NET Core 2.0을 대상으로 하는 것은 작동할 가능성이 있습니다.
프로젝트 파일에 <RuntimeFrameworkVersion>1.{sub-version}</RuntimeFrameworkVersion>이 포함된 경우에는 이 GitHub 문제를 참조하세요.
에서 .NET Core SDK 버전 업데이트 global.json
솔루션이 global.json 특정 .NET Core SDK 버전을 대상으로 하는 파일에 의존하는 경우 컴퓨터에 설치된 2.0 버전을 사용하도록 해당 version 속성을 업데이트합니다.
{
"sdk": {
"version": "2.0.0"
}
}
패키지 참조 업데이트
1.x 프로젝트의 파일에는 .csproj 프로젝트에서 사용하는 각 NuGet 패키지가 나열됩니다.
.NET Core 2.0을 대상으로 하는 ASP.NET Core 2.0 프로젝트에서 파일의 단일 메타패키지 참조 .csproj 가 패키지 컬렉션을 대체합니다.
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.9" />
</ItemGroup>
ASP.NET Core 2.0 및 Entity Framework Core 2.0의 모든 기능은 metapackage에 포함됩니다.
.NET Framework를 대상으로 하는 ASP.NET Core 2.0 프로젝트는 계속해서 개별 NuGet 패키지를 참조해야 합니다. 각 <PackageReference /> 노드의 Version 특성을 2.0.0으로 업데이트합니다.
예를 들어 다음은 .NET Framework를 대상으로 하는 일반적인 ASP.NET Core 2.0 프로젝트에 사용되는 <PackageReference /> 노드의 목록입니다.
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.0" PrivateAssets="All" />
</ItemGroup>
Microsoft.Extensions.CommandLineUtils 패키지는 더 이상 사용되지 않습니다. 이것은 여전히 제공되기는 하지만, 지원되지 않습니다.
.NET CLI 도구 업데이트
.csproj 파일에서 각 <DotNetCliToolReference /> 노드의 특성을 2.0.0으로 업데이트 Version 합니다.
예를 들어 다음은 .NET Core 2.0을 대상으로 하는 일반적인 ASP.NET Core 2.0 프로젝트에 사용되는 CLI 도구의 목록입니다.
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" />
<DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="2.0.0" />
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
패키지 대상 대체 속성의 이름 바꾸기
1.x 프로젝트의 파일은 .csproj 노드 및 변수를 PackageTargetFallback 사용했습니다.
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
노드 및 변수의 이름을 모두 AssetTargetFallback으로 바꾸기:
<AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wp8+wpa81;</AssetTargetFallback>
Program.cs의 Main 메서드 업데이트
1.x 프로젝트에서 메서드 Program.cs 는 Main 다음과 같습니다.
using System.IO;
using Microsoft.AspNetCore.Hosting;
namespace AspNetCoreDotNetCore1App
{
public class Program
{
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
host.Run();
}
}
}
2.0 프로젝트에서 메서드 Program.cs 가 Main 간소화되었습니다.
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
namespace AspNetCoreDotNetCore2App
{
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
}
}
이 새로운 2.0 패턴의 도입은 적극 권장되며 EF(Entity Framework) Core 마이그레이션과 같은 제품 기능을 작동하는 데 필요합니다. 예를 들어 패키지 관리자 콘솔 창에서 Update-Database 또는 명령줄(ASP.NET Core 2.0으로 변환되는 프로젝트에서)에서 dotnet ef database update 실행은 다음 오류를 생성합니다.
Unable to create an object of type '<Context>'. Add an implementation of 'IDesignTimeDbContextFactory<Context>' to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.
구성 공급자 추가
1.x 프로젝트에서는 Startup 생성자를 통해 앱에 구성 공급자를 추가했습니다. 이 단계에는 ConfigurationBuilder의 인스턴스 만들기, 해당 공급자(환경 변수, 앱 설정 등) 로드 및 IConfigurationRoot의 멤버 초기화와 같은 작업이 포함되었습니다.
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
if (env.IsDevelopment())
{
builder.AddUserSecrets<Startup>();
}
builder.AddEnvironmentVariables();
Configuration = builder.Build();
}
public IConfigurationRoot Configuration { get; }
위의 예제에서는 IHostingEnvironment.EnvironmentName 속성과 일치하는 appsettings.{Environment}.json 파일뿐만 아니라, appsettings.json의 구성 설정을 사용하여 Configuration 멤버를 로드합니다. 이러한 파일의 위치는 .와 동일한 경로 Startup.cs에 있습니다.
2.0 프로젝트에서 1.x 프로젝트에 포함된 기본 구성 코드는 백그라운드에서 실행됩니다. 예를 들어 환경 변수 및 앱 설정은 시작 시 로드됩니다. 해당하는 Startup.cs 코드는 삽입된 인스턴스를 사용하여 초기화로 IConfiguration 축소됩니다.
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
WebHostBuilder.CreateDefaultBuilder를 추가하여 기본 공급자를 제거하려면 ConfigureAppConfiguration 내부의 IConfigurationBuilder.Sources 속성에서 Clear 메서드를 호출합니다. 공급자를 다시 추가하려면 다음에서 메서드를 ConfigureAppConfiguration 활용합니다.Program.cs
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureAppConfiguration((hostContext, config) =>
{
// delete all default configuration providers
config.Sources.Clear();
config.AddJsonFile("myconfig.json", optional: true);
})
.Build();
이전 코드 조각의 CreateDefaultBuilder 메서드에서 사용하는 구성은 여기에서 확인할 수 있습니다.
자세한 내용은 ASP.NET Core의 구성을 참조하세요.
데이터베이스 초기화 코드 이동
EF Core 1.x를 사용하는 1.x 프로젝트에서 dotnet ef migrations add와 같은 명령은 다음을 수행합니다.
Startup인스턴스를 인스턴스화합니다.ConfigureServices메서드를 호출하여 종속성 주입을 통해 모든 서비스를 등록합니다(DbContext형식 포함).- 필수 작업을 수행합니다.
EF Core 2.0을 사용하는 2.0 프로젝트에서는 애플리케이션 서비스를 가져오기 위해 Program.BuildWebHost가 호출됩니다. 1.x와 달리 2.0 프로젝트에서는 Startup.Configure를 호출하는 데 부작용이 추가로 발생합니다. 1.x 앱이 Configure 메서드에서 데이터베이스 초기화 코드를 호출한 경우 예기치 않은 문제가 발생할 수 있습니다. 예를 들어, 데이터베이스가 아직 없는 경우, EF Core 마이그레이션 명령 실행 전에 시드 코드가 실행됩니다. 아직 데이터베이스가 없는 경우 이 문제가 dotnet ef migrations list 명령 실패의 원인이 됩니다.
메서드에서 다음 1.x 초기화 코드를 Configure Startup.cs고려합니다.
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
SeedData.Initialize(app.ApplicationServices);
2.0 프로젝트에서 호출을 SeedData.Initialize 다음 메서드Program.cs로 Main 이동합니다.
var host = BuildWebHost(args);
using (var scope = host.Services.CreateScope())
{
var services = scope.ServiceProvider;
try
{
// Requires using RazorPagesMovie.Models;
SeedData.Initialize(services);
}
catch (Exception ex)
{
var logger = services.GetRequiredService<ILogger<Program>>();
logger.LogError(ex, "An error occurred seeding the DB.");
}
}
host.Run();
2.0부터 BuildWebHost에서 웹 호스트를 빌드하고 구성하는 작업 외에 다른 작업을 수행하는 것은 바람직하지 않습니다. 애플리케이션 실행과 관련된 모든 작업은 BuildWebHost의 외부(보통 Program.cs의 Main 메서드)에서 처리해야 합니다.
Razor 보기 컴파일 설정 검토
빠른 애플리케이션 시작 시간 및 보다 작은 게시된 번들은 무엇보다도 중요합니다. 이러한 이유로 Razor 보기 컴파일은 ASP.NET Core 2.0에서 기본적으로 활성화됩니다.
MvcRazorCompileOnPublish 속성을 true로 설정하는 것은 더 이상 필요하지 않습니다. 뷰 컴파일을 사용하지 않도록 설정하지 않으면 파일에서 .csproj 속성이 제거될 수 있습니다.
.NET Framework를 대상으로 하는 경우에도 Microsoft.AspNetCore.MvcRazor.를 명시적으로 참조해야 합니다. 파일의 .csproj ViewCompilation NuGet 패키지:
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
Application Insights "강화" 기능 사용
애플리케이션 성능 계측의 손쉬운 설치는 중요합니다. 이제 Visual Studio 2017 도구에서 제공하는 Application Insights "강화" 기능을 사용할 수 있습니다.
Visual Studio 2017에서 만든 ASP.NET Core 1.1 프로젝트는 기본적으로 Application Insights를 추가했습니다. Application Insights SDK를 외부에서 직접 Program.cs Startup.cs사용하지 않는 경우 다음 단계를 수행합니다.
.NET Core를 대상으로 하는 경우 파일에서 다음
<PackageReference />노드를 제거합니다.csproj.<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />.NET Core를 대상으로 하는 경우 다음에서 확장 메서드 호출을
Program.cs제거UseApplicationInsights합니다.public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup<Startup>() .UseApplicationInsights() .Build(); host.Run(); }에서 Application Insights 클라이언트 쪽 API 호출을
_Layout.cshtml제거합니다. 다음 두 코드 줄을 구성합니다.@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet @Html.Raw(JavaScriptSnippet.FullScript)
Application Insights SDK를 직접 사용하는 경우 계속 진행합니다. 2.0 metapackage에는 최신 버전의 Application Insights가 포함되어 있으므로 이전 버전을 참조하는 경우 패키지 다운그레이드 오류가 나타납니다.
인증/Identity 향상 도입
ASP.NET Core 2.0에는 새 인증 모델 및 ASP.NET Core Identity에 대한 몇 가지 주요 변경 사항이 있습니다. 개별 사용자 계정을 활성화하여 프로젝트를 만들거나 인증 또는 Identity를 수동으로 추가한 경우 ASP.NET Core 2.0으로 인증 및 Identity 마이그레이션을 참조하세요.
추가 리소스
ASP.NET Core