.NET Core 3.0의 호환성이 손상되는 변경

  • 아티클

.NET Core, ASP.NET Core, EF Core 버전 3.0으로 마이그레이션하는 경우 이 문서에 나열된 호환성이 손상되는 변경이 앱에 영향을 줄 수 있습니다.

ASP.NET Core

사용되지 않는 위조 방지, CORS, 진단, MVC 및 라우팅 API가 제거됨

ASP.NET Core 2.2에서 사용되지 않는 멤버 및 호환성 스위치가 제거되었습니다.

도입된 버전

3.0

변경 이유

시간에 따른 API 표면 개선.

.NET Core 2.2를 대상으로 하는 동안 사용되지 않는 빌드 메시지의 지침에 따라 새 API를 대신 채택합니다.

범주

ASP.NET Core

영향을 받는 API

다음 형식 및 멤버는 ASP.NET Core 2.1 및 2.2에서 사용되지 않는 것으로 표시되었습니다.

유형

  • Microsoft.AspNetCore.Diagnostics.Views.WelcomePage
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProvider
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinder
  • Microsoft.AspNetCore.Routing.IRouteValuesAddressMetadata
  • Microsoft.AspNetCore.Routing.RouteValuesAddressMetadata

생성자

  • Microsoft.AspNetCore.Cors.Infrastructure.CorsService(IOptions{CorsOptions})
  • Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder(ILoggerFactory,UrlEncoder,ObjectPool{UriBuildingContext},IInlineConstraintResolver)
  • Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider)
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider,IActionResultTypeMapper)
  • Microsoft.AspNetCore.Mvc.Formatters.FormatFilter(IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary`2)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
  • Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

속성

  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
  • Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
  • Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
  • Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

메서드

“Pubternal” API가 제거됨

ASP.NET Core의 공용 API 노출 영역을 보다 효율적으로 유지 관리하기 위해 *.Internal 네임스페이스("pubternal" API라고 함)에 있는 대부분의 형식이 진정한 내부용이 되었습니다. 이러한 네임스페이스의 멤버는 공용 API로 지원되지 않았습니다. 이러한 API는 마이너 릴리스에서 중단 가능성이 있었고 실제로 자주 중단되었습니다. ASP.NET Core 3.0으로 업데이트할 때 이러한 API에 종속된 코드가 중단됩니다.

자세한 내용은 dotnet/aspnetcore#4932 및 dotnet/aspnetcore#11312를 참조하세요.

도입된 버전

3.0

이전 동작

영향을 받는 API가 public 액세스 한정자로 표시되고 *.Internal 네임스페이스에 존재합니다.

새 동작

영향을 받는 API가 internal 액세스 한정자로 표시되며, 해당 어셈블리 외부의 코드에서 이 API를 더 이상 사용할 수 없습니다.

변경 이유

이러한 "pubternal" API에 대한 지침은 다음과 같은 특성이 있었습니다.

  • 예고 없이 변경될 수 있었습니다.
  • 호환성이 손상되는 변경을 방지하기 위해 .NET 정책에 적용되지 않았습니다.

API를 public으로 유지하여(*.Internal 네임스페이스에서도) 고객이 혼동할 수 있었습니다.

이러한 "pubternal" API 사용을 중지합니다. 대체 API에 대한 질문이 있는 경우 dotnet/aspnetcore 리포지토리에서 문제를 여세요.

예를 들어 ASP.NET Core 2.2 프로젝트에서 다음 HTTP 요청 버퍼링 코드가 있습니다. EnableRewind 확장 메서드는 Microsoft.AspNetCore.Http.Internal 네임스페이스에 있습니다.

HttpContext.Request.EnableRewind();

ASP.NET Core 3.0 프로젝트에서 EnableRewind 호출을 EnableBuffering 확장 메서드에 대한 호출로 바꿉니다. 요청 버퍼링 기능은 이전과 동일하게 작동합니다. EnableBuffering은 이제 internal API를 호출합니다.

HttpContext.Request.EnableBuffering();

범주

ASP.NET Core

영향을 받는 API

네임 스페이스 이름에 Internal 세그먼트가 있는 Microsoft.AspNetCore.* 및 Microsoft.Extensions.* 네임스페이스의 모든 API. 예시:

  • Microsoft.AspNetCore.Authentication.Internal
  • Microsoft.AspNetCore.Builder.Internal
  • Microsoft.AspNetCore.DataProtection.Cng.Internal
  • Microsoft.AspNetCore.DataProtection.Internal
  • Microsoft.AspNetCore.Hosting.Internal
  • Microsoft.AspNetCore.Http.Internal
  • Microsoft.AspNetCore.Mvc.Core.Infrastructure
  • Microsoft.AspNetCore.Mvc.Core.Internal
  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal
  • Microsoft.AspNetCore.Rewrite.Internal
  • Microsoft.AspNetCore.Routing.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
  • Microsoft.AspNetCore.Server.Kestrel.Https.Internal

인증: Google+는 사용되지 않고 바뀜

Google은 2019년 1월 28일부터 앱에 대한 Google+ 로그인을 종료하기 시작했습니다.

변경 내용 설명

ASP.NET 4.x 및 ASP.NET Core는 Google+ 로그인 API를 사용하여 웹앱에서 Google 계정 사용자를 인증하고 있습니다. 영향을 받는 NuGet 패키지는 Microsoft.AspNetCore.Authentication.Google이며 ASP.NET Web Forms 및 MVC가 있는 Microsoft.Owin의 경우 Microsoft.Owin.Security.Google입니다.

Google의 대체 API는 다른 데이터 원본 및 형식을 사용합니다. 아래에 제공된 완화 및 솔루션은 구조적 변경을 제공합니다. 앱은 데이터 자체가 여전히 요구 사항을 충족하는지 확인해야 합니다. 예를 들어 이름, 이메일 주소, 프로필 링크 및 프로필 사진은 이전과는 약간 다른 값을 제공할 수 있습니다.

도입된 버전

모든 버전. 이 변경 내용은 ASP.NET Core 외부에 있습니다.

ASP.NET Web Forms 및 MVC를 사용한 Owin

Microsoft.Owin 3.1.0 이상의 경우 임시 완화가 여기에 간략하게 설명되어 있습니다. 앱은 데이터 형식의 변경 내용을 확인하기 위해 완화를 사용하여 테스트를 완료해야 합니다. 수정 내용이 있는 Microsoft.Owin 4.0.1을 릴리스할 계획이 있습니다. 이전 버전을 사용하는 앱은 버전 4.0.1로 업데이트해야 합니다.

ASP.NET Core 1.x

ASP.NET Web Forms 및 MVC를 사용한 Owin의 완화를 ASP.NET Core 1.x에 맞게 조정할 수 있습니다. 1.x가 수명 종료 상태에 도달했기 때문에 NuGet 패키지 패치가 계획되지 않았습니다.

ASP.NET Core 2.x

Microsoft.AspNetCore.Authentication.Google 버전 2.x의 경우 Startup.ConfigureServices의 AddGoogle에 대한 기존 호출을 다음 코드로 바꿉니다.

.AddGoogle(o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo";
    o.ClaimActions.Clear();
    o.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");
    o.ClaimActions.MapJsonKey(ClaimTypes.Name, "name");
    o.ClaimActions.MapJsonKey(ClaimTypes.GivenName, "given_name");
    o.ClaimActions.MapJsonKey(ClaimTypes.Surname, "family_name");
    o.ClaimActions.MapJsonKey("urn:google:profile", "link");
    o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");
});

2월 2.1 및 2.2 패치는 이전의 재구성을 새 기본값으로 통합했습니다. 수명 종료에 도달했기 때문에 ASP.NET Core 2.0의 패치가 계획되지 않았습니다.

ASP.NET Core 3.0

ASP.NET Core 2.x에 제공된 완화는 ASP.NET Core 3.0에도 사용할 수 있습니다. 향후 3.0 미리 보기에서 Microsoft.AspNetCore.Authentication.Google 패키지가 제거될 수 있습니다. 사용자는 대신 Microsoft.AspNetCore.Authentication.OpenIdConnect로 이동해야 합니다. 다음 코드는 Startup.ConfigureServices에서 AddGoogle을 AddOpenIdConnect로 바꾸는 방법을 보여줍니다. 이 대체 항목은 ASP.NET Core 2.0 이상에서 사용할 수 있으며, 필요에 따라 ASP.NET Core 1.x에 맞게 조정할 수 있습니다.

.AddOpenIdConnect("Google", o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.Authority = "https://accounts.google.com";
    o.ResponseType = OpenIdConnectResponseType.Code;
    o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
    o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Authentication.Google

인증: HttpContext.Authentication 속성이 제거됨

HttpContext에서 사용되지 않는 Authentication 속성이 제거되었습니다.

변경 내용 설명

dotnet/aspnetcore#6504의 일부로, HttpContext에서 사용되지 않는 Authentication 속성이 제거되었습니다. Authentication 속성은 2.0 이후 더 이상 사용되지 않습니다. 사용되지 않는 이 속성을 사용하여 코드를 새 대체 API로 마이그레이션하기 위해 마이그레이션 가이드가 게시되었습니다. 이전 ASP.NET Core 1.x 인증 스택과 관련된 나머지 사용되지 않는 클래스/API는 커밋 dotnet/aspnetcore@d7a7c65에서 제거되었습니다.

토론은 dotnet/aspnetcore#6533을 참조하세요.

도입된 버전

3.0

변경 이유

ASP.NET Core 1.0 API는 Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions의 확장 메서드로 대체되었습니다.

마이그레이션 가이드를 참조하세요.

범주

ASP.NET Core

영향을 받는 API

인증: Newtonsoft.Json 형식이 바뀜

ASP.NET Core 3.0에서는 인증 API에 사용된 Newtonsoft.Json 형식이 System.Text.Json 형식으로 대체되었습니다. 다음 경우를 제외하고 인증 패키지의 기본 사용량은 영향을 받지 않습니다.

  • OAuth 공급자에서 파생된 클래스(예: aspnet-contribaspnet의 클래스)입니다.
  • 고급 클레임 조작 구현.

자세한 내용은 dotnet/aspnetcore#7105를 참조하세요. 토론은 dotnet/aspnetcore#7289를 참조하세요.

도입된 버전

3.0

파생 OAuth 구현의 경우 가장 일반적인 변경 내용은 여기에 표시된 것처럼 CreateTicketAsync 재정의에서 JObject.Parse를 JsonDocument.Parse로 바꾸는 것입니다. JsonDocument는 IDisposable를 구현합니다.

다음 목록에서는 알려진 변경 내용을 간략하게 설명합니다.

범주

ASP.NET Core

영향을 받는 API

인증: OAuthHandler ExchangeCodeAsync 서명이 변경됨

ASP.NET Core 3.0에서 OAuthHandler.ExchangeCodeAsync의 서명이 다음에서 변경되었습니다.

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }

다음으로 변경:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }

도입된 버전

3.0

이전 동작

code 및 redirectUri 문자열은 별도의 인수로 전달되었습니다.

새 동작

Code 및 RedirectUri는 OAuthCodeExchangeContext 생성자를 통해 설정할 수 있는 OAuthCodeExchangeContext의 속성입니다. 새 OAuthCodeExchangeContext 형식은 OAuthHandler.ExchangeCodeAsync에 전달된 유일한 인수입니다.

변경 이유

이러한 변경으로 인해 추가 매개 변수가 중단되지 않은 방식으로 제공될 수 있습니다. 새 ExchangeCodeAsync 오버로드를 만들 필요가 없습니다.

적절한 code 및 redirectUri 값을 사용하여 OAuthCodeExchangeContext를 구성합니다. AuthenticationProperties 인스턴스를 제공해야 합니다. 이 단일 OAuthCodeExchangeContext 인스턴스는 여러 인수 대신 OAuthHandler.ExchangeCodeAsync에 전달할 수 있습니다.

범주

ASP.NET Core

영향을 받는 API

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

권한 부여: AddAuthorization 오버로드가 다른 어셈블리로 이동됨

Microsoft.AspNetCore.Authorization에 상주하는 데 사용되는 핵심 AddAuthorization 메서드가 AddAuthorizationCore로 이름이 변경되었습니다. 이전 AddAuthorization 메서드는 여전히 존재하지만, 대신 Microsoft.AspNetCore.Authorization.Policy 어셈블리에 있습니다. 두 방법을 모두 사용하는 앱은 영향을 받지 않아야 합니다. Microsoft.AspNetCore.Authorization.Policy는 이제 공유 프레임워크: Microsoft.AspNetCore.App에서 제거된 어셈블리에 설명된 대로 독립 실행형 패키지가 아닌 공유 프레임워크로 제공됩니다.

도입된 버전

3.0

이전 동작

AddAuthorization 메서드가 Microsoft.AspNetCore.Authorization에 있었습니다.

새 동작

AddAuthorization 메서드가 Microsoft.AspNetCore.Authorization.Policy에 있습니다. AddAuthorizationCore는 이전 메서드의 새 이름입니다.

변경 이유

AddAuthorization는 권한 부여에 필요한 모든 일반 서비스를 추가하는 데 더 나은 메서드 이름입니다.

Microsoft.AspNetCore.Authorization.Policy에 대한 참조를 추가하거나 대신 AddAuthorizationCore를 사용합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection, Action<AuthorizationOptions>)

권한 부여: AuthorizationFilterContext.Filters에서 IAllowAnonymous가 제거됨

ASP.NET Core 3.0을 기준으로 MVC에서 컨트롤러 및 작업 메서드에서 검색된 [AllowAnonymous] 특성에 대해 AllowAnonymousFilters를 추가하지 않습니다. 이 변경 사항은 AuthorizeAttribute의 파생에 대해 로컬로 처리하지만 IAsyncAuthorizationFilter 및 IAuthorizationFilter 구현에 대해 호환성이 손상됩니다. [TypeFilter] 특성에 래핑된 이러한 구현은 구성 및 종속성 주입이 모두 필요한 경우 강력한 형식의 특성 기반 권한 부여를 달성하는 일반적이고 지원되는 방식입니다.

도입된 버전

3.0

이전 동작

IAllowAnonymous가 AuthorizationFilterContext.Filters 컬렉션에 표시되었습니다. 인터페이스의 현재 상태에 대한 테스트는 개별 컨트롤러 메서드에서 필터를 재정의하거나 사용하지 않도록 설정하는 유효한 방법이었습니다.

새 동작

AuthorizationFilterContext.Filters 컬렉션에 IAllowAnonymous가 더 이상 표시되지 않습니다. 이전 동작에 의존하는 IAsyncAuthorizationFilter 구현은 일반적으로 일시적인 HTTP 401 Unauthorized 또는 HTTP 403 Forbidden 응답의 원인이 됩니다.

변경 이유

새 엔드포인트 라우팅 전략은 ASP.NET Core 3.0에서 도입되었습니다.

IAllowAnonymous에 대한 엔드포인트 메타데이터를 검색합니다. 예시:

var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}

이 기법에 대한 예는 HasAllowAnonymous 메서드에 표시됩니다.

범주

ASP.NET Core

영향을 받는 API

없음

권한 부여: IAuthorizationPolicyProvider 구현에는 새로운 메서드가 필요함

ASP.NET Core 3.0에서는 새 GetFallbackPolicyAsync 메서드가 IAuthorizationPolicyProvider에 추가되었습니다. 이 대체 정책은 정책이 지정되지 않은 경우 권한 부여 미들웨어에서 사용됩니다.

자세한 내용은 dotnet/aspnetcore#9759를 참조하세요.

도입된 버전

3.0

이전 동작

IAuthorizationPolicyProvider의 구현에는 GetFallbackPolicyAsync 메서드가 필요하지 않습니다.

새 동작

IAuthorizationPolicyProvider의 구현에는 GetFallbackPolicyAsync 메서드가 필요합니다.

변경 이유

정책이 지정되지 않은 경우 새 AuthorizationMiddleware를 사용할 수 있는 새로운 메서드가 필요했습니다.

IAuthorizationPolicyProvider의 구현에 GetFallbackPolicyAsync 메서드를 추가합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

캐싱: CompactOnMemoryPressure 속성이 제거됨

ASP.NET Core 3.0 릴리스에서는 사용되지 않는 MemoryCacheOptions API를 제거했습니다.

변경 내용 설명

이 변경 내용은 aspnet/Caching#221에 대한 후속 작업입니다. 자세한 내용은 dotnet/extensions#1062를 참조하세요.

도입된 버전

3.0

이전 동작

MemoryCacheOptions.CompactOnMemoryPressure 속성을 사용할 수 있었습니다.

새 동작

MemoryCacheOptions.CompactOnMemoryPressure 속성이 제거되었습니다.

변경 이유

자동으로 캐시를 압축하면 문제가 발생합니다. 예기치 않은 동작을 방지하려면 필요한 경우에만 캐시를 압축해야 합니다.

캐시를 압축하려면 MemoryCache를 다운캐스트하고 필요한 경우 Compact를 호출합니다.

범주

ASP.NET Core

영향을 받는 API

MemoryCacheOptions.CompactOnMemoryPressure

캐싱: Microsoft.Extensions.Caching.SqlServer가 새로운 SqlClient 패키지를 사용함

Microsoft.Extensions.Caching.SqlServer 패키지는 System.Data.SqlClient 패키지 대신 새 Microsoft.Data.SqlClient 패키지를 사용합니다. 이 변경으로 인해 약간의 동작이 크게 변경될 수 있습니다. 자세한 내용은 새 Microsoft.Data.SqlClient 소개를 참조하세요.

도입된 버전

3.0

이전 동작

Microsoft.Extensions.Caching.SqlServer 패키지는 System.Data.SqlClient 패키지를 사용했습니다.

새 동작

Microsoft.Extensions.Caching.SqlServer가 현재 Microsoft.Data.SqlClient 패키지를 사용하고 있습니다.

변경 이유

Microsoft.Data.SqlClient는 System.Data.SqlClient에서 빌드된 새 패키지입니다. 이제부터 모든 새 기능 작업이 수행됩니다.

고객은 Microsoft.Extensions.Caching.SqlServer 패키지에서 반환된 형식을 사용하고 System.Data.SqlClient 형식으로 캐스팅하지 않는 한 이러한 호환성이 손상되는 변경에 대해 걱정할 필요가 없습니다. 예를 들어 다른 사용자가 DbConnection을 이전 SqlConnection 형식으로 캐스팅하는 경우 캐스팅을 새 Microsoft.Data.SqlClient.SqlConnection 형식으로 변경해야 합니다.

범주

ASP.NET Core

영향을 받는 API

없음

캐싱: ResponseCaching "pubternal" 형식이 내부로 변경됨

ASP.NET Core 3.0에서는 ResponseCaching의 "pubternal" 유형이 internal로 변경되었습니다.

또한 IResponseCachingPolicyProvider 및 IResponseCachingKeyProvider의 기본 구현은 더 이상 AddResponseCaching 메서드의 일부로 서비스에 추가되지 않습니다.

변경 내용 설명

ASP.NET Core에서 "pubternal" 유형은 public으로 선언되지만 .Internal로 접미사가 지정된 네임스페이스에 있습니다. 이러한 형식은 공용이지만 지원 정책이 없으며 호환성이 손상되는 변경이 적용됩니다. 아쉽게도 이러한 형식의 우발적 사용이 일반적으로 발생하므로 이러한 프로젝트에 대한 호환성이 손상되는 변경이 발생하고 프레임워크를 유지 관리하는 기능이 제한됩니다.

도입된 버전

3.0

이전 동작

이러한 형식은 공개적으로 표시되지만 지원되지는 않습니다.

새 동작

이러한 유형은 이제는 internal입니다.

변경 이유

internal 범위는 지원되지 않는 정책을 더 잘 반영합니다.

앱 또는 라이브러리에서 사용하는 형식을 복사합니다.

범주

ASP.NET Core

영향을 받는 API

데이터 보호: DataProtection.Blobs가 새로운 Azure Storage API를 사용함

Azure.Extensions.AspNetCore.DataProtection.Blobs은 Azure Storage 라이브러리에 따라 달라집니다. 이러한 라이브러리는 해당 어셈블리, 패키지 및 네임 스페이스의 이름을 바꿨습니다. ASP.NET Core 3.0부터 Azure.Extensions.AspNetCore.DataProtection.Blobs는 새 Azure.Storage. 접두사가 지정된 API 및 패키지를 사용합니다.

Azure Storage API에 대한 질문은 https://github.com/Azure/azure-storage-net을 사용하세요. 이 문제에 대한 자세한 내용은 dotnet/aspnetcore#19570을 참조하세요.

도입된 버전

3.0

이전 동작

패키지는 WindowsAzure.Storage NuGet 패키지를 참조했습니다. 패키지는 Microsoft.Azure.Storage.Blob NuGet 패키지를 참조합니다.

새 동작

패키지는 Azure.Storage.Blob NuGet 패키지를 참조합니다.

변경 이유

이 변경으로 인해 Azure.Extensions.AspNetCore.DataProtection.Blobs는 권장 Azure Storage 패키지로 마이그레이션할 수 있습니다.

ASP.NET Core 3.0과 함께 이전 Azure Storage API를 계속 사용해야 하는 경우 WindowsAzure.Storage 또는 Microsoft.Azure.Storage 패키지에 직접 종속성을 추가합니다. 이 패키지는 새 Azure.Storage API와 함께 설치할 수 있습니다.

대부분의 경우 업그레이드는 새 네임스페이스를 사용하도록 using 문만 변경하면 됩니다.

- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;

범주

ASP.NET Core

영향을 받는 API

없음

호스팅: AspNetCoreModule V1이 Windows 호스팅 번들에서 제거됨

ASP.NET Core 3.0부터 Windows Hosting Bundle에는 ANCM(AspNetCoreModule) V1이 포함되어 있지 않습니다.

ANCM V2는 ANCM OutOfProcess와 역호환되며 ASP.NET Core 3.0 앱에서 사용하는 것이 좋습니다.

토론은 dotnet/aspnetcore#7095를 참조하세요.

도입된 버전

3.0

이전 동작

ANCM V1은 Windows Hosting Bundle에 포함되어 있습니다.

새 동작

ANCM V1은 Windows Hosting Bundle에 포함되어 있지 않습니다.

변경 이유

ANCM V2는 ANCM OutOfProcess와 역호환되며 ASP.NET Core 3.0 앱에서 사용하는 것이 좋습니다.

ASP.NET Core 3.0 앱에서 ANCM V2를 사용합니다.

ANCM V1이 필요한 경우 ASP.NET Core 2.1 또는 2.2 Windows Hosting Bundle을 사용하여 설치할 수 있습니다.

이 변경으로 인해 다음과 같은 ASP.NET Core 3.0 앱이 중단됩니다.

  • <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>에서 ANCM V1을 사용하도록 명시적으로 선택했습니다.
  • <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />를 사용하여 사용자 지정 web .config 파일을 만듭니다.

범주

ASP.NET Core

영향을 받는 API

없음

호스팅: 제네릭 호스트가 시작 생성자 주입을 제한함

제네릭 호스트가 Startup 클래스 생성자 주입을 지원하는 형식은 IHostEnvironment, IWebHostEnvironment 및 IConfiguration뿐입니다. WebHost를 사용하는 앱은 영향을 받지 않습니다.

변경 내용 설명

ASP.NET Core 3.0 이전에는 Startup 클래스의 생성자에 있는 임의 형식에 생성자 주입을 사용할 수 있습니다. ASP.NET Core 3.0에서는 웹 스택이 제네릭 호스트 라이브러리로 다시 플랫폼화되었습니다. 템플릿의 Program.cs 파일에서 변경 내용을 확인할 수 있습니다.

ASP.NET Core 2.x:

https://github.com/dotnet/aspnetcore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L20-L22

ASP.NET Core 3.0:

https://github.com/dotnet/aspnetcore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L19-L24

Host는 하나의 DI(종속성 주입) 컨테이너를 사용하여 앱을 빌드합니다. WebHost는 두 개의 컨테이너(호스트용과 앱용)를 사용합니다. 따라서 Startup 생성자는 더 이상 사용자 지정 서비스 주입을 지원하지 않습니다. IHostEnvironment, IWebHostEnvironment 및 IConfiguration만 주입할 수 있습니다. 이 변경으로 인해 싱글톤 서비스의 중복 만들기와 같은 DI 문제가 방지됩니다.

도입된 버전

3.0

변경 이유

이 변경 내용은 웹 스택을 제네릭 호스트 라이브러리로 다시 플랫폼화한 결과입니다.

Startup.Configure 메서드 서명에 서비스를 주입합니다. 예시:

public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)

범주

ASP.NET Core

영향을 받는 API

없음

호스팅: IIS Out-of-Process 앱에 대해 HTTPS 리디렉션이 사용하도록 설정됨

IIS Out of Process를 통해 호스팅하기 위한 ASP.NET Core 모듈(ANCM)의 버전 13.0.19218.0은 ASP.NET Core 3.0 및 2.2 앱에 대한 기존 HTTPS 리디렉션 기능을 사용하도록 설정합니다.

토론은 dotnet/AspNetCore#15243을 참조하세요.

도입된 버전

3.0

이전 동작

ASP.NET Core 2.1 프로젝트 템플릿은 먼저 UseHttpsRedirection 및 UseHsts와 같은 HTTPS 미들웨어 메서드에 대한 지원을 도입했습니다. 개발 중인 앱은 기본 포트 443을 사용하지 않으므로 HTTPS 리디렉션을 사용하도록 설정하려면 구성을 추가해야 합니다. HSTS(HTTP Strict Transport Security)는 요청이 HTTPS를 이미 사용하고 있을 경우에만 활성화됩니다. localhost는 기본적으로 생략됩니다.

새 동작

ASP.NET Core 3.0에서 IIS HTTPS 시나리오는 향상되었습니다. 향상된 기능을 사용하면 앱이 서버의 HTTPS 포트를 검색하고 기본적으로 UseHttpsRedirection 작업을 수행할 수 있습니다. In Process 구성 요소는 IServerAddresses 기능을 사용하여 포트 검색을 완료했습니다. In Process 라이브러리가 프레임워크를 통해 버전이 지정되었기 때문에 이 기능은 ASP.NET Core 3.0 앱에만 영향을 줍니다. ASPNETCORE_HTTPS_PORT 환경 변수를 자동으로 추가하도록 Out of Process 구성 요소가 변경되었습니다. Out of Process 구성 요소가 전역적으로 공유되기 때문에 이 변경은 ASP.NET Core 2.2 및 3.0 앱 모두에 영향을 미쳤습니다. ASP.NET Core 2.1 앱은 기본적으로 이전 버전의 버전을 ANCM을 사용하므로 영향을 받지 않습니다.

ASP.NET Core 3.0.1과 3.1.0 Preview 3에서 이전 동작을 수정하여 ASP.NET Core 2.x의 동작 변경을 되돌립니다. 해당 변경 내용은 IIS Out of Process 앱에만 영향을 줍니다.

위에서 설명한 대로 ASP.NET Core 3.0.0을 설치하면 ASP.NET Core 2.x 앱에서 UseHttpsRedirection 미들웨어도 활성화되는 부작용이 있었습니다. ASP.NET Core 3.0.1 및 3.1.0 Preview 3을 설치해도 ASP.NET Core 2.x 앱에 더 이상 영향을 주지 않도록 변경되었습니다. ASP.NET Corea 3.0.0에서 ANCM이 채운 ASPNETCORE_HTTPS_PORT 환경 변수가 ASP.NET Core 3.0.1 및 3.1.0 Preview 3의 ASPNETCORE_ANCM_HTTPS_PORT로 변경되었습니다. UseHttpsRedirection는 새로운 변수와 이전 변수를 모두 이해하기 위해 이 릴리스에서도 업데이트되었습니다. ASP.NET Core 2.x는 업데이트되지 않습니다. 그 결과, 기본적으로 사용하지 않도록 설정된 이전 동작으로 돌아갑니다.

변경 이유

ASP.NET Core 3.0 기능이 향상되었습니다.

모든 클라이언트가 HTTPS를 사용하도록 하려면 작업이 필요 없습니다. 일부 클라이언트가 HTTPS를 사용하도록 허용하려면 다음 단계 중 하나를 수행합니다.

  • 프로젝트의 Startup.Configure 메서드에서 UseHttpsRedirection 및 UseHsts에 대한 호출을 제거하고 앱을 다시 배포하세요.

  • web.config 파일에서 ASPNETCORE_HTTPS_PORT 환경 변수를 빈 문자열로 설정하세요. 변경은 앱을 다시 배포하지 않고 서버에서 직접 발생할 수 있습니다. 예시:

    <aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >
    <environmentVariables>
    <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
    </environmentVariables>
</aspNetCore>

UseHttpsRedirection은 여전히 다음이 될 수 있습니다.

  • ASPNETCORE_HTTPS_PORT 환경 변수를 적절한 포트 번호(대부분의 프로덕션 시나리오에서 443)로 설정하여 ASP.NET Core 2.x에서 수동으로 활성화했습니다.
  • 빈 문자열 값으로 ASPNETCORE_ANCM_HTTPS_PORT를 정의하여 ASP.NET Core 3.x에서 비활성화했습니다. 이 값은 앞의 ASPNETCORE_HTTPS_PORT 예제와 동일한 방식으로 설정됩니다.

ASP.NET Core 3.0.0 앱을 실행하는 컴퓨터는 ASP.NET Core 3.1.0 Preview 3 ANCM을 설치하기 전에 ASP.NET Core 3.0.1 런타임을 설치해야 합니다. 이렇게 하면 UseHttpsRedirection이 ASP.NET Core 3.0 앱에 대해 예상대로 작동합니다.

Azure App Service에서는 ANCM이 전역 특성 때문에 런타임과 별도의 일정으로 배포됩니다. ANCM은 ASP.NET Core 3.0.1 및 3.1.0가 배포된 후 해당 변경과 함께 Azure에 배포되었습니다.

범주

ASP.NET Core

영향을 받는 API

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

호스팅: IHostingEnvironment 및 IApplicationLifetime 형식이 사용되지 않음으로 표시되고 바뀜

기존 IHostingEnvironment 및 IApplicationLifetime 형식을 대체하기 위해 새로운 형식이 도입되었습니다.

도입된 버전

3.0

이전 동작

Microsoft.Extensions.Hosting 및 Microsoft.AspNetCore.Hosting과는 다른 두 가지(IHostingEnvironment 및 IApplicationLifetime) 형식이 있습니다.

새 동작

이전 형식은 사용되지 않음으로 표시되었으며 새 형식으로 대체되었습니다.

변경 이유

ASP.NET Core 2.1에 Microsoft.Extensions.Hosting이 도입되었을 때 IHostingEnvironment 및 IApplicationLifetime과 같은 일부 형식이 Microsoft.AspNetCore.Hosting에서 복사되었습니다. 일부 ASP.NET Core 3.0 변경으로 인해 앱에 Microsoft.Extensions.Hosting 및 Microsoft.AspNetCore.Hosting 네임스페이스가 모두 포함됩니다. 이러한 중복 형식을 사용하면 네임스페이스가 모두 참조될 때 "모호한 참조" 컴파일러 오류가 발생합니다.

이전 형식의 사용을 다음과 같이 새로 도입된 형식으로 대체했습니다.

사용되지 않는 형식(경고):

새 형식:

새 IHostEnvironmentIsDevelopment 및 IsProduction 확장 메서드는 Microsoft.Extensions.Hosting 네임스페이스에 있습니다. 해당 네임스페이스를 프로젝트에 추가해야 할 수도 있습니다.

범주

ASP.NET Core

영향을 받는 API

호스팅: WebHostBuilder 종속성에서 ObjectPoolProvider가 제거됨

ASP.NET Core가 재생에 대해 추가 비용을 지불하도록 하는 과정에서 ObjectPoolProvider가 기본 종속성 세트에서 제거되었습니다. ObjectPoolProvider에 의존하는 특정 구성 요소가 이제 해당 구성 요소를 추가합니다.

토론은 dotnet/aspnetcore#5944를 참조하세요.

도입된 버전

3.0

이전 동작

WebHostBuilder에서는 기본적으로 DI 컨테이너에 ObjectPoolProvider를 제공합니다.

새 동작

WebHostBuilder에서는 더 이상 기본적으로 DI 컨테이너에 ObjectPoolProvider를 제공하지 않습니다.

변경 이유

이러한 변경으로 인해 ASP.NET Core가 더 많은 비용을 지불하게 되었습니다.

구성 요소에 ObjectPoolProvider가 필요한 경우 IServiceCollection을 통해 종속성에 추가해야 합니다.

범주

ASP.NET Core

영향을 받는 API

없음

HTTP: DefaultHttpContext 확장성이 제거됨

ASP.NET Core 3.0 성능 향상의 일환으로 DefaultHttpContext의 확장성이 제거되었습니다. 클래스는 이제 sealed입니다. 자세한 내용은 dotnet/aspnetcore#6504를 참조하세요.

단위 테스트에 Mock<DefaultHttpContext>가 사용되는 경우에는 대신 Mock<HttpContext> 또는 new DefaultHttpContext()를 사용합니다.

토론은 dotnet/aspnetcore#6534를 참조하세요.

도입된 버전

3.0

이전 동작

클래스는 DefaultHttpContext에서 파생될 수 있습니다.

새 동작

클래스는 DefaultHttpContext에서 파생될 수 없습니다.

변경 이유

확장성은 처음에는 HttpContext의 풀링을 허용하기 위해 제공되었지만 불필요 한 복잡성을 야기하고 기타 최적화를 방해했습니다.

단위 테스트에서 Mock<DefaultHttpContext>를 사용하는 경우, 대신 Mock<HttpContext>를 사용합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames 상수가 정적 읽기 전용으로 변경됨

ASP.NET Core 3.0 Preview 5부터 Microsoft.Net.Http.Headers.HeaderNames의 필드가 const에서 static readonly로 변경되었습니다.

토론은 dotnet/aspnetcore#9514를 참조하세요.

도입된 버전

3.0

이전 동작

이러한 필드는 const가 되는 데 사용됩니다.

새 동작

이러한 필드는 이제 static readonly입니다.

변경 이유

변경 내용:

  • 값이 어셈블리 경계를 넘어 포함되지 않도록 하여 필요에 따라 값을 수정할 수 있도록 합니다.
  • 참조 같음 검사를 더 빠르게 수행할 수 있습니다.

3.0에 대해 다시 컴파일합니다. 다음 방법으로 이러한 필드를 사용하는 소스 코드는 더 이상 이렇게 할 수 없습니다.

  • 특성 인수로 사용
  • switch 문의 case로 사용
  • 다른 const를 정의하는 경우

호환성이 손상되는 변경을 해결하려면 자체 정의된 헤더 이름 상수 또는 문자열 리터럴을 사용하도록 전환합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.Net.Http.Headers.HeaderNames

HTTP: 응답 본문 인프라 변경

HTTP 응답 본문을 지원하는 인프라가 변경되었습니다. HttpResponse를 직접 사용하는 경우 코드를 변경할 필요가 없습니다. HttpResponse.Body를 래핑 또는 대체하거나 HttpContext.Features에 액세스하는 경우 자세히 읽어보세요.

도입된 버전

3.0

이전 동작

HTTP 응답 본문과 관련된 세 가지 API가 있습니다.

  • IHttpResponseFeature.Body
  • IHttpSendFileFeature.SendFileAsync
  • IHttpBufferingFeature.DisableResponseBuffering

새 동작

HttpResponse.Body를 바꾸면 StreamResponseBodyFeature를 사용하여 전체 IHttpResponseBodyFeature를 지정된 스트림 주변의 래퍼로 대체하여 모든 예상 API에 대한 기본 구현을 제공합니다. 원래 스트림으로 다시 설정하면 이 변경 내용이 되돌려집니다.

변경 이유

응답 본문 API를 새로운 단일 기능 인터페이스로 결합하는 것이 좋습니다.

이전에 IHttpResponseFeature.Body, IHttpSendFileFeature 또는 IHttpBufferingFeature를 사용했던 IHttpResponseBodyFeature를 사용합니다.

범주

ASP.NET Core

영향을 받는 API

SameSite은(는) 일부 CSRF(교차 사이트 요청 위조) 공격을 완화하는 데 도움이 되는 쿠키의 옵션입니다. 처음에 이 옵션을 도입했을 때 다양한 ASP.NET Core API에서 일관되지 않은 기본값이 사용되었습니다. 이와 같은 불일치로 혼란스러운 결과가 발생했습니다. ASP.NET Core 3.0부터, 이 기본값은 효율적으로 정렬되었습니다. 구성 요소별로 이 기능을 설정해야 합니다.

도입된 버전

3.0

이전 동작

유사한 ASP.NET Core API에서 다른 기본 SameSiteMode 값을 사용했습니다. 불일치에 대한 예는 기본값인 SameSiteMode.None 및 SameSiteMode.Lax(으)로 각각 설정된 HttpResponse.Cookies.Append(String, String) 및 HttpResponse.Cookies.Append(String, String, CookieOptions)에서 볼 수 있습니다.

새 동작

영향을 받는 모든 API의 기본값은 SameSiteMode.None입니다.

변경 이유

SameSite을(를) 옵트인 기능으로 설정하도록 기본값이 변경되었습니다.

쿠키를 내보내는 각 구성 요소는 SameSite이(가) 시나리오에 적합한지 여부를 결정해야 합니다. 영향을 받는 API의 사용을 검토하고 필요에 따라 SameSite을(를) 다시 구성합니다.

범주

ASP.NET Core

영향을 받는 API

HTTP: 모든 서버에서 동기 IO가 사용하지 않도록 설정됨

ASP.NET Core 3.0부터 동기 서버 작업은 기본적으로 비활성화되어 있습니다.

변경 내용 설명

AllowSynchronousIO는 HttpRequest.Body.Read, HttpResponse.Body.Write 및 Stream.Flush와 같은 동기 IO API를 사용하거나 사용하지 않도록 설정하는 각 서버의 옵션입니다. 이러한 API는 오랫동안 스레드 고갈과 앱 중지의 원인이었습니다. ASP.NET Core 3.0 미리 보기 3부터 이러한 동기 작업은 기본적으로 비활성화되어 있습니다.

영향을 받는 서버:

  • Kestrel
  • HttpSys
  • IIS In-Process
  • TestServer

다음과 유사한 오류가 예상됩니다.

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

각 서버에는 이 동작을 제어하는 AllowSynchronousIO 옵션이 있으며 모든 항목에 대한 기본값은 이제 false입니다.

이 동작은 요청에 따라 임시 완화로 재정의할 수도 있습니다. 예시:

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

TextWriter 또는 Dispose에서 동기 API를 호출하는 다른 스트림에 문제가 있는 경우 대신 새 DisposeAsync API를 호출합니다.

토론은 dotnet/aspnetcore#7644를 참조하세요.

도입된 버전

3.0

이전 동작

기본적으로 HttpRequest.Body.Read, HttpResponse.Body.Write 및 Stream.Flush가 허용됩니다.

새 동작

이러한 동기 API는 기본적으로 허용되지 않습니다.

다음과 유사한 오류가 예상됩니다.

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

변경 이유

이러한 동기 API는 오랫동안 스레드 고갈과 앱 중지의 원인이었습니다. ASP.NET Core 3.0 미리 보기 3부터 동기 작업은 기본적으로 비활성화되어 있습니다.

비동기 버전의 메서드를 사용합니다. 이 동작은 요청에 따라 임시 완화로 재정의할 수도 있습니다.

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

범주

ASP.NET Core

영향을 받는 API

ID: AddDefaultUI 메서드 오버로드가 제거됨

ASP.NET Core 3.0부터는 IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) 메서드 오버로드가 더 이상 존재하지 않습니다.

도입된 버전

3.0

변경 이유

이 변경 내용은 정적 웹 자산 기능을 채택한 결과입니다.

두 개의 인수를 사용하는 오버로드 대신 IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder)를 호출합니다. 부트스트랩 3을 사용하는 경우 프로젝트 파일의 <PropertyGroup> 요소에 다음 줄을 추가합니다.

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

범주

ASP.NET Core

영향을 받는 API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

ID: UI의 기본 부트스트랩 버전이 변경됨

ASP.NET Core 3.0부터 ID UI는 기본적으로 부트스트랩 버전 4를 사용합니다.

도입된 버전

3.0

이전 동작

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); 메서드 호출은 services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);와 동일했습니다.

새 동작

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); 메서드 호출은 services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);와 동일합니다.

변경 이유

부트스트랩 4는 ASP.NET Core 3.0 기간 동안 릴리스되었습니다.

기본 ID UI를 사용하고 다음 예제와 같이 Startup.ConfigureServices에 추가한 경우 이 변경 내용의 영향을 받게 됩니다.

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();

다음 작업 중 하나를 수행합니다.

  • 마이그레이션 가이드를 사용하여 부트스트랩 4를 사용하도록 앱을 마이그레이션합니다.

  • 부트스트랩 3의 사용을 적용하도록 Startup.ConfigureServices를 업데이트합니다. 예시:

    services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

범주

ASP.NET Core

영향을 받는 API

없음

ID: 인증되지 않은 ID에 대해 SignInAsync에서 예외가 throw됨

기본적으로 SignInAsync는 IsAuthenticated가 false인 보안 주체/ID에 대해 예외를 throw합니다.

도입된 버전

3.0

이전 동작

SignInAsync는 IsAuthenticated가 false인 ID를 포함하여 모든 보안 주체/ID를 허용합니다.

새 동작

기본적으로 SignInAsync는 IsAuthenticated가 false인 보안 주체/ID에 대해 예외를 throw합니다. 이 동작을 표시하지 않는 새로운 플래그가 있지만 기본 동작이 변경되었습니다.

변경 이유

기본적으로 이러한 보안 주체는 [Authorize] / RequireAuthenticatedUser()에 의해 거부되었기 때문에 이전 동작은 문제가 있었습니다.

ASP.NET Core 3.0 Preview 6에서는 기본적으로 true인 AuthenticationOptions에 RequireAuthenticatedSignIn 플래그가 있습니다. 이전 동작을 복원하려면 이 플래그를 false로 설정합니다.

범주

ASP.NET Core

영향을 받는 API

없음

ID: SignInManager 생성자가 새 매개 변수를 허용함

ASP.NET Core 3.0부터 새 IUserConfirmation<TUser> 매개 변수가 SignInManager 생성자에 추가되었습니다. 자세한 내용은 dotnet/aspnetcore#8356을 참조하세요.

도입된 버전

3.0

변경 이유

변경에 대한 동기는 ID에 새 이메일/확인 흐름에 대한 지원을 추가하는 것이었습니다.

SignInManager를 수동으로 구성하는 경우 IUserConfirmation의 구현을 제공하거나 종속성 주입에서 하나를 가져와 제공합니다.

범주

ASP.NET Core

영향을 받는 API

SignInManager<TUser>

ID: UI가 정적 웹 자산 기능을 사용함

ASP.NET Core 3.0에는 정적 웹 자산 기능이 도입되었으며 ID UI에서 이를 채택했습니다.

변경 내용 설명

ID UI가 정적 웹 자산 기능을 채택한 결과는 다음과 같습니다.

  • 프레임워크 선택은 프로젝트 파일에서 IdentityUIFrameworkVersion 속성을 사용하여 수행됩니다.
  • 부트스트랩 4는 ID UI의 기본 UI 프레임워크입니다. 부트스트랩 3은 수명이 다되었으므로 지원되는 버전으로 마이그레이션하는 것을 고려해야 합니다.

도입된 버전

3.0

이전 동작

ID UI의 기본 UI 프레임워크는 부트스트랩 3입니다. Startup.ConfigureServices에서 AddDefaultUI 메서드 호출에 대한 매개 변수를 사용하여 UI 프레임워크를 구성할 수 있습니다.

새 동작

ID UI의 기본 UI 프레임워크는 부트스트랩 4입니다. UI 프레임워크는 AddDefaultUI 메서드 호출 대신 프로젝트 파일에 구성되어야 합니다.

변경 이유

정적 웹 자산 기능을 채택하려면 UI 프레임워크 구성이 MSBuild로 이동해야 했습니다. 포함할 프레임워크를 결정하는 것은 런타임 결정이 아니라 빌드 시간 결정입니다.

사이트 UI를 검토하여 새 부트스트랩 4 구성 요소가 호환되는지 확인합니다. 필요한 경우 IdentityUIFrameworkVersion MSBuild 속성을 사용하여 부트스트랩 3으로 되돌립니다. 프로젝트 파일의 <PropertyGroup> 요소에 속성을 추가합니다.

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

범주

ASP.NET Core

영향을 받는 API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: 연결 어댑터가 제거됨

"pubternal" API를 public으로 이동하는 과정의 일부로, IConnectionAdapter의 개념이 Kestrel에서 제거되었습니다. 연결 어댑터는 연결 미들웨어(ASP.NET Core 파이프라인의 HTTP 미들웨어와 유사하지만 하위 수준 연결용)로 대체되고 있습니다. HTTPS 및 연결 로깅은 연결 어댑터에서 연결 미들웨어로 이동했습니다. 이러한 확장 메서드는 계속해서 원활하게 작동하지만 구현 세부 정보는 변경되었습니다.

자세한 내용은 dotnet/aspnetcore#11412를 참조하세요. 토론은 dotnet/aspnetcore#11475를 참조하세요.

도입된 버전

3.0

이전 동작

IConnectionAdapter를 사용하여 kestrel 확장성 구성 요소를 만들었습니다.

새 동작

kestrel 확장성 구성 요소는 미들웨어로 만들었습니다.

변경 이유

이 변경은 보다 유연한 확장성 아키텍처를 제공하기 위한 것입니다.

여기에 표시된 대로 새 미들웨어 패턴을 사용하도록 IConnectionAdapter의 구현을 변환합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter

Kestrel: 빈 HTTPS 어셈블리가 제거됨

Microsoft.AspNetCore.Server.Kestrel.Https 어셈블리가 제거되었습니다.

도입된 버전

3.0

변경 이유

ASP.NET Core 2.1에서 Microsoft.AspNetCore.Server.Kestrel.Https의 내용이 Microsoft.AspNetCore.Server.Kestrel.Core으로 이동했습니다. 이 변경은 [TypeForwardedTo] 특성을 사용하여 중단되지 않는 방식으로 수행되었습니다.

  • Microsoft.AspNetCore.Server.Kestrel.Https 2.0를 참조하는 라이브러리는 모든 ASP.NET Core 종속성을 2.1 이상으로 업데이트해야 합니다. 그렇지 않으면 ASP.NET Core 3.0 앱에 로드될 때 중단될 수 있습니다.
  • ASP.NET Core 2.1 이상을 대상으로 하는 앱 및 라이브러리는 Microsoft.AspNetCore.Server.Kestrel.Https NuGet 패키지에 대한 직접 참조를 모두 제거해야 합니다.

범주

ASP.NET Core

영향을 받는 API

없음

Kestrel: 요청 후행부 헤더가 새 컬렉션으로 이동됨

이전 버전에서 Kestrel은 요청 본문을 끝까지 읽을 때 HTTP/1.1 청크 처리된 트레일러 헤더를 요청 헤더 컬렉션에 추가했습니다. 이 동작은 헤더와 트레일러 사이의 모호성에 대한 문제를 발생시켰습니다. 트레일러를 새 컬렉션으로 이동하기로 결정했습니다.

HTTP/2 요청 트레일러는 ASP.NET Core 2.2에서 사용할 수 없었지만 이제 ASP.NET Core 3.0의 이 새 컬렉션에서도 사용할 수 있습니다.

이러한 트레일러에 액세스하기 위해 새 요청 확장 메서드가 추가되었습니다.

HTTP/1.1 트레일러는 전체 요청 본문을 읽은 후에 사용할 수 있습니다.

HTTP/2 트레일러는 클라이언트에서 수신한 후 사용할 수 있습니다. 클라이언트는 전체 요청 본문이 최소한 서버에 의해 버퍼링될 때까지 트레일러를 보내지 않습니다. 버퍼 공간을 확보하기 위해 요청 본문을 읽어야 할 수도 있습니다. 트레일러는 요청 본문을 끝까지 읽으면 항상 사용할 수 있습니다. 트레일러는 본문의 끝을 표시합니다.

도입된 버전

3.0

이전 동작

요청 트레일러 헤더가 HttpRequest.Headers 컬렉션에 추가됩니다.

새 동작

요청 트레일러 헤더가 HttpRequest.Headers 컬렉션에 존재하지 않습니다. HttpRequest에서 다음 확장 메서드를 사용하여 액세스합니다.

  • GetDeclaredTrailers() - 본문 다음에 사용할 트레일러를 나열하는 요청 "트레일러" 헤더를 가져옵니다.
  • SupportsTrailers() - 요청에서 트레일러 헤더 수신을 지원하는지 여부를 나타냅니다.
  • CheckTrailersAvailable() - 요청에서 트레일러를 지원하는지 여부와 읽을 수 있는지 여부를 확인합니다.
  • GetTrailer(string trailerName) - 응답에서 요청된 후행 헤더를 가져옵니다.

변경 이유

트레일러는 gRPC와 같은 시나리오의 주요 기능입니다. 트레일러를 병합하여 헤더를 요청하는 것은 사용자에게 혼동을 줍니다.

HttpRequest에서 트레일러 관련 확장 메서드를 사용하여 트레일러에 액세스합니다.

범주

ASP.NET Core

영향을 받는 API

HttpRequest.Headers

Kestrel: 전송 추상화 제거 및 공용

"pubternal" API에서 벗어나 이동하는 과정에서 Kestrel 전송 계층 API는 Microsoft.AspNetCore.Connections.Abstractions 라이브러리의 공용 인터페이스로 노출됩니다.

도입된 버전

3.0

이전 동작

  • 전송 관련 추상화는 Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions 라이브러리에서 사용할 수 있었습니다.
  • ListenOptions.NoDelay 속성을 사용할 수 있었습니다.

새 동작

  • IConnectionListener 인터페이스는 ...Transport.Abstractions 라이브러리에서 가장 많이 사용되는 기능을 노출하기 위해 Microsoft.AspNetCore.Connections.Abstractions 라이브러리에 도입되었습니다.
  • 이제 NoDelay는 전송 옵션(LibuvTransportOptions 및 SocketTransportOptions)에서 사용할 수 있습니다.
  • SchedulingMode를 더 이상 사용할 수 없습니다.

변경 이유

ASP.NET Core 3.0은 "pubternal" API에서 벗어나 이동했습니다.

범주

ASP.NET Core

영향을 받는 API

없음

지역화: ResourceManagerWithCultureStringLocalizer 및 WithCulture가 사용되지 않음으로 표시됨

ResourceManagerWithCultureStringLocalizer 클래스 및 WithCulture 인터페이스 멤버는 특히 고유한 IStringLocalizer 구현을 만들 때 지역화 사용자에게 혼동의 원인이 됩니다. 이러한 항목은 사용자에게 IStringLocalizer 인스턴스가 "언어별, 리소스별"이라는 인상을 줍니다. 실제로 인스턴스는 "리소스별"이어야 합니다. 검색된 언어는 실행 시 CultureInfo.CurrentUICulture에 의해 결정됩니다. 혼동의 원인을 제거하기 위해 API는 ASP.NET Core 3.0 Preview 3에서 사용되지 않는 것으로 표시되었습니다. API는 이후 릴리스에서 제거됩니다.

컨텍스트는 dotnet/aspnetcore#3324를 참조하세요. 토론은 dotnet/aspnetcore#7756을 참조하세요.

도입된 버전

3.0

이전 동작

메서드가 Obsolete로 표시되지 않았습니다.

새 동작

메서드는 Obsolete로 표시됩니다.

변경 이유

API는 권장되지 않는 사용 사례를 나타냅니다. 지역화 디자인에 대한 혼동이 있었습니다.

대신 ResourceManagerStringLocalizer를 사용하는 것이 좋습니다. CurrentCulture에서 문화권을 설정하도록 합니다. 옵션이 아닌 경우 ResourceManagerWithCultureStringLocalizer 복사본을 만들고 사용합니다.

범주

ASP.NET Core

영향을 받는 API

로깅: DebugLogger 클래스가 내부로 만들어짐

ASP.NET Core 3.0 이전에는 DebugLogger의 액세스 한정자가 public였습니다. ASP.NET Core 3.0에서 액세스 한정자가 internal로 변경되었습니다.

도입된 버전

3.0

변경 이유

변경 내용은 다음과 같습니다.

  • ConsoleLogger와 같은 다른 로거 구현과 일관성을 유지합니다.
  • API 표면을 줄입니다.

AddDebugILoggingBuilder 확장 메서드를 사용하여 디버그 로깅을 사용하도록 설정합니다. 서비스를 수동으로 동록해야 하는 경우에도 DebugLoggerProvider는 여전히 public입니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: 컨트롤러 작업 이름에서 비동기 접미사가 잘림

dotnet/aspnetcore#4849를 해결하는 과정의 일부로, ASP.NET Core MVC는 기본적으로 작업 이름에서 Async 접미사를 잘라냅니다. ASP.NET Core 3.0부터 이 변경 내용은 라우팅 및 링크 생성 모두에 영향을 줍니다.

도입된 버전

3.0

이전 동작

다음 ASP.NET Core MVC 컨트롤러를 고려하세요.

public class ProductController : Controller
{
    public async IActionResult ListAsync()
    {
        var model = await DbContext.Products.ToListAsync();
        return View(model);
    }
}

작업은 Product/ListAsync를 통해 라우팅할 수 있습니다. 링크 생성을 위해서는 Async 접미사를 지정해야 합니다. 예시:

<a asp-controller="Product" asp-action="ListAsync">List</a>

새 동작

ASP.NET Core 3.0에서 작업은 Product/List를 통해 라우팅할 수 있습니다. 링크 생성 코드는 Async 접미사를 생략해야 합니다. 예시:

<a asp-controller="Product" asp-action="List">List</a>

이 변경은 [ActionName] 특성을 사용하여 지정된 이름에는 영향을 주지 않습니다. Startup.ConfigureServices에서 MvcOptions.SuppressAsyncSuffixInActionNames를 false로 설정하여 새 동작을 사용하지 않도록 설정할 수 있습니다.

services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

변경 이유

규칙에 따라 비동기 .NET 메서드는 Async로 접미사가 붙습니다. 그러나 메서드가 MVC 작업을 정의할 때 Async 접미사를 사용하는 것은 바람직하지 않습니다.

앱이 이름의 Async 접미사를 유지하는 MVC 작업에 의존하는 경우 다음 완화 방법 중 하나를 선택합니다.

  • [ActionName] 특성을 사용하여 원래 이름을 유지합니다.
  • Startup.ConfigureServices에서 MvcOptions.SuppressAsyncSuffixInActionNames를 false로 설정하여 전체 이름 바꾸기를 사용하지 않도록 설정합니다.
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

범주

ASP.NET Core

영향을 받는 API

없음

MVC: JsonResult를 Microsoft.AspNetCore.Mvc.Core로 이동

JsonResult가 Microsoft.AspNetCore.Mvc.Core 어셈블리로 이동했습니다. 이 형식은 Microsoft.AspNetCore.Mvc.Formatters.Json에서 정의되었습니다. 대부분 사용자의 문제를 해결하기 위해 어셈블리 수준 [TypeForwardedTo] 특성이 Microsoft.AspNetCore.Mvc.Formatters.Json에 추가되었습니다. 타사 라이브러리를 사용하는 앱에서 문제가 발생할 수 있습니다.

도입된 버전

3.0 미리 보기 6

이전 동작

2.2 기반 라이브러리를 사용하는 앱이 성공적으로 빌드됩니다.

새 동작

2.2 기반 라이브러리를 사용하는 앱이 컴파일에 실패합니다. 다음 텍스트의 변형을 포함하는 오류가 제공됩니다.

The type 'JsonResult' exists in both 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

이러한 문제의 예는 dotnet/aspnetcore#7220을 참조하세요.

변경 이유

플랫폼 수준이 aspnet/Announcements#325에서 설명하는 것과 같이 ASP.NET Core의 컴퍼지션으로 변경됩니다.

Microsoft.AspNetCore.Mvc.Formatters.Json 2.2 버전에 대해 컴파일된 라이브러리를 다시 컴파일하여 모든 소비자에 대한 문제를 해결해야 할 수 있습니다. 영향을 받는 경우 라이브러리 작성자에게 문의하세요. ASP.NET Core 3.0을 대상으로 하는 라이브러리의 재컴파일을 요청합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Mvc.JsonResult

MVC: 사전 컴파일 도구가 사용되지 않음

ASP.NET Core 1.1에서는 Razor 파일(.cshtml 파일)의 게시 시간 컴파일 지원을 추가하기 위해 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation(MVC 미리 컴파일 도구) 패키지가 도입되었습니다. ASP.NET Core 2.1에서는 Razor SDK가 미리 컴파일 도구의 기능을 확장하기 위해 도입되었습니다. Razor SDK는 Razor 파일의 빌드 및 게시 시간 컴파일에 대한 지원을 추가했습니다. SDK는 앱 시작 시간을 개선하면서 빌드 시 .cshtml 파일의 정확성을 확인합니다. Razor SDK는 기본적으로 켜져 있으며 사용을 시작하는 데 제스처는 필요하지 않습니다.

ASP.NET Core 3.0에서는 ASP.NET Core 1.1-era MVC 미리 컴파일 도구가 제거되었습니다. 이전 패키지 버전은 패치 릴리스에서 중요한 버그 및 보안 픽스를 계속 받습니다.

도입된 버전

3.0

이전 동작

Microsoft.AspNetCore.Mvc.Razor.ViewCompilation 패키지는 MVC Razor 뷰를 미리 컴파일하는 데 사용되었습니다.

새 동작

Razor SDK는 기본적으로 이 기능을 지원합니다. Microsoft.AspNetCore.Mvc.Razor.ViewCompilation 패키지가 더 이상 업데이트되지 않습니다.

변경 이유

Razor SDK는 더 많은 기능을 제공하고 빌드 시 .cshtml 파일의 정확성을 확인합니다. 또한 SDK는 앱 시작 시간을 개선합니다.

ASP.NET Core 2.1 이상 사용자의 경우 Razor SDK에서 미리 컴파일에 대한 기본 지원을 사용하도록 업데이트합니다. 버그 또는 누락된 기능으로 인해 Razor SDK로 마이그레이션할 수 없는 경우 dotnet/aspnetcore에서 문제를 엽니다.

범주

ASP.NET Core

영향을 받는 API

없음

MVC: "Pubternal" 형식이 내부로 변경됨

ASP.NET Core 3.0에서는 MVC의 모든 "pubternal" 형식이 지원되는 네임스페이스에서 public 또는 필요에 따라 internal로 업데이트되었습니다.

변경 내용 설명

ASP.NET Core에서 "pubternal" 형식은 public으로 선언되었지만 .Internal 접미사가 지정된 네임스페이스에 있습니다. 이러한 형식은 public이지만 지원 정책이 없으며 호환성이 손상되는 변경이 적용됩니다. 아쉽게도 이러한 형식의 우발적 사용이 일반적으로 발생하므로 이러한 프로젝트에 대한 호환성이 손상되는 변경이 발생하고 프레임워크를 유지 관리하는 기능이 제한됩니다.

도입된 버전

3.0

이전 동작

MVC의 일부 형식은 public이지만 .Internal 네임스페이스에 있습니다. 이러한 형식에는 지원 정책이 없었으며 호환성이 손상되는 변경이 적용되었습니다.

새 동작

이러한 모든 형식은 지원되는 네임스페이스에서 public으로 업데이트되거나 internal로 표시됩니다.

변경 이유

"pubternal" 형식의 우발적 사용이 일반적으로 발생하므로 이러한 프로젝트에 대한 호환성이 손상되는 변경이 발생하고 프레임워크를 유지 관리하는 기능이 제한됩니다.

실제로 public이 되고 지원되는 새 네임스페이스로 이동한 형식을 사용하는 경우 새 네임스페이스와 일치하도록 참조를 업데이트합니다.

internal로 표시된 형식을 사용하는 경우에는 다른 방법을 찾아야 합니다. 이전에 "pubternal" 형식은 공용으로 지원되지 않았습니다. 이러한 네임스페이스의 앱에 중요한 특정 형식이 있는 경우 dotnet/aspnetcore에서 문제를 해결합니다. 요청된 형식 public을 만드는 것을 고려할 수 있습니다.

범주

ASP.NET Core

영향을 받는 API

이 변경 내용에는 다음 네임스페이스의 형식이 포함됩니다.

  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal

MVC: 웹 API 호환성 심이 제거됨

ASP.NET Core 3.0부터는 Microsoft.AspNetCore.Mvc.WebApiCompatShim 패키지를 더 이상 사용할 수 없습니다.

변경 내용 설명

Microsoft.AspNetCore.Mvc.WebApiCompatShim(WebApiCompatShim) 패키지는 ASP.NET Core에서 ASP.NET 4.x Web API 2와의 부분 호환성을 제공하여 기존 Web API 구현을 ASP.NET Core로 마이그레이션하는 것을 간소화합니다. 그러나 WebApiCompatShim을 사용하는 앱은 최신 ASP.NET Core 릴리스에서 제공되는 API 관련 기능의 이점을 활용하지 못합니다. 이러한 기능에는 향상된 Open API 사양 생성, 표준화된 오류 처리 및 클라이언트 코드 생성이 포함됩니다. 3.0에서 API 노력에 더 집중하기 위해 WebApiCompatShim이 제거되었습니다. WebApiCompatShim을 사용하는 기존 앱은 최신 [ApiController] 모델로 마이그레이션해야 합니다.

도입된 버전

3.0

변경 이유

Web API 호환성 shim은 마이그레이션 도구였습니다. ASP.NET Core에 추가된 새로운 기능에 대한 사용자 액세스를 제한합니다.

이 shim의 사용을 제거하고 ASP.NET Core 자체의 유사한 기능으로 직접 마이그레이션합니다.

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API가 제거됨

RazorTemplateEngine API가 제거되고 Microsoft.AspNetCore.Razor.Language.RazorProjectEngine으로 바뀌었습니다.

자세한 내용은 GitHub 이슈 dotnet/aspnetcore#25215를 참조하세요.

도입된 버전

3.0

이전 동작

템플릿 엔진을 만들고 Razor 파일의 코드를 구문 분석하고 생성하는 데 사용할 수 있습니다.

새 동작

RazorProjectEngine을 만들고 Razor 파일의 코드를 구문 분석하고 생성하기 위해 해당 엔진에 RazorTemplateEngine과 동일한 유형의 정보를 제공할 수 있습니다. RazorProjectEngine은 추가 수준의 구성도 제공합니다.

변경 이유

RazorTemplateEngine이 기존 구현과 너무 긴밀하게 결합되었습니다. 이러한 결합으로 인해 Razor 구문 분석/생성 파이프라인을 제대로 구성하려고 할 때 더 많은 질문이 발생했습니다.

RazorProjectEngine 대신 RazorTemplateEngine를 사용합니다. 다음 예를 살펴보세요.

RazorProjectEngine 만들기 및 구성
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

                // Can also configure other aspects of the class here.
            });

            // More configuration can go here
        });
Razor 파일의 코드 생성
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
    output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();

범주

ASP.NET Core

영향을 받는 API

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: 런타임 컴파일이 패키지로 이동됨

Razor 뷰 및 Razor Pages의 런타임 컴파일을 지원하기 위해 별도의 패키지로 이동되었습니다.

도입된 버전

3.0

이전 동작

추가 패키지 없이 런타임 컴파일을 사용할 수 있습니다.

새 동작

이 기능은 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 패키지로 이동되었습니다.

런타임 컴파일을 지원하기 위해 이전에 Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions에서 다음 API를 사용할 수 있었습니다. 이제 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions를 통해 API를 사용할 수 있습니다.

  • RazorViewEngineOptions.FileProviders는 이제 MvcRazorRuntimeCompilationOptions.FileProviders입니다.
  • RazorViewEngineOptions.AdditionalCompilationReferences는 이제 MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths입니다.

또한 Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange가 제거되었습니다. 파일 변경 시 재컴파일은 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 패키지를 참조하여 기본적으로 사용하도록 설정됩니다.

변경 이유

이 변경은 Roslyn에서 ASP.NET Core 공유 프레임워크 종속성을 제거하기 위해 필요했습니다.

Razor 파일의 런타임 컴파일 또는 재컴파일이 필요한 앱은 다음 단계를 수행해야 합니다.

  1. Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 패키지에 대한 참조를 추가합니다.

  2. AddRazorRuntimeCompilation에 대한 호출을 포함하도록 프로젝트의 Startup.ConfigureServices 메서드를 업데이트합니다. 예시:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

범주

ASP.NET Core

영향을 받는 API

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

세션 상태: 사용되지 않는 API가 제거됨

세션 쿠키를 구성하는 데 사용되지 않는 API가 제거되었습니다. 자세한 내용은 aspnet/Announcements#257을 참조하세요.

도입된 버전

3.0

변경 이유

이 변경 내용은 쿠키를 사용하는 기능을 구성하기 위해 API 간에 일관성을 유지합니다.

제거된 API의 사용을 새 대체 항목으로 마이그레이션합니다. Startup.ConfigureServices에서 다음 예제를 참조하세요.

public void ConfigureServices(ServiceCollection services)
{
    services.AddSession(options =>
    {
        // Removed obsolete APIs
        options.CookieName = "SessionCookie";
        options.CookieDomain = "contoso.com";
        options.CookiePath = "/";
        options.CookieHttpOnly = true;
        options.CookieSecure = CookieSecurePolicy.Always;

        // new API
        options.Cookie.Name = "SessionCookie";
        options.Cookie.Domain = "contoso.com";
        options.Cookie.Path = "/";
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

범주

ASP.NET Core

영향을 받는 API

공유 프레임워크: Microsoft.AspNetCore.App에서 제거되는 어셈블리

ASP.NET Core 3.0부터 ASP.NET Core 공유 프레임워크(Microsoft.AspNetCore.App)에는 Microsoft에서 완전히 개발하고, 지원하고, 서비스를 제공하는 자사 어셈블리만 포함되어 있습니다.

변경 내용 설명

이러한 변경은 ASP.NET Core "플랫폼"의 경계를 다시 정의하는 것으로 간주합니다. 공유 프레임워크는 GitHub를 통해 누구나 원본으로 빌드할 수 있으며, .NET Core 공유 프레임워크의 기존 이점을 앱에 계속 제공합니다. 몇 가지 이점으로 더 작은 배포 크기, 중앙 집중식 패치, 더 빠른 시작 시간 등이 있습니다.

변경의 일부로 몇 가지 주목할 만한 호환성이 손상되는 변경이 Microsoft.AspNetCore.App에 도입되었습니다.

도입된 버전

3.0

이전 동작

프로젝트는 프로젝트 파일의 <PackageReference> 요소를 통해 Microsoft.AspNetCore.App을 참조했습니다.

또한 Microsoft.AspNetCore.App에는 다음과 같은 하위 구성 요소가 포함되었습니다.

  • Json.NET(Newtonsoft.Json)
  • Entity Framework Core(접두사가 Microsoft.EntityFrameworkCore.인 어셈블리)
  • Roslyn(Microsoft.CodeAnalysis)

새 동작

Microsoft.AspNetCore.App에 대한 참조에는 더 이상 프로젝트 파일의 <PackageReference> 요소가 필요하지 않습니다. .NET Core SDK는 <PackageReference>의 사용을 대체하는 <FrameworkReference>라는 새 요소를 지원합니다.

자세한 내용은 dotnet/aspnetcore#3612를 참조하세요.

Entity Framework Core는 NuGet 패키지로 제공됩니다. 이 변경은 배송 모델을 .NET의 다른 모든 데이터 액세스 라이브러리와 맞춥니다. 다양한 .NET 플랫폼을 지원하면서 계속 혁신할 수 있는 가장 간단한 경로인 Entity Framework Core를 제공합니다. Entity Framework Core를 공유 프레임워크 밖으로 이동하더라도 Microsoft에서 개발하고, 지원하고, 서비스를 제공하는 라이브러리의 상태에는 영향을 주지 않습니다. .NET Core 지원 정책에서는 이를 계속 다루고 있습니다.

Json.NET 및 Entity Framework Core는 ASP.NET Core를 계속 사용합니다. 그러나 공유 프레임워크에는 포함되지 않습니다.

자세한 내용은 .NET Core 3.0에서 JSON의 미래를 참조하세요. 또한 공유 프레임워크에서 제거된 이진 파일의 전체 목록도 참조하세요.

변경 이유

이 변경으로 인해 Microsoft.AspNetCore.App의 사용이 간소화되고 NuGet 패키지와 공유 프레임워크 간의 중복이 줄어듭니다.

이 변경의 동기에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.

ASP.NET Core 3.0부터 더 이상 프로젝트가 Microsoft.AspNetCore.App에서 NuGet 패키지로 어셈블리를 사용할 필요가 없습니다. ASP.NET Core 공유 프레임워크의 대상 지정 및 사용을 간소화하기 위해 ASP.NET Core 1.0 이후에 제공된 많은 NuGet 패키지가 더 이상 생성되지 않습니다. 이러한 패키지에서 제공하는 API는 <FrameworkReference>를 Microsoft.AspNetCore.App에 사용하여 앱에서 계속 사용할 수 있습니다. 일반적인 API의 예로 Kestrel, MVC 및 Razor가 있습니다.

이 변경은 ASP.NET Core 2.x의 Microsoft.AspNetCore.App을 통해 참조되는 모든 이진 파일에 적용되지 않습니다. 주목할 만한 예외는 다음과 같습니다.

  • 계속해서 .NET Standard를 대상으로 하는 Microsoft.Extensions 라이브러리는 NuGet 패키지로 사용할 수 있습니다(https://github.com/dotnet/extensions 참조).
  • Microsoft.AspNetCore.App의 일부가 아닌 ASP.NET Core 팀에서 생성한 API입니다. 예를 들어 NuGet 패키지로 사용할 수 있는 구성 요소는 다음과 같습니다.
  • Json.NET 지원을 유지하는 MVC 확장. API는 Json.NET 및 MVC 사용을 지원하기 위해 NuGet 패키지로 제공됩니다. 자세한 내용은 ASP.NET Core 마이그레이션 가이드를 참조하세요.
  • SignalR .NET 클라이언트는 .NET Standard를 계속 지원하며 NuGet 패키지로 제공됩니다. 이는 Xamarin 및 UWP와 같은 많은 .NET 런타임에서 사용하기 위한 것입니다.

자세한 내용은 3.0에서 공유 프레임워크 어셈블리용 패키지 생성 중지를 참조하세요. 토론은 dotnet/aspnetcore#3757을 참조하세요.

범주

ASP.NET Core

영향을 받는 API

공유 프레임워크: Microsoft.AspNetCore.All이 제거됨

ASP.NET Core 3.0부터 Microsoft.AspNetCore.All 메타패키지 및 일치하는 Microsoft.AspNetCore.All 공유 프레임워크가 더 이상 생성되지 않습니다. 이 패키지는 ASP.NET Core 2.2에서 사용할 수 있으며 ASP.NET Core 2.1에서 서비스 업데이트를 계속 받을 수 있습니다.

도입된 버전

3.0

이전 동작

앱은 Microsoft.AspNetCore.All 메타패키지를 사용하여 .NET Core에서 Microsoft.AspNetCore.All 공유 프레임워크를 대상으로 할 수 있습니다.

새 동작

.NET Core 3.0에는 Microsoft.AspNetCore.All 공유 프레임워크가 포함되어 있지 않습니다.

변경 이유

Microsoft.AspNetCore.All 메타패키지에는 많은 수의 외부 종속성이 포함되어 있습니다.

Microsoft.AspNetCore.App 프레임워크를 사용하도록 프로젝트를 마이그레이션합니다. 이전에 Microsoft.AspNetCore.All에서 사용할 수 있었던 구성 요소는 NuGet에서 계속 사용할 수 있습니다. 이러한 구성 요소는 이제 공유 프레임워크에 포함되지 않고 앱과 함께 배포됩니다.

범주

ASP.NET Core

영향을 받는 API

없음

SignalR: HandshakeProtocol.SuccessHandshakeData가 바뀜

HandshakeProtocol.SuccessHandshakeData 필드가 제거되었으며 특정 IHubProtocol에 제공된 성공적인 핸드셰이크 응답을 생성하는 도우미 메서드로 대체되었습니다.

도입된 버전

3.0

이전 동작

HandshakeProtocol.SuccessHandshakeData는 public static ReadOnlyMemory<byte> 필드입니다.

새 동작

HandshakeProtocol.SuccessHandshakeData는 지정된 프로토콜을 기반으로 ReadOnlyMemory<byte>를 반환하는 staticGetSuccessfulHandshake(IHubProtocol protocol) 메서드로 대체되었습니다.

변경 이유

비상수이며 선택된 프로토콜에 따라 변경되는 추가 필드가 핸드셰이크 응답에 추가되었습니다.

없음 이 형식은 사용자 코드에서 사용하도록 설계되지 않았습니다. public이기 때문에 SignalR 서버와 클라이언트 간에 공유할 수 있습니다. .NET으로 작성된 고객 SignalR 클라이언트에서도 사용할 수 있습니다. SignalR의 사용자는 이 변경 내용의 영향을 받지 않아야 합니다.

범주

ASP.NET Core

영향을 받는 API

HandshakeProtocol.SuccessHandshakeData

SignalR: HubConnection ResetSendPing 및 ResetTimeout 메서드가 제거됨

ResetSendPing 및 ResetTimeout 메서드가 SignalR HubConnection API에서 제거되었습니다. 이러한 메서드는 원래 내부용으로만 사용되었지만 ASP.NET Core 2.2에서 공개되었습니다. 이러한 메서드는 ASP.NET Core 3.0 Preview 4 릴리스부터 사용할 수 없습니다. 토론은 dotnet/aspnetcore#8543을 참조하세요.

도입된 버전

3.0

이전 동작

API를 사용할 수 있었습니다.

새 동작

API가 제거되었습니다.

변경 이유

이러한 메서드는 원래 내부용으로만 사용되었지만 ASP.NET Core 2.2에서 공개되었습니다.

이러한 메서드를 사용하지 마세요.

범주

ASP.NET Core

영향을 받는 API

SignalR: HubConnectionContext 생성자가 변경됨

SignalR의 HubConnectionContext 생성자는 이후 증명 추가 옵션에 대해 여러 매개 변수 대신 옵션 유형을 허용하도록 변경되었습니다. 이 변경 내용은 두 개의 생성자를 옵션 유형을 허용하는 단일 생성자로 대체합니다.

도입된 버전

3.0

이전 동작

HubConnectionContext에는 두 개의 생성자가 있습니다.

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);

새 동작

두 개의 생성자가 제거되고 하나의 생성자로 대체되었습니다.

public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)

변경 이유

새 생성자는 새 옵션 개체를 사용합니다. 따라서 나중에 추가 생성자 및 호환성이 손상되는 변경 없이 HubConnectionContext의 기능을 확장할 수 있습니다.

다음 생성자 사용하는 대신:

HubConnectionContext connectionContext = new HubConnectionContext(
    connectionContext,
    keepAliveInterval: TimeSpan.FromSeconds(15),
    loggerFactory,
    clientTimeoutInterval: TimeSpan.FromSeconds(15));

다음 생성자를 사용합니다.

HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
    KeepAliveInterval = TimeSpan.FromSeconds(15),
    ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);

범주

ASP.NET Core

영향을 받는 API

SignalR: JavaScript 클라이언트 패키지 이름이 변경됨

ASP.NET Core 3.0 Preview 7에서 SignalR JavaScript 클라이언트 패키지 이름이 @aspnet/signalr에서 @microsoft/signalr로 변경되었습니다. 이름 변경은 Azure SignalR Service 덕분에 SignalR은 ASP.NET Core 앱 이상에서만 유용하다는 사실을 반영합니다.

이 변경에 대응하려면 package.json 파일, require 문 및 ECMAScript import 문에서 참조를 변경합니다. 이 이름 바꾸기의 일부로 API가 변경되지 않습니다.

토론은 dotnet/aspnetcore#11637을 참조하세요.

도입된 버전

3.0

이전 동작

클라이언트 패키지의 이름은 @aspnet/signalr이었습니다.

새 동작

클라이언트 패키지의 이름은 @microsoft/signalr입니다.

변경 이유

이름 변경은 Azure SignalR Service 덕분에 SignalR은 ASP.NET Core 앱 이외에도 유용합니다.

새 패키지 @microsoft/signalr로 전환합니다.

범주

ASP.NET Core

영향을 받는 API

없음

SignalR: UseSignalR 및 UseConnections 메서드가 사용되지 않음으로 표시됨

UseConnections 및 UseSignalR 메서드와 ConnectionsRouteBuilder 및 HubRouteBuilder 클래스는 ASP.NET Core 3.0에서 사용되지 않는 것으로 표시됩니다.

도입된 버전

3.0

이전 동작

UseSignalR 또는 UseConnections를 사용하여 SignalR 허브 라우팅이 구성되었습니다.

새 동작

라우팅을 구성하는 이전 방법은 사용되지 않으며 엔드포인트 라우팅으로 바뀌었습니다.

변경 이유

미들웨어가 새 엔드포인트 라우팅 시스템으로 이동되고 있습니다. 미들웨어를 추가하는 이전 방법은 사용되지 않습니다.

UseSignalR을 UseEndpoints로 바꿉니다.

이전 코드:

app.UseSignalR(routes =>
{
    routes.MapHub<SomeHub>("/path");
});

새 코드:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHub<SomeHub>("/path");
});

범주

ASP.NET Core

영향을 받는 API

SPA: SpaServices 및 NodeServices가 사용되지 않음으로 표시됨

다음 NuGet 패키지의 내용은 ASP.NET Core 2.1 이후 모두 필요하지 않습니다. 따라서 다음 패키지는 사용되지 않는 것으로 표시됩니다.

동일한 이유로 다음 npm 모듈은 더 이상 사용되지 않는 것으로 표시됩니다.

이전 패키지 및 npm 모듈은 나중에 .NET 5에서 제거됩니다.

도입된 버전

3.0

이전 동작

사용되지 않는 패키지 및 npm 모듈은 ASP.NET Core를 다양한 SPA(단일 페이지 앱) 프레임워크와 통합하기 위한 것입니다. 이러한 프레임워크에는 Angular, React 및 Redux를 사용한 React가 포함됩니다.

새 동작

Microsoft.AspNetCore.SpaServices.Extensions NuGet 패키지에 새 통합 메커니즘이 있습니다. 패키지는 ASP.NET Core 2.1 이후 Angular 및 React 프로젝트 템플릿의 기반으로 유지됩니다.

변경 이유

ASP.NET Core는 Angular, React 및 Redux를 React를 포함한 다양한 SPA(단일 페이지 앱) 프레임워크와의 통합을 지원합니다. 처음에 이러한 프레임워크와의 통합은 서버 쪽 렌더링 및 Webpack과의 통합과 같은 시나리오를 처리하는 ASP.NET Core 관련 구성 요소를 사용하여 수행되었습니다. 시간이 지남에 따라 업계 표준이 변경되었습니다. 각 SPA 프레임워크는 자체 표준 명령줄 인터페이스를 릴리스했습니다. 예를 들어 Angular CLI 및 create-react-app입니다.

2018년 5월에 ASP.NET Core 2.1이 릴리스되었을 때 팀은 표준 변경에 대응했습니다. SPA 프레임워크 자체 도구 체인과 통합하는 새롭고 간단한 방법이 제공되었습니다. 새로운 통합 메커니즘은 Microsoft.AspNetCore.SpaServices.Extensions 패키지에 존재하며 ASP.NET Core 2.1 이후 Angular 및 React 프로젝트 템플릿의 기반으로 유지됩니다.

이전 ASP.NET Core 관련 구성 요소는 관련이 없으며 권장되지 않는다는 것을 명확하게 하기 위해 다음과 같이 합니다.

  • 2.1 이전 통합 메커니즘은 사용되지 않는 것으로 표시되었습니다.
  • 지원되는 npm 패키지는 더 이상 사용되지 않는 것으로 표시됩니다.

이러한 패키지를 사용하는 경우 다음 기능을 사용하도록 앱을 업데이트합니다.

  • Microsoft.AspNetCore.SpaServices.Extensions 패키지에 있습니다.
  • 사용 중인 SPA 프레임워크에서 제공됨

서버 쪽 렌더링 및 핫 모듈 재로드와 같은 기능을 사용하려면 해당 SPA 프레임워크에 대한 설명서를 참조하세요. Microsoft.AspNetCore.SpaServices.Extensions의 기능은 사용되지 않는 것이 아니며 계속 지원됩니다.

범주

ASP.NET Core

영향을 받는 API

SPA: SpaServices 및 NodeServices가 더 이상 콘솔 로거로 대체되지 않음

로깅을 구성하지 않으면 Microsoft.AspNetCore.SpaServices 및 Microsoft.AspNetCore.NodeServices에 콘솔 로그가 표시되지 않습니다.

도입된 버전

3.0

이전 동작

로깅이 구성되지 않은 경우 Microsoft.AspNetCore.SpaServices 및 Microsoft.AspNetCore.NodeServices는 콘솔 로거를 자동으로 만드는 데 사용됩니다.

새 동작

로깅을 구성하지 않으면 Microsoft.AspNetCore.SpaServices 및 Microsoft.AspNetCore.NodeServices에 콘솔 로그가 표시되지 않습니다.

변경 이유

다른 ASP.NET Core 패키지에서 로깅을 구현하는 방법에 맞춰 조정할 필요가 있습니다.

이전 동작이 필요한 경우 콘솔 로깅을 구성하려면 Setup.ConfigureServices 메서드에 services.AddLogging(builder => builder.AddConsole())을 추가합니다.

범주

ASP.NET Core

영향을 받는 API

없음

대상 프레임워크: .NET Framework 지원 삭제

ASP.NET Core 3.0부터 .NET Framework는 지원되는 않는 대상 프레임워크입니다.

변경 내용 설명

.NET Framework 4.8은 .NET Framework의 마지막 주 버전입니다. 새 ASP.NET Core 앱은 .NET Core를 기반으로 빌드해야 합니다. .NET Core 3.0 릴리스부터는 ASP.NET Core 3.0을 .NET Core의 일부로 간주할 수 있습니다.

.NET Framework와 함께 ASP.NET Core를 사용하는 고객은 2.1 LTS 릴리스를 사용하여 완전히 지원되는 방식으로 계속할 수 있습니다. 2.1에 대한 지원 및 서비스는 2021년 8월 21일까지 계속됩니다. 이 날짜는 .NET 지원 정책에 따라 LTS 릴리스가 선언된 후 3년입니다. .NET Framework에서 ASP.NET Core 2.1 패키지에 대한 지원은 다른 패키지 기반 ASP.NET 프레임워크에 대한 서비스 정책과 유사하게 무기한으로 확장됩니다.

.NET Framework에서 .NET Core로 포팅하는 방법에 대한 자세한 내용은 .NET Core로 포팅을 참조하세요.

Microsoft.Extensions 패키지(예: 로깅, 종속성 주입 및 구성)와 Entity Framework Core는 영향을 받지 않습니다. .NET Standard를 계속 지원합니다.

이러한 변경의 동기에 대한 자세한 내용은 원래 블로그 게시물을 참조하세요.

도입된 버전

3.0

이전 동작

ASP.NET Core 앱은 .NET Core 또는 .NET Framework에서 실행될 수 있습니다.

새 동작

ASP.NET Core 앱은 .NET Core에서만 실행할 수 있습니다.

다음 작업 중 하나를 수행합니다.

  • 앱을 ASP.NET Core 2.1에 보관합니다.
  • 앱 및 종속성을 .NET Core로 마이그레이션합니다.

범주

ASP.NET Core

영향을 받는 API

없음

핵심 .NET 라이브러리

버전을 보고하는 API가 이제 파일 버전이 아닌 제품 버전을 보고함

.NET Core의 버전을 반환하는 대부분의 API가 이제 파일 버전이 아닌 제품 버전을 반환합니다.

변경 내용 설명

.NET Core 2.2 및 이전 버전에서는 Environment.Version, RuntimeInformation.FrameworkDescription 등의 메서드와 .NET Core 어셈블리의 파일 속성 대화 상자에 파일 버전이 반영됩니다. .NET Core 3.0부터는 제품 버전이 반영됩니다.

다음 그림은 Windows 탐색기 파일 속성 대화 상자에 표시되는 .NET Core 2.2(왼쪽) 및 .NET Core 3.0(오른쪽)에 대한 System.Runtime.dll 어셈블리의 버전 정보 차이를 보여 줍니다.

Difference in product version information

도입된 버전

3.0

없음 이 변경을 통해 직관적인 버전 검색이 가능합니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

사용자 지정 EncoderFallbackBuffer 인스턴스는 재귀적으로 대체될 수 없음

사용자 지정 EncoderFallbackBuffer 인스턴스는 재귀적으로 대체될 수 없습니다. EncoderFallbackBuffer.GetNextChar()를 구현하면 대상 인코딩으로 변환할 수 있는 문자 시퀀스가 생겨야 합니다. 그렇지 않으면 예외가 발생합니다.

변경 내용 설명

런타임은 문자-바이트 트랜스코딩 작업 도중 형식이 잘못되었거나 변환할 수 없는 UTF-16 시퀀스를 검색하여 해당 문자를 EncoderFallbackBuffer.Fallback 메서드에 제공합니다. Fallback 메서드는 변환할 수 없는 원래 데이터를 대체할 문자를 결정하며, 이러한 문자는 루프에서 EncoderFallbackBuffer.GetNextChar를 호출하여 드레이닝됩니다.

그런 다음 런타임은 이러한 대체 문자를 대상 인코딩으로 트랜스코딩하려고 합니다. 이 작업이 성공하면 런타임은 원래 입력 문자열에서 중단된 위치에서 트랜스코딩을 계속 실행합니다.

이전에는 EncoderFallbackBuffer.GetNextChar()에 대한 사용자 지정 구현은 대상 인코딩으로 변환할 수 없는 문자 시퀀스를 반환할 수 있습니다. 대체된 문자를 대상 인코딩으로 변환할 수 없는 경우 런타임은 대체 문자를 사용하여 EncoderFallbackBuffer.Fallback 메서드를 다시 한 번 호출하여 EncoderFallbackBuffer.GetNextChar() 메서드가 새 대체 시퀀스를 반환할 것을 예상합니다. 이 프로세스는 런타임이 올바른 형식의 변환 가능한 대체를 확인하거나 최대 재귀 횟수에 도달할 때까지 계속됩니다.

.Net Core 3.0부터 EncoderFallbackBuffer.GetNextChar()에 대한 사용자 지정 구현은 대상 인코딩으로 변환할 수 있는 문자 시퀀스를 반환해야 합니다. 대체된 문자를 대상 인코딩으로 트랜스 코딩할 수 없으면 ArgumentException이 throw됩니다. 런타임은 더 이상 EncoderFallbackBuffer 인스턴스에 대한 재귀 호출을 수행하지 않습니다.

이 동작은 다음 조건 중 세 가지를 모두 충족하는 경우에만 적용됩니다.

  • 런타임은 잘못된 형식의 UTF-16 시퀀스 또는 대상 인코딩으로 변환할 수 없는 UTF-16 시퀀스를 검색합니다.
  • 사용자 지정 EncoderFallback이 지정되었습니다.
  • 사용자 지정 EncoderFallback은 잘못된 형식이거나 변환할 수 없는 새 UTF-16 시퀀스를 대체하려고 시도합니다.

도입된 버전

3.0

대부분의 개발자는 아무 작업도 수행하지 않아도 됩니다.

애플리케이션이 사용자 지정 EncoderFallback 및 EncoderFallbackBuffer 클래스를 사용하는 경우 런타임이 처음 Fallback 메서드를 호출할 때 EncoderFallbackBuffer.Fallback 구현이 대상 인코딩으로 직접 변환할 수 있는 올바른 형식의 UTF-16 데이터로 대체 버퍼를 채우도록 합니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

부동 소수점 서식 및 구문 분석 동작 변경됨

이제 부동 소수점 구문 분석 및 서식 동작(Double 및 Single 형식 사용)이 IEEE 규격으로 변경되었습니다. 따라서 .NET의 부동 소수점 형식 동작이 기타 IEEE 규격 언어의 동작과 일치합니다. 예를 들어 double.Parse("SomeLiteral")는 항상 C#에서 double x = SomeLiteral에 대해 생성하는 것과 일치해야 합니다.

변경 내용 설명

.NET Core 2.2 및 이전 버전에서는 Double.ToString 및 Single.ToString을 사용한 서식과 Double.Parse, Double.TryParse, Single.Parse, Single.TryParse을 사용한 구문 분석이 IEEE 규격이 아닙니다. 따라서 지원되는 표준 또는 사용자 지정 형식 문자열로 값이 왕복한다고 보장할 수 없습니다. 입력에 따라 서식이 지정된 값을 구문 분석하려는 시도가 실패하는 경우도 있고, 구문 분석된 값이 원래 값과 달라지는 경우도 있습니다.

.NET Core 3.0부터는 부동 소수점 구문 분석 및 서식 작업이 IEEE 754 규격입니다.

다음 표에서는 두 개의 코드 조각과 .NET Core 2.2와 .NET Core 3.1 사이에서 출력이 어떻게 변경되는지를 보여줍니다.

코드 조각 .NET Core 2.2에서의 출력 .NET Core 3.1에서의 출력
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

자세한 내용은 Floating-point parsing and formatting improvements in .NET Core 3.0(.NET Core 3.0의 부동 소수점 구문 분석 및 서식 개선 사항)에 대한 블로그 게시물을 참조하세요.

도입된 버전

3.0

.NET Core 3.0의 부동 소수점 구문 분석 및 서식 개선 사항 블로그 게시물의 기존 코드에 미치는 잠재적 영향 섹션에서는 이전 동작을 유지하고자 하는 경우 코드에 대해 수행할 수 있는 몇 가지 변경 사항을 제안합니다.

  • 서식에서의 일부 차이점의 경우 다른 서식 문자열을 지정하여 이전 동작과 동일한 동작을 가져올 수 있습니다.
  • 구문 분석에서의 차이점의 경우 이전 동작으로 되돌릴 메커니즘이 없습니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

부동 소수점 구문 분석 작업은 더 이상 실패하거나 OverflowException을 throw하지 않음

부동 소수점 구문 분석 메서드는 더 이상 OverflowException을 throw하지 않거나, 숫자 값이 Single 또는 Double 부동 소수점 형식의 범위를 벗어난 문자열을 구문 분석할 때 false를 반환합니다.

변경 내용 설명

.NET Core 2.2 및 이전 버전에서 Double.Parse 및 Single.Parse 메서드는 해당 형식의 범위를 벗어난 값에 대해 OverflowException를 throw합니다. Double.TryParse 및 Single.TryParse 메서드는 범위를 벗어난 숫자 값의 문자열 표현에 대해 false를 반환합니다.

.NET Core 3.0부터 범위를 벗어난 숫자 문자열을 구문 분석할 때 Double.Parse, Double.TryParse, Single.Parse 및 Single.TryParse 메서드가 더 이상 실패하지 않습니다. 대신 Double 구문 분석 메서드는 Double.MaxValue를 초과하는 값에 대해 Double.PositiveInfinity를 반환하고 Double.MinValue보다 작은 값에 대해 Double.NegativeInfinity를 반환합니다. 마찬가지로 Single 구문 분석 메서드는 Single.MaxValue를 초과하는 값에 대해 Single.PositiveInfinity를 반환하고 Single.MinValue보다 작은 값에 대해 Single.NegativeInfinity를 반환합니다.

이러한 변경은 개정된 IEEE 754:2008 규정 준수를 위해 이루어졌습니다.

도입된 버전

3.0

이러한 변경 내용은 다음 두 가지 방법 중 하나로 코드에 영향을 줄 수 있습니다.

  • 코드는 오버플로가 발생할 때 실행되는 OverflowException에 대한 처리기에 따라 다릅니다. 이 경우 catch 문을 제거하고 Double.IsInfinity 또는 Single.IsInfinity가 true인지 여부를 테스트하는 If 문에 필요한 코드를 넣어야 합니다.

  • 코드에서 부동 소수점 값이 Infinity가 아니라고 가정합니다. 이 경우 PositiveInfinity 및 NegativeInfinity의 부동 소수점 값을 확인하는 데 필요한 코드를 추가해야 합니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

InvalidAsynchronousStateException이 다른 어셈블리로 이동됨

InvalidAsynchronousStateException 클래스가 이동되었습니다.

변경 내용 설명

.NET Core 2.2 및 이전 버전에서는 InvalidAsynchronousStateException 클래스가 System.ComponentModel.TypeConverter 어셈블리에 있습니다.

.NET Core 3.0부터는 System.ComponentModel.Primitives 어셈블리에 있습니다.

도입된 버전

3.0

이 변경은 Assembly.GetType등의 메서드나 형식이 특정 어셈블리에 있다고 가정하는 Activator.CreateInstance 오버로드를 호출하여 리플렉션을 통해 InvalidAsynchronousStateException을 로드하는 애플리케이션에만 영향을 줍니다. 이 경우에는 메서드 호출에서 참조된 어셈블리를 업데이트하여 형식의 새 어셈블리 위치를 반영합니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

없음

잘못된 형식의 UTF-8바이트 시퀀스 교체는 유니코드 지침을 따름

바이트-문자 코드 변환 작업 중에 UTF8Encoding 클래스에서 형식이 잘못된 UTF-8바이트 시퀀스가 있는 경우 출력 문자열에서 이 시퀀스가 '�' 문자(U+FFFD 대체 문자)로 바뀝니다. .NET Core 3.0은 이전 버전의 .NET Core 및 .NET Framework와 달리 트랜스코딩 작업 도중 이 대체를 수행하기 위해 유니코드 모범 사례를 따릅니다.

이는 새로운 System.Text.Unicode.Utf8 및 System.Text.Rune 형식을 포함하여 .NET 전체에서 UTF-8 처리를 향상하기 위해 기울인 보다 많은 노력의 일환입니다. UTF8Encoding 형식에는 새로 도입된 형식과 일치하는 출력을 생성하도록 향상된 오류 처리 메커니즘이 적용되었습니다.

변경 내용 설명

.Net Core 3.0부터 바이트를 문자로 트랜스코딩하는 경우 UTF8Encoding 클래스는 유니코드 모범 사례를 기반으로 문자 대체를 수행합니다. 사용되는 대체 메커니즘은 최대 하위 부분의 U+FFFD 대체 항목의 유니코드 표준 버전 12.0, 섹션 3.9(PDF)에서 설명합니다.

이 동작은 입력 바이트 시퀀스에 잘못된 형식의 UTF-8 데이터가 포함된 경우에만 적용됩니다. 또한 UTF8Encoding 인스턴스가 throwOnInvalidBytes: true를 사용하여 구성된 경우 UTF8Encoding 인스턴스는 U+FFFD 대체를 수행하는 대신 잘못된 입력에 대해 계속 throw합니다. UTF8Encoding 생성자에 대한 자세한 내용은 UTF8Encoding(Boolean, Boolean)를 참조하세요.

다음 표에서는 잘못된 3바이트 입력으로 인한 이 변경의 영향을 보여줍니다.

잘못된 형식의 3바이트 입력 .NET Core 3.0 이하의 출력 .NET Core 3.0 이상의 출력
[ ED A0 90 ] [ FFFD FFFD ](2자 출력) [ FFFD FFFD FFFD ](3자 출력)

3자 출력은 위에 링크된 유니코드 표준 PDF의 표 3-9에 따라 선호되는 출력입니다.

도입된 버전

3.0

개발자는 아무 작업도 수행하지 않아도 됩니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

TypeDescriptionProviderAttribute가 다른 어셈블리로 이동됨

TypeDescriptionProviderAttribute 클래스가 이동되었습니다.

변경 내용 설명

.NET Core 2.2 및 이전 버전에서는 TypeDescriptionProviderAttribute 클래스가 System.ComponentModel.TypeConverter 어셈블리에 있습니다.

.NET Core 3.0부터는 System.ObjectModel 어셈블리에 있습니다.

도입된 버전

3.0

이 변경은 Assembly.GetType등의 메서드나 형식이 특정 어셈블리에 있다고 가정하는 Activator.CreateInstance 오버로드를 호출하여 리플렉션을 통해 TypeDescriptionProviderAttribute 형식을 로드하는 애플리케이션에만 영향을 줍니다. 이 경우에는 메서드 호출에서 참조된 어셈블리를 형식의 새 어셈블리 위치에 맞게 업데이트해야 합니다.

범주

Windows Forms

영향을 받는 API

없음

ZipArchiveEntry가 더 이상 일치하지 않는 항목 크기의 아카이브를 처리하지 않음

Zip 보관 파일은 중앙 디렉터리 및 로컬 헤더에 압축 크기와 압축되지 않은 크기를 모두 나열합니다. 항목 데이터 자체도 크기를 표시합니다. .NET Core 2.2 버전 이하에서는 이러한 값에 대해 일관성을 검사하지 않았습니다. .NET Core 3.0부터는 검사됩니다.

변경 내용 설명

.Net Core 2.2 버전 이하에서는 로컬 헤더가 zip 파일의 중앙 헤더와 일치하지 않는 경우에도 ZipArchiveEntry.Open()이 성공합니다. 데이터는 압축된 스트림의 끝에 도달할 때까지 압축이 풀립니다. 이는 해당 길이가 중앙 디렉터리/로컬 헤더에 나열된 압축되지 않은 파일 크기를 초과하는 경우에도 마찬가지입니다.

.Net Core 3.0부터 ZipArchiveEntry.Open() 메서드는 로컬 헤더 및 중앙 헤더에서 항목의 압축된 크기와 압축되지 않은 크기가 일치하는지 확인합니다. 보관 파일의 로컬 헤더 및/또는 데이터 설명자가 zip 파일의 중앙 디렉터리와 일치하지 않는 크기를 나열하는 경우 메서드가 InvalidDataException을 throw합니다. 항목을 읽을 때 압축 해제된 데이터가 헤더에 나열된 압축되지 않은 파일 크기로 잘립니다.

이러한 변경은 ZipArchiveEntry가 해당 데이터의 크기를 정확하게 표시하고 해당 양의 데이터만 읽도록 하기 위함입니다.

도입된 버전

3.0

이러한 문제가 발생하는 zip 보관 파일을 다시 패키지합니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

FieldInfo.SetValue가 초기화 전용 정적 필드에 대해 예외를 throw

.NET Core 3.0부터 System.Reflection.FieldInfo.SetValue를 호출하여 정적 InitOnly 필드에 값을 설정하려고 하면 예외가 throw됩니다.

변경 내용 설명

.NET Framework 및 3.0 이전 버전의 .NET Core에서는 System.Reflection.FieldInfo.SetValue을 호출하여 초기화 후 상수인 정적 필드의 값을 설정할 수 있습니다(C#의 readonly). 그러나 이러한 필드를 이 방식으로 설정하면 대상 프레임워크 및 최적화 설정에 따라 예기치 않은 동작이 발생합니다.

.NET Core 3.0 이상 버전에서 정적 InitOnly 필드에 SetValue를 호출하면 System.FieldAccessException 예외가 throw됩니다.

팁

InitOnly 필드는 선언되는 시점에 또는 포함하는 클래스의 생성자에서만 설정할 수 있는 필드입니다. 즉, 초기화 후에는 상수입니다.

도입된 버전

3.0

정적 생성자에서 정적 InitOnly 필드를 초기화합니다. 이는 동적 형식과 비동적 형식 모두에 적용됩니다.

또는 필드에서 FieldAttributes.InitOnly 특성을 제거한 다음 FieldInfo.SetValue를 호출할 수 있습니다.

범주

핵심 .NET 라이브러리

영향을 받는 API

IEnumerable<T>를 사용하는 확장 메서드에 GroupCollection을 전달하려면 명확성 필요

GroupCollection에서 IEnumerable<T>를 사용하는 확장 메서드를 호출하는 경우 캐스트를 사용하여 형식을 명확하게 해야 합니다.

변경 내용 설명

.NET Core 3.0부터 System.Text.RegularExpressions.GroupCollection은 구현하는 IEnumerable<Group>을 비롯한 기타 형식 외에 IEnumerable<KeyValuePair<String,Group>>도 구현합니다. 따라서 IEnumerable<T>를 사용하는 확장 메서드를 호출할 때 모호성이 발생합니다. GroupCollection 인스턴스에서 이러한 확장 메서드(예: Enumerable.Count)를 호출하는 경우 다음과 같은 컴파일러 오류가 표시됩니다.

CS1061: ‘GroupCollection’에 ‘Count’에 대한 정의가 없고 ‘GroupCollection’ 형식의 첫 번째 인수를 허용하는 액세스 가능한 확장 메서드 ‘Count’가 없습니다. using 지시문 또는 어셈블리 참조가 있는지 확인하세요.

이전 버전의 .NET에서는 모호성이 없어서 컴파일러 오류가 발생하지 않았습니다.

도입된 버전

3.0

변경 이유

이는 호환성이 손상되는 의도치 않은 변경이었습니다. 이와 같은 상황은 한동안 지속되어 왔으므로 되돌릴 계획이 없습니다. 또한 되돌리는 변경 자체로도 호환성이 손상될 수 있습니다.

GroupCollection 인스턴스의 경우 IEnumerable<T>를 허용하는 확장 메서드의 호출을 캐스트를 사용하여 명확하게 합니다.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

범주

핵심 .NET 라이브러리

영향을 받는 API

IEnumerable<T>를 허용하는 모든 확장 메서드가 영향을 받습니다. 예시:

암호화

Linux에서 루트 인증서에 대해 더 이상 지원되지 않는 "BEGIN TRUSTED CERTIFICATE" 구문

Linux 및 기타 Unix 유사 시스템(macOS 제외)의 루트 인증서는 표준 BEGIN CERTIFICATE PEM 헤더와 OpenSSL별 BEGIN TRUSTED CERTIFICATE PEM 헤더의 두 가지 형태로 제공될 수 있습니다. 후자 구문은 .NET Core의 System.Security.Cryptography.X509Certificates.X509Chain 클래스와의 호환성 문제가 발생한 추가 구성을 허용합니다. .NET Core 3.0부터 체인 엔진이 BEGIN TRUSTED CERTIFICATE 루트 인증서 콘텐츠를 더 이상 로드하지 않습니다.

변경 내용 설명

이전에는 BEGIN CERTIFICATE 및 BEGIN TRUSTED CERTIFICATE 구문이 모두 루트 신뢰 목록을 채우는 데 사용되었습니다. BEGIN TRUSTED CERTIFICATE 구문이 사용되고 파일에 추가 옵션이 지정된 경우 X509Chain에서 체인 트러스트가 명시적으로 허용되지 않았음을 보고했을 수 있습니다(X509ChainStatusFlags.ExplicitDistrust). 그러나 인증서가 이전에 로드된 파일에서 BEGIN CERTIFICATE 구문으로 지정된 경우에는 체인 트러스트가 허용되었습니다.

.NET Core 3.0부터 BEGIN TRUSTED CERTIFICATE 콘텐츠를 더 이상 읽지 않습니다. 표준 BEGIN CERTIFICATE 구문을 통해서도 인증서가 지정되지 않은 경우 X509Chain은 루트를 신뢰할 수 없음으로 보고합니다(X509ChainStatusFlags.UntrustedRoot).

도입된 버전

3.0

대부분의 애플리케이션은 이러한 변경의 영향을 받지 않지만 권한 문제로 인해 루트 인증서 원본을 모두 볼 수 없는 애플리케이션은 업그레이드 후 예기치 않은 UntrustedRoot 오류가 발생할 수 있습니다.

많은 Linux 배포(또는 배포판)는 루트 인증서를 파일당 하나의 인증서 디렉터리 및 하나의 파일 연결의 두 위치에 씁니다. 일부 배포판에서는 파일당 하나의 인증서 디렉터리가 BEGIN TRUSTED CERTIFICATE 구문을 사용하는 반면 파일 연결은 표준 BEGIN CERTIFICATE 구문을 사용합니다. 사용자 지정 루트 인증서를 이러한 위치 중 하나 이상에 BEGIN CERTIFICATE로 추가하고 두 위치를 모두 애플리케이션에서 읽을 수 있는지 확인합니다.

일반적인 디렉터리는 /etc/ssl/certs/이고 일반적인 연결 파일은 /etc/ssl/cert.pem입니다. openssl version -d 명령을 사용하여 /etc/ssl/과 다를 수 있는 플랫폼별 루트를 확인합니다. 예를 들어 Ubuntu 18.04에서 디렉터리는 /usr/lib/ssl/certs/이고 파일은 /usr/lib/ssl/cert.pem입니다. 그러나 /usr/lib/ssl/certs/는 /etc/ssl/certs/에 대한 symlink이며 /usr/lib/ssl/cert.pem은 존재하지 않습니다.

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

범주

암호화

영향을 받는 API

EnvelopedCms를 기본적으로 AES-256 암호화로 설정

EnvelopedCms에서 사용하는 기본 대칭 암호화 알고리즘이 TripleDES에서 AES-256으로 변경되었습니다.

변경 내용 설명

이전 버전에서는 생성자 오버로드를 통해 대칭 암호화 알고리즘을 지정하지 않고 EnvelopedCms가 데이터를 암호화하는 데 사용되는 경우 데이터가 TripleDES/3DES/3DEA/DES3-EDE 알고리즘을 사용하여 암호화됩니다.

.NET Core 3.0부터( System.Security.Cryptography.Pkcs NuGet 패키지의 버전 4.6.0을 통해) 기본 알고리즘이 현대화 알고리즘용 AES-256으로 변경되어 보안 기본 옵션을 개선합니다. 메시지 받는 사람 인증서에 (EC가 아닌) Diffie-Hellman 공개 키가 있는 경우 기본 플랫폼의 제한 사항으로 인해 CryptographicException에서 암호화 작업이 실패할 수 있습니다.

다음 샘플 코드에서는 .NET Core 2.2 이전 버전에서 실행되는 경우 데이터가 TripleDES로 암호화됩니다. .NET Core 3.0 이상에서 실행되는 경우 데이터가 AES-256으로 암호화됩니다.

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

도입된 버전

3.0

이 변경으로 부정적인 영향을 받는 경우 다음과 같이 AlgorithmIdentifier 형식의 매개 변수를 포함하는 EnvelopedCms 생성자에서 암호화 알고리즘 식별자를 명시적으로 지정하여 TripleDES 암호화를 복원할 수 있습니다.

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

범주

암호화

영향을 받는 API

RSAOpenSsl 키 생성 최소 크기가 증가

Linux에서 새 RSA 키를 생성하기 위한 최소 크기가 384비트에서 512비트로 증가했습니다.

변경 내용 설명

.NET Core 3.0부터는 Linux의 RSA.Create, RSAOpenSsl 및 RSACryptoServiceProvider에서 RSA 인스턴스의 LegalKeySizes 속성이 보고하는 합법적인 최소 키 크기가 384에서 512로 증가했습니다.

따라서 .NET Core 2.2 버전 이하에서는 RSA.Create(384) 같은 메서드 호출이 성공합니다. .Net Core 3.0 버전 이상에서 메서드 호출 RSA.Create(384)는 크기가 너무 작음을 나타내는 예외를 throw합니다.

이 변경은 Linux에서 암호화 작업을 수행하는 OpenSSL이 버전 1.0.2와 1.1.0 간에 최소값을 상향했기 때문에 적용된 것입니다. .NET Core 3.0은 OpenSSL 1.0.x보다 1.1.x를 기본으로 적용하고, 이 높아진 새 종속성 제한을 반영하기 위해 보고된 최소 버전이 상향되었습니다.

도입된 버전

3.0

영향을 받는 API를 호출하는 경우 생성된 키의 크기가 공급자 최소값보다 작지 않은지 확인하세요.

참고 항목

384비트 RSA는 이미 안전하지 않은 것으로 간주됩니다(512비트 RSA도 마찬가지). NIST 특별 간행물 800-57 1부 수정 버전 4와 같은 최신 권장 사항은 새로 생성된 키에 대한 최소 크기로 2048 비트를 제안합니다.

범주

암호화

영향을 받는 API

.NET Core 3.0은 OpenSSL 1.0.x보다 OpenSSL 1.1.x를 권장합니다.

여러 Linux 배포판에서 작동하는 Linux용 .NET Core는 OpenSSL 1.0.x와 OpenSSL 1.1.x를 모두 지원합니다. .NET Core 2.1 및 .NET Core 2.2는 먼저 1.0.x를 찾은 다음 1.1.x로 대체합니다. .NET Core 3.0은 1.1.x부터 찾습니다. 이 변경은 새로운 암호화 표준에 대한 지원을 추가하기 위해 실시된 것입니다.

이 변경이 .NET Core에서 OpenSSL 특정 상호 작용 형식으로 플랫폼 상호 작용을 수행하는 라이브러리나 애플리케이션에 영향을 줄 수 있습니다.

변경 내용 설명

.NET Core 2.2 버전 이하에서 런타임은 OpenSSL 1.0.x보다 1.1.x를 우선적으로 로드합니다. 이는 OpenSSL과 상호 작용을 위한 IntPtr 및 SafeHandle 형식이 기본적으로 libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10에 사용된다는 의미입니다.

.Net Core 3.0부터 런타임은 OpenSSL 1.0.x보다 OpenSSL 1.1.x를 우선적으로 로드하므로 OpenSSL과 상호 작용을 위한 IntPtr 및 SafeHandle 형식이 기본적으로 ibcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1에 사용됩니다. 따라서 OpenSSL과 직접 상호 운용되는 라이브러리 및 애플리케이션은 .NET Core 2.1 또는 .NET Core 2.2에서 업그레이드할 경우 .NET Core에 노출된 값과 호환되지 않는 포인터를 가질 수 있습니다.

도입된 버전

3.0

OpenSSL을 사용하여 직접 작업을 수행하는 라이브러리 및 애플리케이션은 .NET Core 런타임과 동일한 버전의 OpenSSL을 사용하고 있는지 확인해야 합니다.

OpenSSL을 사용하여 직접 .NET Core 암호화 형식에서 IntPtr 또는 SafeHandle 값을 사용하는 모든 라이브러리 또는 애플리케이션은사용하는 라이브러리 버전을 새 SafeEvpPKeyHandle.OpenSslVersion 속성과 비교하여 포인터가 호환되는지 확인 해야 합니다.

범주

암호화

영향을 받는 API

CryptoStream.Dispose는 쓰는 경우에만 최종 블록을 변환함

CryptoStream 연산을 완료하기 위해 사용되는 CryptoStream.Dispose 메서드는 읽을 때 더 이상 최종 블록을 변환하려고 시도하지 않습니다.

변경 내용 설명

이전 .NET 버전에서는 사용자가 Read 모드에서 CryptoStream을 사용할 때 불완전한 읽기를 수행하는 경우 Dispose 메서드가 예외를 throw할 수 있습니다(예: 패딩이 포함된 AES를 사용할 경우). 최종 블록을 변환하려고 시도했지만 데이터가 불완전하기 때문에 예외가 throw되었습니다.

.NET Core 3.0 이상 버전에서 Dispose는 읽을 때 더 이상 최종 블록을 변환(불완전한 읽기가 가능함)하려고 시도하지 않습니다.

변경 이유

이렇게 변경하면 네트워크 작업이 취소되는 경우 예외를 catch하지 않고도 암호화 스트림에서 불완전한 읽기가 가능합니다.

도입된 버전

3.0

대부분의 앱은 이 변경의 영향을 받지 않습니다.

불완전한 읽기 발생 시 애플리케이션이 이전에 예외를 catch했다면 해당 catch 블록을 삭제할 수 있습니다. 해시 시나리오에서 앱이 최종 블록의 변환을 사용한 경우 삭제하기 전에 전체 스트림을 읽었는지 확인해야 할 수도 있습니다.

범주

암호화

영향을 받는 API

Entity Framework Core

Entity Framework Core 호환성이 손상되는 변경 사항

전역화

“C” 로캘이 고정 로캘에 매핑됩니다.

.NET Core 2.2 및 이전 버전은 "C" 로캘을 en_US_POSIX 로캘에 매핑하는 기본 ICU 동작에 의존합니다. en_US_POSIX 로캘은 대/소문자를 구분하지 않는 문자열 비교를 지원하지 않으므로 원치 않는 데이터 정렬 동작이 있습니다. 일부 Linux 배포판에서는 "C" 로캘을 기본 로캘로 설정하므로 사용자가 예기치 않은 동작을 경험했습니다.

변경 내용 설명

.NET Core 3.0부터 "C" 로캘 매핑이 en_US_POSIX 대신 고정 로캘을 사용하도록 변경되었습니다. "C" 로캘의 고정 로캘 매핑은 일관성을 위해 Windows에도 적용됩니다.

en_US_POSIX는 대/소문자를 구분하지 않는 정렬/검색 문자열 작업을 지원하지 않기 때문에 "C"를 en_US_POSIX 문화권에 매핑 시 고객의 혼란이 발생했습니다. "C" 로캘이 일부 Linux 배포판에서 기본 로캘로 사용되므로 고객이 이러한 운영 체제에서 이 원치 않는 동작을 경험했습니다.

도입된 버전

3.0

이 변경 내용을 아는 것 외에 특별히 다른 것은 없습니다. 이러한 변경 내용은 “C” 로캘을 사용하는 애플리케이션에만 영향을 줍니다.

범주

전역화

영향을 받는 API

모든 데이터 정렬 및 문화권 API는 이 변경 내용의 영향을 받습니다.

MSBuild

리소스 매니페스트 파일 이름 변경

.NET Core 3.0부터 기본 사례에서 MSBuild는 리소스 파일에 대해 다른 매니페스트 파일 이름을 생성합니다.

도입된 버전

3.0

변경 내용 설명

.NET Core 3.0보다 이전 버전에서는 프로젝트 파일의 EmbeddedResource 항목에 대해 LogicalName, ManifestResourceName 또는 DependentUpon 메타데이터가 지정되지 않은 경우 MSBuild는 <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources 패턴으로 매니페스트 파일 이름을 생성했습니다. 프로젝트 파일에 RootNamespace가 정의되어 있지 않은 경우 기본적으로 프로젝트 이름으로 설정됩니다. 예를 들어, 루트 프로젝트 디렉터리의 Form1.resx라는 리소스 파일에 대해 생성된 매니페스트 이름은 MyProject.Form1.resources였습니다.

.NET Core 3.0부터 리소스 파일이 동일한 이름의 소스 파일과 공동 배치되는 경우(예: Form1.resx와 Form1.cs) MSBuild는 소스 파일의 형식 정보를 사용하여 <Namespace>.<ClassName>.resources 패턴으로 매니페스트 파일 이름을 생성합니다. 네임스페이스 및 클래스 이름은 공동 배치된 소스 파일의 첫 번째 형식에서 추출됩니다. 예를 들어 Form1.cs라는 소스 파일과 공동 배치된 Form1.resx라는 리소스 파일에 대해 생성된 매니페스트 이름은 MyNamespace.Form1.resources입니다. 중요한 점은 파일 이름의 첫 부분이 이전 버전의 .NET Core와 다르다는 것입니다(MyProject가 아니라 MyNamespace).

참고 항목

프로젝트 파일의 EmbeddedResource 항목에 LogicalName, ManifestResourceName 또는 DependentUpon 메타데이터가 지정되어 있는 경우 이 변경 내용은 해당 리소스 파일에 영향을 주지 않습니다.

이 주요 변경 내용은 .NET Core 프로젝트에 EmbeddedResourceUseDependentUponConvention 속성을 추가하여 도입되었습니다. 기본적으로 리소스 파일은 .NET Core 프로젝트 파일에 명시적으로 나열되지 않으므로 생성된 .resources 파일의 이름을 지정하는 방법을 지정하는 DependentUpon 메타데이터가 없습니다. EmbeddedResourceUseDependentUponConvention이 기본값 true로 설정된 경우 MSBuild는 공동 배치된 소스 파일을 찾아 해당 파일에서 네임스페이스 및 클래스 이름을 추출합니다. EmbeddedResourceUseDependentUponConvention을 false로 설정하면 MSBuild는 이전 동작에 따라, 즉 RootNamespace와 상대 파일 경로를 결합하여 매니페스트 이름을 생성합니다.

대부분의 경우 개발자에게는 아무 작업도 필요하지 않으며 앱은 계속 작동할 것입니다. 그러나 이 변경으로 앱이 중단되는 경우 다음 중 하나를 수행할 수 있습니다.

  • 새 매니페스트 이름을 예상하도록 코드를 변경합니다.

  • 프로젝트 파일에서 EmbeddedResourceUseDependentUponConvention을 false로 설정하여 새 명명 규칙을 옵트아웃합니다.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

범주

MSBuild

영향을 받는 API

해당 없음

네트워킹

HttpRequestMessage.Version의 기본값은 1.1로 변경되었습니다.

System.Net.Http.HttpRequestMessage.Version 속성의 기본값은 2.0에서 1.1로 변경되었습니다.

도입된 버전

3.0

변경 내용 설명

.NET Core 1.0 ~ 2.0에서 System.Net.Http.HttpRequestMessage.Version 속성의 기본값은 1.1입니다. .NET Core 2.1부터 2.1로 변경되었습니다.

.NET Core 3.0부터 System.Net.Http.HttpRequestMessage.Version 속성에 의해 반환되는 기본 버전 번호는 다시 1.1입니다.

2.0 기본값을 반환하는 System.Net.Http.HttpRequestMessage.Version 속성에 따라 달라지는 경우 코드를 업데이트합니다.

범주

네트워킹

영향을 받는 API

참고 항목