.NET Core 3.0'da hataya neden olan değişiklikler

  • Makale

.NET Core, ASP.NET Core veya EF Core'un 3.0 sürümüne geçiş yaparsanız, bu makalede listelenen hataya neden olan değişiklikler uygulamanızı etkileyebilir.

ASP.NET Core

Eski Antiforgery, CORS, Tanılama, MVC ve Yönlendirme API'leri kaldırıldı

ASP.NET Core 2.2'deki eski üyeler ve uyumluluk anahtarları kaldırıldı.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

API yüzeyinin zaman içinde geliştirilmesi.

.NET Core 2.2'yi hedeflerken, bunun yerine yeni API'leri benimsemek için eski derleme iletilerindeki yönergeleri izleyin.

Kategori

ASP.NET Core

Etkilenen API’ler

Aşağıdaki türler ve üyeler ASP.NET Core 2.1 ve 2.2 için kullanım dışı olarak işaretlendi:

Türler

  • 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

Oluşturucular

  • 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)

Veri Erişimi

  • 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

Yöntemler

"Pubternal" API'leri kaldırıldı

ASP.NET Core'un genel API yüzeyini daha iyi korumak için ad alanındaki *.Internal türlerin çoğu (API'ler olarak "pubternal" adlandırılır) gerçekten dahili hale gelmiştir. Bu ad alanları içindeki üyelerin hiçbir zaman genel kullanıma yönelik API'ler olarak desteklenmesi amaçlanmamıştır. API'ler küçük sürümlerde bozulabilir ve genellikle kırılabilir. ASP.NET Core 3.0'a güncelleştirildiğinde bu API'lere bağlı kod bozuluyor.

Daha fazla bilgi için bkz . dotnet/aspnetcore#4932 ve dotnet/aspnetcore#11312.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Etkilenen API'ler erişim değiştiricisi ile public işaretlenir ve ad alanları içinde *.Internal bulunur.

Yeni davranış

Etkilenen API'ler iç erişim değiştiricisi ile işaretlenir ve artık bu derlemenin dışındaki kodlar tarafından kullanılamaz.

Değişiklik nedeni

Bu "pubternal" API'ler için rehberlik şu şekildedir:

  • Bildirimde bulunmadan değişebilir.
  • Hataya neden olan değişiklikleri önlemek için .NET ilkelerine tabi değildi.

API'leri public (ad alanları içinde *.Internal bile) bırakmak müşteriler için kafa karıştırıcıydı.

Bu "pubternal" API'leri kullanmayı durdurun. Alternatif API'ler hakkında sorularınız varsa dotnet/aspnetcore deposunda bir sorun açın.

Örneğin, ASP.NET Core 2.2 projesinde aşağıdaki HTTP isteği arabelleğe alma kodunu göz önünde bulundurun. EnableRewind Uzantı yöntemi ad alanında Microsoft.AspNetCore.Http.Internal bulunur.

HttpContext.Request.EnableRewind();

ASP.NET Core 3.0 projesinde, çağrıyı EnableRewind uzantı yöntemine EnableBuffering yapılan bir çağrıyla değiştirin. İstek arabelleğe alma özelliği geçmişte olduğu gibi çalışır. EnableBuffering şimdi internal API'sini çağırır.

HttpContext.Request.EnableBuffering();

Kategori

ASP.NET Core

Etkilenen API’ler

ad alanı adında bir Internal kesimi olan ve Microsoft.Extensions.* ad alanları içindeki tüm API'lerMicrosoft.AspNetCore.*. Örneğin:

  • 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

Kimlik doğrulaması: Google+ kullanım dışı bırakıldı ve değiştirildi

Google, 28 Ocak 2019'da uygulamalar için Google+ Oturum Açma'yı kapatmaya başlıyor.

Açıklama değiştirildi

ASP.NET 4.x ve ASP.NET Core, web uygulamalarında Google hesabı kullanıcılarının kimliğini doğrulamak için Google+ Oturum Açma API'lerini kullanıyor. Etkilenen NuGet paketleri, ASP.NET Core için Microsoft.AspNetCore.Authentication.Google ve ASP.NET Web Forms ve MVC ile Microsoft.Owin.Security.Google'dır Microsoft.Owin.

Google'ın yeni API'leri farklı bir veri kaynağı ve biçimi kullanır. Aşağıda sağlanan risk azaltmalar ve çözümler yapısal değişiklikleri hesaba ekler. Uygulamalar, verilerin gereksinimlerini karşılamaya devam ediyor olduğunu doğrulamalıdır. Örneğin, adlar, e-posta adresleri, profil bağlantıları ve profil fotoğrafları öncekinden çok farklı değerler sağlayabilir.

Sürüm kullanıma sunulmuştur

Tüm sürümler. Bu değişiklik ASP.NET Core dışındadır.

ASP.NET Web Forms ve MVC ile Owin

Microsoft.Owin 3.1.0 ve üzeri için geçici bir azaltma burada özetlenmiştir. Uygulamalar, veri biçimindeki değişiklikleri denetlemek için azaltma ile test işlemini tamamlamalıdır. Bir düzeltme ile 4.0.1'i yayınlama Microsoft.Owin planları vardır. Önceki sürümleri kullanan uygulamalar 4.0.1 sürümüne güncelleştirilmelidir.

ASP.NET Core 1.x

ASP.NET Web Forms ve MVC ile Owin'deki risk azaltma, ASP.NET Core 1.x'e uyarlanabilir. NuGet paketi düzeltme ekleri planlanmamıştır çünkü 1.x kullanım süresi sonuna ulaşmıştır.

ASP.NET Core 2.x

sürüm 2.x için Microsoft.AspNetCore.Authentication.Google , var olan içindeki çağrınızı AddGoogleStartup.ConfigureServices aşağıdaki kodla değiştirin:

.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.1 ve 2.2 Şubat düzeltme ekleri, önceki yeniden yapılandırmayı yeni varsayılan değer olarak birleştirir. ASP.NET Core 2.0 kullanım ömrü sona erdiğinden hiçbir yama planlanmıyor.

ASP.NET Core 3.0

ASP.NET Core 2.x için verilen azaltma, ASP.NET Core 3.0 için de kullanılabilir. Sonraki 3.0 önizlemelerinde Microsoft.AspNetCore.Authentication.Google paket kaldırılabilir. Bunun yerine kullanıcılara Microsoft.AspNetCore.Authentication.OpenIdConnect yönlendirilebilir. Aşağıdaki kod, içinde Startup.ConfigureServicesile AddOpenIdConnect nasıl değiştirilmeye AddGoogle devam yapılacağını gösterir. Bu değiştirme, ASP.NET Core 2.0 ve üzeri ile kullanılabilir ve gerektiğinde ASP.NET Core 1.x için uyarlanabilir.

.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();

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Authentication.Google

Kimlik doğrulaması: HttpContext.Authentication özelliği kaldırıldı

üzerindeki HttpContext kullanım dışı bırakılan Authentication özellik kaldırıldı.

Açıklama değiştirildi

dotnet/aspnetcore#6504'ün bir parçası olarak üzerindeki kullanım dışı bırakılan Authentication özellik HttpContext kaldırıldı. Authentication Özelliği 2.0'dan bu yana kullanım dışı bırakıldı. Bu kullanım dışı bırakılan özellik kullanılarak kodu yeni değiştirme API'lerine geçirmek için bir geçiş kılavuzu yayımlandı. Eski ASP.NET Core 1.x kimlik doğrulama yığınıyla ilgili kalan kullanılmayan sınıflar/API'ler commit dotnet/aspnetcore@d7a7c65 kaldırıldı.

Tartışma için bkz . dotnet/aspnetcore#6533.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

ASP.NET Core 1.0 API'lerinin yerini içindeki Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensionsuzantı yöntemleri aldı.

Geçiş kılavuzuna bakın.

Kategori

ASP.NET Core

Etkilenen API’ler

Kimlik doğrulaması: Newtonsoft.Json türleri değiştirildi

ASP.NET Core 3.0'da, Newtonsoft.Json Kimlik Doğrulama API'lerinde kullanılan türler türlerle System.Text.Json değiştirilmiştir. Aşağıdaki durumlar dışında, Kimlik Doğrulama paketlerinin temel kullanımı etkilenmez:

Daha fazla bilgi için bkz . dotnet/aspnetcore#7105. Tartışma için bkz . dotnet/aspnetcore#7289.

Sürüm kullanıma sunulmuştur

3.0

Türetilmiş OAuth uygulamaları için en yaygın değişiklik, burada gösterildiği gibi geçersiz kılmada CreateTicketAsync ile JsonDocument.Parse değiştirmektirJObject.Parse. JsonDocument uygular IDisposable.

Aşağıdaki listede bilinen değişiklikler özetlenmiştir:

Kategori

ASP.NET Core

Etkilenen API’ler

Kimlik doğrulaması: OAuthHandler ExchangeCodeAsync imzası değiştirildi

ASP.NET Core 3.0'da imzası OAuthHandler.ExchangeCodeAsync şu şekilde değiştirildi:

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

Hedef:

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

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

code ve redirectUri dizeleri ayrı bağımsız değişkenler olarak geçirildi.

Yeni davranış

Code ve RedirectUri oluşturucu aracılığıyla ayarlanabilen özelliklerdir OAuthCodeExchangeContextOAuthCodeExchangeContext . Yeni OAuthCodeExchangeContext tür, öğesine OAuthHandler.ExchangeCodeAsyncgeçirilen tek bağımsız değişkendir.

Değişiklik nedeni

Bu değişiklik, ek parametrelerin hataya neden olmayan bir şekilde sağlanmasına olanak tanır. Yeni ExchangeCodeAsync aşırı yüklemeler oluşturmanıza gerek yoktur.

Uygun code ve redirectUri değerleriyle bir OAuthCodeExchangeContext oluşturma. Bir AuthenticationProperties örnek sağlanmalıdır. Bu tek OAuthCodeExchangeContext örnek birden çok bağımsız değişken yerine öğesine OAuthHandler.ExchangeCodeAsync geçirilebilir.

Kategori

ASP.NET Core

Etkilenen API’ler

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Yetkilendirme: AddAuthorization aşırı yüklemesi farklı derlemeye taşındı

Içinde yer Microsoft.AspNetCore.Authorization almak için kullanılan temel AddAuthorization yöntemler olarak AddAuthorizationCoreyeniden adlandırıldı. Eski AddAuthorization yöntemler hala var, ancak bunun yerine derlemede Microsoft.AspNetCore.Authorization.Policy . Her iki yöntemi kullanan uygulamalar herhangi bir etki görmemelidir. Microsoft.AspNetCore.Authorization.Policy Artık Paylaşılan çerçeve: Derlemeler Microsoft.AspNetCore.App kaldırıldı bölümünde açıklandığı gibi tek başına paket yerine paylaşılan çerçevede kullanıma sunuluyor.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

AddAuthorization yöntemleri içinde Microsoft.AspNetCore.Authorizationmevcutdu.

Yeni davranış

AddAuthorization yöntemleri içinde Microsoft.AspNetCore.Authorization.Policybulunur. AddAuthorizationCore eski yöntemlerin yeni adıdır.

Değişiklik nedeni

AddAuthorization , yetkilendirme için gereken tüm ortak hizmetleri eklemek için daha iyi bir yöntem adıdır.

Bunun yerine öğesine Microsoft.AspNetCore.Authorization.Policy bir başvuru ekleyin veya kullanın AddAuthorizationCore .

Kategori

ASP.NET Core

Etkilenen API’ler

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

Yetkilendirme: IAllowAnonymous AuthorizationFilterContext.Filters öğesinden kaldırıldı

ASP.NET Core 3.0 itibarıyla MVC, denetleyiciler ve eylem yöntemlerinde bulunan [AllowAnonymous] öznitelikleri için AllowAnonymousFilters eklemez. Bu değişiklik, türevleri AuthorizeAttributeiçin yerel olarak ele alınsa da ve IAuthorizationFilter uygulamaları için IAsyncAuthorizationFilter çığır açan bir değişikliktir. [TypeFilter] özniteliğine sarmalanan bu tür uygulamalar, hem yapılandırma hem de bağımlılık ekleme gerektiğinde kesin olarak türlenmiş, öznitelik tabanlı yetkilendirme elde etmenin popüler ve desteklenen bir yoludur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

IAllowAnonymousAuthorizationFilterContext.Filters koleksiyonunda göründü. Arabirimin varlığını test etmek, tek tek denetleyici yöntemlerinde filtreyi geçersiz kılmak veya devre dışı bırakmak için geçerli bir yaklaşımdı.

Yeni davranış

IAllowAnonymous artık koleksiyonda AuthorizationFilterContext.Filters görünmez. IAsyncAuthorizationFilter eski davranışa bağımlı olan uygulamalar genellikle aralıklı HTTP 401 Yetkisiz veya HTTP 403 Yasak yanıtlarına neden olur.

Değişiklik nedeni

ASP.NET Core 3.0'da yeni bir uç nokta yönlendirme stratejisi kullanıma sunulmuştur.

Uç nokta meta verilerini için IAllowAnonymousarayın. Örneğin:

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

Bu tekniğin bir örneği bu HasAllowAnonymous yönteminde görülmektedir.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Yetkilendirme: IAuthorizationPolicyProvider uygulamaları yeni yöntem gerektiriyor

ASP.NET Core 3.0'da öğesine IAuthorizationPolicyProvideryeni GetFallbackPolicyAsync bir yöntem eklendi. Bu geri dönüş ilkesi, hiçbir ilke belirtilmediğinde yetkilendirme ara yazılımı tarafından kullanılır.

Daha fazla bilgi için bkz . dotnet/aspnetcore#9759.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

uygulamaları IAuthorizationPolicyProvider bir GetFallbackPolicyAsync yöntem gerektirmedi.

Yeni davranış

uygulamaları IAuthorizationPolicyProvider bir GetFallbackPolicyAsync yöntem gerektirir.

Değişiklik nedeni

İlke belirtilmediğinde yeninin kullanması için yeni AuthorizationMiddleware bir yöntem gerekiyordu.

GetFallbackPolicyAsync yöntemini uygulamalarınıza IAuthorizationPolicyProviderekleyin.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Önbelleğe Alma: CompactOnMemoryPressure özelliği kaldırıldı

ASP.NET Core 3.0 sürümü, eski MemoryCacheOptions API'lerini kaldırdı.

Açıklama değiştirildi

Bu değişiklik aspnet/Önbelleğe Alma#221'e yapılan bir izlemedir. Tartışma için bkz . dotnet/extensions#1062.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

MemoryCacheOptions.CompactOnMemoryPressure özelliği kullanılabilir durumdaydı.

Yeni davranış

MemoryCacheOptions.CompactOnMemoryPressure özelliği kaldırıldı.

Değişiklik nedeni

Önbelleğin otomatik olarak sıkıştırılması sorunlara neden oldu. Beklenmeyen davranışlardan kaçınmak için önbellek yalnızca gerektiğinde sıkıştırılmalıdır.

Önbelleği sıkıştırmak için alt noktaya yayın MemoryCache yapın ve gerektiğinde çağrısı Compact yapın.

Kategori

ASP.NET Core

Etkilenen API’ler

MemoryCacheOptions.CompactOnMemoryPressure

Önbelleğe Alma: Microsoft.Extensions. Önbelleğe Alma. SqlServer yeni SqlClient paketi kullanıyor

PaketMicrosoft.Extensions.Caching.SqlServer, paket yerine System.Data.SqlClient yeni Microsoft.Data.SqlClient paketi kullanır. Bu değişiklik, küçük davranış hatalarının değişmesine neden olabilir. Daha fazla bilgi için bkz . Yeni Microsoft.Data.SqlClient ile tanışın.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Paket Microsoft.Extensions.Caching.SqlServer , System.Data.SqlClient paketi kullandı.

Yeni davranış

Microsoft.Extensions.Caching.SqlServer artık paketini kullanıyor Microsoft.Data.SqlClient .

Değişiklik nedeni

Microsoft.Data.SqlClient , ile oluşturulan yeni bir pakettir System.Data.SqlClient. Bundan sonra tüm yeni özellik çalışmalarının yapılacağı yer burasıdır.

Müşterilerin paket tarafından Microsoft.Extensions.Caching.SqlServer döndürülen türleri kullanmadıkları ve bunları türlere dönüştürmedikleri System.Data.SqlClient sürece bu hataya neden olan değişiklik konusunda endişelenmeleri gerekmez. Örneğin, birisi eski Sql Bağlan ion türüne bir DbConnection tür atmışsa, atamayı yeni Microsoft.Data.SqlClient.SqlConnection türle değiştirmesi gerekir.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Önbelleğe Alma: Yanıt Önbelleğe Alma "pubternal" türleri dahili olarak değiştirildi

ASP.NET Core 3.0'da ResponseCaching içindeki "pubternal" türleri olarak internaldeğiştirildi.

Ayrıca ve varsayılan uygulamaları IResponseCachingPolicyProviderIResponseCachingKeyProvider artık yönteminin AddResponseCaching bir parçası olarak hizmetlere eklenmez.

Açıklama değiştirildi

ASP.NET Core'da "pubternal" türleri olarak public bildirilir ancak ile .Internalekli bir ad alanında bulunur. Bu türler genel olsa da, destek ilkesi yoktur ve hataya neden olan değişikliklere tabidir. Ne yazık ki, bu türlerin yanlışlıkla kullanılması yaygın olarak görülür ve bu da bu projelerde hataya neden olan değişikliklere ve çerçeveyi koruma becerisini sınırlamaya neden olmuştur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Bu türler genel olarak görünür durumdaydı, ancak desteklenmiyordu.

Yeni davranış

Bu türler artık internalşeklindedir.

Değişiklik nedeni

Kapsam internal desteklenmeyen ilkeyi daha iyi yansıtır.

Uygulamanız veya kitaplığınız tarafından kullanılan kopyalama türleri.

Kategori

ASP.NET Core

Etkilenen API’ler

Veri Koruması: DataProtection.Blobs yeni Azure Depolama API'lerini kullanıyor

Azure.Extensions.AspNetCore.DataProtection.BlobsAzure Depolama kitaplıklarına bağlıdır. Bu kitaplıklar derlemelerini, paketlerini ve ad alanlarını yeniden adlandırdı. ASP.NET Core 3.0'dan başlayarak yeni Azure.Extensions.AspNetCore.DataProtection.BlobsAzure.Storage.ön ekli API'leri ve paketleri kullanır.

Azure Depolama API'leri hakkında sorular için kullanınhttps://github.com/Azure/azure-storage-net. Bu sorunla ilgili tartışma için bkz . dotnet/aspnetcore#19570.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Paket, NuGet paketine başvuruda bulundu WindowsAzure.Storage . Paket, NuGet paketine Microsoft.Azure.Storage.Blob başvurur.

Yeni davranış

Paket, NuGet paketine Azure.Storage.Blob başvurur.

Değişiklik nedeni

Bu değişiklik, önerilen Azure Depolama paketlerine geçiş yapılmasını sağlarAzure.Extensions.AspNetCore.DataProtection.Blobs.

ASP.NET Core 3.0 ile eski Azure Depolama API'lerini kullanmaya devam etmeniz gerekiyorsa WindowsAzure.Depolama veya Microsoft.Azure.Depolama paketine doğrudan bağımlılık ekleyin. Bu paket yeni Azure.Storage API'ler ile birlikte yüklenebilir.

Çoğu durumda yükseltme yalnızca deyimlerin yeni ad alanlarını kullanacak şekilde değiştirilmesini using içerir:

- 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;

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Barındırma: AspNetCoreModule V1, Windows Barındırma Paketi'nden kaldırıldı

ASP.NET Core 3.0'dan başlayarak, Windows Barındırma Paketi AspNetCoreModule (ANCM) V1'i içermez.

ANCM V2, ANCM OutOfProcess ile geriye dönük olarak uyumludur ve ASP.NET Core 3.0 uygulamalarıyla kullanılması önerilir.

Tartışma için bkz . dotnet/aspnetcore#7095.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

ANCM V1, Windows Barındırma Paketi'ne dahildir.

Yeni davranış

ANCM V1, Windows Barındırma Paketi'ne dahil değildir.

Değişiklik nedeni

ANCM V2, ANCM OutOfProcess ile geriye dönük olarak uyumludur ve ASP.NET Core 3.0 uygulamalarıyla kullanılması önerilir.

ASP.NET Core 3.0 uygulamalarıyla ANCM V2 kullanın.

ANCM V1 gerekiyorsa, ASP.NET Core 2.1 veya 2.2 Windows Barındırma Paketi kullanılarak yüklenebilir.

Bu değişiklik, aşağıdaki ASP.NET Core 3.0 uygulamalarını bozar:

  • ANCM V1'i ile <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>kullanmayı açıkça kabul etti.
  • ile özel bir web.config dosyası oluşturun <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Barındırma: Genel konak Başlangıç oluşturucu eklemeyi kısıtlar

Genel konağın sınıf oluşturucu eklemesi için Startup desteklediği türler yalnızca , IWebHostEnvironmentve IConfiguration'dırIHostEnvironment. kullanan WebHost uygulamalar etkilenmez.

Açıklama değiştirildi

ASP.NET Core 3.0'a başlamadan önce, oluşturucu ekleme sınıfın oluşturucusunda Startup rastgele türler için kullanılabilir. ASP.NET Core 3.0'da web yığını genel konak kitaplığına yeniden birleştirilmişti. Değişikliği şablonların Program.cs dosyasında görebilirsiniz:

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 uygulamayı derlemek için bir bağımlılık ekleme (DI) kapsayıcısı kullanır. WebHost iki kapsayıcı kullanır: biri konak için, diğeri uygulama için. Sonuç olarak, Startup oluşturucu artık özel hizmet eklemeyi desteklemez. Yalnızca IHostEnvironment, IWebHostEnvironmentve IConfiguration eklenebilir. Bu değişiklik, tek bir hizmetin yinelenen oluşturulması gibi DI sorunlarını önler.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Bu değişiklik, web yığınını genel konak kitaplığına yeniden eklemenin bir sonucudur.

Hizmetleri yöntem imzasına Startup.Configure ekleyin. Örneğin:

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

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Barındırma: IIS işlem dışı uygulamalar için HTTPS yeniden yönlendirme etkinleştirildi

IIS aracılığıyla barındırmaya yönelik ASP.NET Çekirdek Modülü'nin (ANCM) 13.0.19218.0 sürümü, ASP.NET Core 3.0 ve 2.2 uygulamaları için mevcut bir HTTPS yeniden yönlendirme özelliğini etkinleştirir.

Tartışma için bkz . dotnet/AspNetCore#15243.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

ASP.NET Core 2.1 proje şablonu ilk olarak ve UseHstsgibi UseHttpsRedirection HTTPS ara yazılım yöntemleri için destek sunms. Geliştirme aşamasındaki uygulamalar varsayılan 443 bağlantı noktasını kullanmadığından HTTPS yeniden yönlendirmesinin etkinleştirilmesi yapılandırmanın eklenmesini gerektiriyor. HTTP Strict Transport Security (HSTS) yalnızca istek zaten HTTPS kullanıyorsa etkindir. Localhost varsayılan olarak atlanır.

Yeni davranış

ASP.NET Core 3.0'da IIS HTTPS senaryosu geliştirildi. Geliştirme ile bir uygulama sunucunun HTTPS bağlantı noktalarını bulabilir ve UseHttpsRedirection varsayılan olarak çalışabilir. İşlem içi bileşen, işlem içi kitaplığın IServerAddresses çerçeveyle sürümü oluşturulduğundan yalnızca ASP.NET Core 3.0 uygulamalarını etkileyen özelliğiyle bağlantı noktası bulmayı başardı. ortam değişkenini otomatik olarak eklemek ASPNETCORE_HTTPS_PORT için işlem dışı bileşen değiştirildi. İşlem dışı bileşen genel olarak paylaşıldığından, bu değişiklik hem ASP.NET Core 2.2 hem de 3.0 uygulamalarını etkiledi. ASP.NET Core 2.1 uygulamaları varsayılan olarak ANCM'nin önceki bir sürümünü kullandıklarından etkilenmez.

Önceki davranış, ASP.NET Core 3.0.1 ve 3.1.0 Önizleme 3'te değiştirildiğinden, ASP.NET Core 2.x'teki davranış değişikliklerini tersine çevirebilirsiniz. Bu değişiklikler yalnızca IIS işlem dışı uygulamaları etkiler.

Yukarıda açıklandığı gibi, ASP.NET Core 3.0.0'ı yüklemek, ASP.NET Core 2.x uygulamalarında ara yazılımı etkinleştirmenin UseHttpsRedirection de yan etkisine sahipti. ASP.NET Core 3.0.1 ve 3.1.0 Preview 3'teki ANCM'de, yüklemenin artık ASP.NET Core 2.x uygulamaları üzerinde bu etkiye sahip olmayacağı bir değişiklik yapıldı. ANCM'nin ASPNETCORE_HTTPS_PORT ASP.NET Core 3.0.0'da doldurduğunu ortam değişkeni, ASP.NET Core 3.0.1 ve 3.1.0 Önizleme 3'te olarak değiştirildi ASPNETCORE_ANCM_HTTPS_PORT . UseHttpsRedirection ayrıca bu sürümlerde hem yeni hem de eski değişkenleri anlamak için güncelleştirildi. ASP.NET Core 2.x güncelleştirilmeyecek. Sonuç olarak, varsayılan olarak önceki devre dışı kalma davranışına geri döner.

Değişiklik nedeni

Geliştirilmiş ASP.NET Core 3.0 işlevselliği.

Tüm istemcilerin HTTPS kullanmasını istiyorsanız herhangi bir eylem gerekmez. Bazı istemcilerin HTTP kullanmasına izin vermek için aşağıdaki adımlardan birini uygulayın:

  • Projenizin Startup.Configure yöntemindeki UseHttpsRedirection ve UseHsts çağrılarını kaldırın ve uygulamayı yeniden dağıtın.

  • web.config dosyanızda ortam değişkenini ASPNETCORE_HTTPS_PORT boş bir dize olarak ayarlayın. Bu değişiklik, uygulamayı yeniden dağıtmadan doğrudan sunucuda gerçekleşebilir. Örneğin:

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

UseHttpsRedirection yine de olabilir:

  • Ortam değişkenini uygun bağlantı noktası numarasına ayarlayarak ASPNETCORE_HTTPS_PORT (çoğu üretim senaryosunda 443) ASP.NET Core 2.x'te el ile etkinleştirildi.
  • boş bir dize değeriyle tanımlanarak ASPNETCORE_ANCM_HTTPS_PORT ASP.NET Core 3.x'te devre dışı bırakıldı. Bu değer, önceki ASPNETCORE_HTTPS_PORT örnekle aynı şekilde ayarlanır.

ASP.NET Core 3.0.0 uygulamalarını çalıştıran makinelerin, ASP.NET Core 3.1.0 Preview 3 ANCM'yi yüklemeden önce ASP.NET Core 3.0.1 çalışma zamanını yüklemesi gerekir. Bunun yapılması, ASP.NET Core 3.0 uygulamaları için beklendiği gibi çalışmaya devam etmesini sağlar UseHttpsRedirection .

Azure Uygulaması Hizmeti'nde ANCM, genel yapısı nedeniyle çalışma zamanından ayrı bir zamanlamaya dağıtılır. ANCM, ASP.NET Core 3.0.1 ve 3.1.0 dağıtıldıktan sonra bu değişikliklerle Azure'a dağıtıldı.

Kategori

ASP.NET Core

Etkilenen API’ler

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Barındırma: IHostingEnvironment ve IApplicationLifetime türleri eski olarak işaretlendi ve değiştirildi

Mevcut IHostingEnvironment ve IApplicationLifetime türleri değiştirmek için yeni türler kullanıma sunulmuştur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

ve'den Microsoft.Extensions.HostingMicrosoft.AspNetCore.Hostingiki farklı IHostingEnvironment ve IApplicationLifetime türü vardı.

Yeni davranış

Eski türler eski olarak işaretlendi ve yeni türlerle değiştirildi.

Değişiklik nedeni

Microsoft.Extensions.Hosting ASP.NET Core 2.1'de kullanıma sunulduğunda ve gibi IHostingEnvironmentIApplicationLifetime bazı türler uygulamasından Microsoft.AspNetCore.Hostingkopyalanmıştır. Bazı ASP.NET Core 3.0 değişiklikleri, uygulamaların hem hem Microsoft.AspNetCore.Hosting de ad alanlarını içermesine Microsoft.Extensions.Hosting neden olur. Bu yinelenen türlerin herhangi bir kullanımı, her iki ad alanına da başvurulduğunda "belirsiz başvuru" derleyici hatasına neden olur.

Eski türlerin tüm kullanımları aşağıdaki gibi yeni tanıtılan türlerle değiştirildi:

Eski türler (uyarı):

Yeni türler:

Yeni IHostEnvironmentIsDevelopment ve IsProduction uzantı yöntemleri ad alanındadır Microsoft.Extensions.Hosting . Bu ad alanının projenize eklenmesi gerekebilir.

Kategori

ASP.NET Core

Etkilenen API’ler

Barındırma: ObjectPoolProvider WebHostBuilder bağımlılıklarından kaldırıldı

ASP.NET Core'un oyun için daha fazla ödeme yapmasının bir parçası olarak, ObjectPoolProvider ana bağımlılık kümesinden kaldırıldı. Bağlı olan ObjectPoolProvider belirli bileşenler artık bunları kendileri ekliyor.

Tartışma için bkz . dotnet/aspnetcore#5944.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

WebHostBuilderObjectPoolProvider, DI kapsayıcısında varsayılan olarak sağlar.

Yeni davranış

WebHostBuilder artık DI kapsayıcısında varsayılan olarak sağlamaz ObjectPoolProvider .

Değişiklik nedeni

Bu değişiklik, ASP.NET Core'un oyun için daha fazla ödeme yapmasını sağlamak için yapılmıştır.

Bileşeniniz gerektiriyorsa ObjectPoolProvider, aracılığıyla bağımlılıklarınıza IServiceCollectioneklenmesi gerekir.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

HTTP: VarsayılanHttpContext genişletilebilirliği kaldırıldı

ASP.NET Core 3.0 performans geliştirmelerinin bir parçası olarak genişletilebilirliği DefaultHttpContext kaldırıldı. sınıfı artık sealedşeklindedir. Daha fazla bilgi için bkz . dotnet/aspnetcore#6504.

Birim testleriniz kullanıyorsa Mock<DefaultHttpContext>veya new DefaultHttpContext() kullanınMock<HttpContext>.

Tartışma için bkz . dotnet/aspnetcore#6534.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Sınıflar' dan DefaultHttpContexttüretilebilir.

Yeni davranış

Sınıflar'dan DefaultHttpContexttüretemez.

Değişiklik nedeni

Genişletilebilirlik başlangıçta havuzuna izin HttpContextvermek için sağlandı, ancak gereksiz karmaşıklığı ortaya çıkardı ve diğer iyileştirmeleri engellendi.

Birim testlerinde kullanıyorsanız Mock<DefaultHttpContext> , bunun yerine kullanmaya Mock<HttpContext> başlayın.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames sabitleri salt okunur statik olarak değiştirildi

ASP.NET Core 3.0 Preview 5'ten başlayarak içindeki Microsoft.Net.Http.Headers.HeaderNames alanlar olarak conststatic readonlydeğiştirildi.

Tartışma için bkz . dotnet/aspnetcore#9514.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Bu alanlar eskiden şeklindedir const.

Yeni davranış

Bu alanlar artık static readonlyşeklindedir.

Değişiklik nedeni

Değişiklik:

  • Değerlerin derleme sınırları boyunca katıştırılmasını engeller ve gerektiğinde değer düzeltmelerine olanak sağlar.
  • Daha hızlı başvuru eşitliği denetimlerini etkinleştirir.

3.0'a karşı yeniden derleme. Aşağıdaki yollarla bu alanları kullanan kaynak kodu artık bunu yapamaz:

  • Öznitelik bağımsız değişkeni olarak
  • Deyiminde switch olduğu case gibi
  • Başka bir tane tanımlarken const

Hataya neden olan değişikliği geçici olarak çözmek için, kendi tanımlı üst bilgi adı sabitlerini veya dize değişmez değerlerini kullanmaya geçin.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Yanıt gövdesi altyapısı değişiklikleri

HTTP yanıt gövdesini desteklemek için altyapı değişti. Doğrudan kullanıyorsanız HttpResponse kod değişikliği yapmanız gerekmez. sarmalarken, değiştirirken veya erişirken HttpResponse.BodyHttpContext.Featuresdaha fazla bilgi edinin.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

HTTP yanıt gövdesiyle ilişkilendirilmiş üç API vardı:

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

Yeni davranış

değerini değiştirirsenizHttpResponse.Body, beklenen tüm API'ler için varsayılan uygulamaları sağlamak üzere kullanarak StreamResponseBodyFeature değerinin tamamını IHttpResponseBodyFeature verilen akışınızın etrafındaki bir sarmalayıcıyla değiştirir. Özgün akışın geri ayarlanması bu değişikliği geri alır.

Değişiklik nedeni

Motivasyon, yanıt gövdesi API'lerini tek bir yeni özellik arabiriminde birleştirmektir.

Daha önce , veya IHttpBufferingFeaturekullanırken kullandığınız IHttpResponseFeature.Bodyyeri kullanınIHttpResponseBodyFeature. IHttpSendFileFeature

Kategori

ASP.NET Core

Etkilenen API’ler

SameSite , bazı Siteler Arası İstek Sahteciliği (CSRF) saldırılarını azaltmaya yardımcı olabilecek tanımlama bilgileri için bir seçenektir. Bu seçenek ilk kez sunulduğunda, çeşitli ASP.NET Çekirdek API'lerinde tutarsız varsayılanlar kullanıldı. Tutarsızlık kafa karıştırıcı sonuçlara yol açtı. ASP.NET Core 3.0 itibarıyla bu varsayılanlar daha iyi hizalanır. Bu özelliği bileşen bazında kabul etmeniz gerekir.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Benzer ASP.NET Çekirdek API'leri farklı varsayılan SameSiteMode değerler kullandı. ve içinde, varsayılan olarak ve olarak varsayılan SameSiteMode.None olarak ve SameSiteMode.Laxolan bir tutarsızlık örneği görülürHttpResponse.Cookies.Append(String, String).HttpResponse.Cookies.Append(String, String, CookieOptions)

Yeni davranış

Etkilenen tüm API'ler varsayılan olarak olarak kullanılır SameSiteMode.None.

Değişiklik nedeni

Varsayılan değer, kabul etme özelliği olacak şekilde SameSite değiştirildi.

Tanımlama bilgilerini yayan her bileşenin senaryolarına uygun olup olmadığını SameSite belirlemesi gerekir. Etkilenen API'leri kullanımınızı gözden geçirin ve gerektiğinde yeniden yapılandırın SameSite .

Kategori

ASP.NET Core

Etkilenen API’ler

HTTP: Zaman uyumlu GÇ tüm sunucularda devre dışı bırakıldı

ASP.NET Core 3.0'dan başlayarak, zaman uyumlu sunucu işlemleri varsayılan olarak devre dışı bırakılır.

Açıklama değiştirildi

AllowSynchronousIO, ve Stream.Flushgibi HttpRequest.Body.ReadHttpResponse.Body.Writezaman uyumlu GÇ API'lerini etkinleştiren veya devre dışı getiren her sunucuda bir seçenektir. Bu API'ler uzun zamandır iş parçacığı açlığı ve uygulama kilitlenmesi kaynağı olmuştur. ASP.NET Core 3.0 Preview 3 sürümünden başlayarak, bu zaman uyumlu işlemler varsayılan olarak devre dışı bırakılır.

Etkilenen sunucular:

  • Kestrel
  • HttpSys
  • IIS işlemde
  • TestServer

Aşağıdakine benzer hatalar bekleyebilirsiniz:

  • 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.

Her sunucunun bu davranışı denetleyebilen bir AllowSynchronousIO seçeneği vardır ve hepsi için varsayılan seçenek şudur false: .

Davranış, geçici bir azaltma olarak istek başına temelinde de geçersiz kılınabilir. Örneğin:

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

içinde zaman uyumlu API'yi çağıran bir TextWriter veya başka bir akışla ilgili sorun yaşıyorsanız, bunun yerine yeni DisposeAsync API'yi Disposeçağırın.

Tartışma için bkz . dotnet/aspnetcore#7644.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

HttpRequest.Body.Read, HttpResponse.Body.Writeve Stream.Flush varsayılan olarak izin verildi.

Yeni davranış

Bu zaman uyumlu API'lere varsayılan olarak izin verilmez:

Aşağıdakine benzer hatalar bekleyebilirsiniz:

  • 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.

Değişiklik nedeni

Bu zaman uyumlu API'ler uzun zamandır iş parçacığı açlığı ve uygulama kilitlenmesi kaynağı olmuştur. ASP.NET Core 3.0 Preview 3 sürümünden itibaren zaman uyumlu işlemler varsayılan olarak devre dışı bırakılır.

Yöntemlerin zaman uyumsuz sürümlerini kullanın. Davranış, geçici bir azaltma olarak istek başına temelinde de geçersiz kılınabilir.

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

Kategori

ASP.NET Core

Etkilenen API’ler

Kimlik: AddDefaultUI yöntemi aşırı yüklemesi kaldırıldı

ASP.NET Core 3.0'dan başlayarak IdentityBuilderUIExtensions.AddDefaultUI (IdentityBuilder,UIFramework) yöntemi aşırı yüklemesi artık mevcut değildir.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Bu değişiklik, statik web varlıkları özelliğinin benimsenmesinin bir sonucuydu.

İki bağımsız değişken alan aşırı yükleme yerine çağrısı IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) yapın. Bootstrap 3 kullanıyorsanız, proje dosyanızdaki bir <PropertyGroup> öğeye aşağıdaki satırı da ekleyin:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

ASP.NET Core

Etkilenen API’ler

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Kimlik: Kullanıcı arabiriminin varsayılan Bootstrap sürümü değiştirildi

ASP.NET Core 3.0'dan başlayarak Kimlik kullanıcı arabirimi varsayılan olarak Bootstrap'ın 4. sürümünü kullanır.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Yöntem services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); çağrısı ile aynıydı services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Yeni davranış

Yöntem services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); çağrısı, services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Değişiklik nedeni

Bootstrap 4, ASP.NET Core 3.0 zaman çerçevesi boyunca yayımlandı.

Varsayılan Kimlik kullanıcı arabirimini kullanıyorsanız ve aşağıdaki örnekte gösterildiği gibi bu Startup.ConfigureServices kullanıcı arabirimini eklediyseniz bu değişiklik sizi etkiler:

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

Aşağıdaki eylemlerden birini uygulayın:

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Kimlik: SignInAsync kimliği doğrulanmamış kimlik için özel durum oluşturur

Varsayılan olarak, SignInAsync içinde olduğu IsAuthenticatedfalsesorumlular / kimlikler için bir özel durum oluşturur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

SignInAsync içindeki kimlikler de dahil olmak üzere tüm sorumluları / kimlikleri IsAuthenticated kabul eder false.

Yeni davranış

Varsayılan olarak, SignInAsync içinde olduğu IsAuthenticatedfalsesorumlular / kimlikler için bir özel durum oluşturur. Bu davranışı gizlemeye ilişkin yeni bir bayrak var, ancak varsayılan davranış değişti.

Değişiklik nedeni

Bu sorumlular varsayılan olarak tarafından [Authorize] / RequireAuthenticatedUser()reddedildiği için eski davranış sorunluydu.

ASP.NET Core 3.0 Preview 6'da varsayılan olarak üzerinde AuthenticationOptionstrue bir RequireAuthenticatedSignIn bayrak vardır. Eski davranışı geri yüklemek için bu bayrağı olarak false ayarlayın.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Kimlik: SignInManager oluşturucu yeni parametreyi kabul ediyor

ASP.NET Core 3.0'dan başlayarak oluşturucuya SignInManager yeni IUserConfirmation<TUser> bir parametre eklendi. Daha fazla bilgi için bkz . dotnet/aspnetcore#8356.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Değişikliğin nedeni, Identity'de yeni e-posta /onay akışları için destek eklemekti.

El ile bir SignInManageroluşturursanız, sağlamak için bağımlılık ekleme işleminin IUserConfirmation bir uygulamasını sağlayın veya bu uygulamadan bir tane alın.

Kategori

ASP.NET Core

Etkilenen API’ler

SignInManager<TUser>

Kimlik: Kullanıcı arabirimi statik web varlıkları özelliğini kullanıyor

ASP.NET Core 3.0 statik bir web varlıkları özelliği kullanıma sunulmuştur ve Kimlik kullanıcı arabirimi bunu benimsemiştir.

Açıklama değiştirildi

Kimlik kullanıcı arabiriminin statik web varlıkları özelliğini benimsemesinin bir sonucu olarak:

  • Çerçeve seçimi, proje dosyanızdaki özelliği kullanılarak IdentityUIFrameworkVersion gerçekleştirilir.
  • Bootstrap 4, Kimlik kullanıcı arabirimi için varsayılan ui çerçevesidir. Bootstrap 3 kullanım ömrünün sonuna ulaştı ve desteklenen bir sürüme geçiş yapmayı düşünmelisiniz.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Kimlik kullanıcı arabirimi için varsayılan UI çerçevesi Bootstrap 3'dü. UI çerçevesi, içindeki Startup.ConfigureServicesyöntem çağrısına AddDefaultUI bir parametre kullanılarak yapılandırılabilir.

Yeni davranış

Kimlik kullanıcı arabirimi için varsayılan UI çerçevesi Bootstrap 4'dür. UI çerçevesi, yöntem çağrısı yerine AddDefaultUI proje dosyanızda yapılandırılmalıdır.

Değişiklik nedeni

Ui çerçevesi yapılandırmasının MSBuild'e taşınması için statik web varlıkları özelliğinin benimsenmesi gerekir. Hangi çerçevenin eklendiğine ilişkin karar çalışma zamanı kararı değil, derleme zamanı kararıdır.

Yeni Bootstrap 4 bileşenlerinin uyumlu olduğundan emin olmak için site kullanıcı arabiriminizi gözden geçirin. Gerekirse, Bootstrap 3'e geri dönmek için MSBuild özelliğini kullanın IdentityUIFrameworkVersion . özelliğini proje dosyanızdaki bir <PropertyGroup> öğeye ekleyin:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

ASP.NET Core

Etkilenen API’ler

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Bağlan bağdaştırıcıları kaldırıldı

"Pubternal" API'lerini 'a publictaşıma işleminin bir parçası olarak kestrel'den kaldırılmıştır IConnectionAdapter . Bağlan ion bağdaştırıcıları bağlantı ara yazılımıyla değiştiriliyor (ASP.NET Core işlem hattındaki HTTP ara yazılımına benzer, ancak alt düzey bağlantılar için). HTTPS ve bağlantı günlüğü, bağlantı bağdaştırıcılarından bağlantı ara yazılımına taşındı. Bu uzantı yöntemleri sorunsuz bir şekilde çalışmaya devam etmelidir, ancak uygulama ayrıntıları değişmiştir.

Daha fazla bilgi için bkz . dotnet/aspnetcore#11412. Tartışma için bkz . dotnet/aspnetcore#11475.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Kestrel genişletilebilirlik bileşenleri kullanılarak IConnectionAdapteroluşturulmuştur.

Yeni davranış

Kestrel genişletilebilirlik bileşenleri ara yazılım olarak oluşturulur.

Değişiklik nedeni

Bu değişiklik, daha esnek bir genişletilebilirlik mimarisi sağlamaya yöneliktir.

IConnectionAdapter Uygulamasını, burada gösterildiği gibi yeni ara yazılım desenini kullanacak şekilde dönüştürün.

Kategori

ASP.NET Core

Etkilenen API’ler

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

Kestrel: Boş HTTPS derlemesi kaldırıldı

Derleme Microsoft.AspNetCore.Server.Kestrel.Https kaldırıldı.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

ASP.NET Core 2.1'de içeriği Microsoft.AspNetCore.Server.Kestrel.Https öğesine Microsoft.AspNetCore.Server.Kestrel.Coretaşındı. Bu değişiklik, öznitelikler kullanılarak [TypeForwardedTo] hataya neden olmayan bir şekilde yapıldı.

  • 2.0'a başvuran Microsoft.AspNetCore.Server.Kestrel.Https kitaplıklar, tüm ASP.NET Core bağımlılıklarını 2.1 veya sonraki bir sürüme güncelleştirmelidir. Aksi takdirde, bir ASP.NET Core 3.0 uygulamasına yüklendiğinde bozulabilir.
  • ASP.NET Core 2.1 ve sonraki sürümleri hedefleyen uygulamalar ve kitaplıklar NuGet paketine Microsoft.AspNetCore.Server.Kestrel.Https yönelik tüm doğrudan başvuruları kaldırmalıdır.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Kestrel: Yeni koleksiyona taşınan römork üst bilgilerini isteme

Önceki sürümlerde Kestrel, istek gövdesi sonuna kadar okunduğunda istek üst bilgileri koleksiyonuna HTTP/1.1 öbekli fragman üst bilgileri eklemiş. Bu davranış, üst bilgiler ve fragmanlar arasındaki belirsizlikle ilgili endişelere neden oldu. Fragmanları yeni bir koleksiyona taşıma kararı alındı.

HTTP/2 istek fragmanları ASP.NET Core 2.2'de kullanılamıyordu ancak artık ASP.NET Core 3.0'daki bu yeni koleksiyonda da kullanılabilir.

Bu fragmanlara erişmek için yeni istek uzantısı yöntemleri eklendi.

İstek gövdesinin tamamı okunduktan sonra HTTP/1.1 fragmanları kullanılabilir.

HTTP/2 fragmanları istemciden alındıktan sonra kullanılabilir. İstemci, istek gövdesinin tamamı en azından sunucu tarafından arabelleğe alınana kadar fragmanları göndermez. Arabellek alanını boşaltmak için istek gövdesini okumanız gerekebilir. İstek gövdesini sonuna kadar okursanız fragmanlar her zaman kullanılabilir. Römorklar vücudun sonunu işaret eder.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

İstek fragman üst bilgileri koleksiyona HttpRequest.Headers eklenir.

Yeni davranış

İstek fragmanı üst bilgileri koleksiyonda HttpRequest.Headers yok. Bunlara erişmek için aşağıdaki HttpRequest uzantı yöntemlerini kullanın:

  • GetDeclaredTrailers() - Gövdeden sonra hangi fragmanların bekleneceğini listeleyen "Trailer" isteği üst bilgisini alır.
  • SupportsTrailers() - İsteğin römork üst bilgilerini almayı desteklenip desteklemediğini gösterir.
  • CheckTrailersAvailable() - İsteğin fragmanları destekleyip desteklemediğini ve okuma için uygun olup olmadığını belirler.
  • GetTrailer(string trailerName) - yanıttan istenen sondaki üst bilgiyi alır.

Değişiklik nedeni

Fragmanlar gRPC gibi senaryolarda önemli bir özelliktir. içindeki römorkların istek üst bilgilerine birleştirilmesi kullanıcılar için kafa karıştırıcıydı.

Römorklara erişmek için üzerinde HttpRequest römorkla ilgili uzantı yöntemlerini kullanın.

Kategori

ASP.NET Core

Etkilenen API’ler

HttpRequest.Headers

Kerkenez: Taşıma soyutlamaları kaldırıldı ve genel kullanıma açık hale getirildi

"Pubternal" API'lerinden uzaklaşmanın bir parçası olarak Kestrel aktarım katmanı API'leri kitaplıkta Microsoft.AspNetCore.Connections.Abstractions genel arabirim olarak kullanıma sunulur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

  • Taşımayla ilgili soyutlamalar kitaplıkta Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions mevcuttur.
  • Özellik ListenOptions.NoDelay kullanılabilir durumdaydı.

Yeni davranış

  • Arabirim IConnectionListener , kitaplıktan Microsoft.AspNetCore.Connections.Abstractions en çok kullanılan işlevselliği kullanıma sunma amacıyla kitaplıkta ...Transport.Abstractions tanıtıldı.
  • NoDelay artık aktarım seçeneklerinde (LibuvTransportOptions ve SocketTransportOptions) kullanılabilir.
  • SchedulingMode artık kullanılamıyor.

Değişiklik nedeni

ASP.NET Core 3.0 , "pubternal" API'lerinden uzaklaştı.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Yerelleştirme: ResourceManagerWithCultureStringLocalizer ve WithCulture eski olarak işaretlendi

ResourceManagerWithCultureStringLocalizer sınıfı ve WithCulture arabirim üyesi genellikle, özellikle kendi IStringLocalizer uygulamalarını oluştururken yerelleştirme kullanıcıları için karışıklığın kaynaklarıdır. Bu öğeler kullanıcıya örneğin IStringLocalizer "dil başına, kaynak başına" olduğu izlenimini verir. Gerçekte, örnekler yalnızca "kaynak başına" olmalıdır. Aranan dil, yürütme zamanında tarafından CultureInfo.CurrentUICulture belirlenir. Karışıklığın kaynağını ortadan kaldırmak için API'ler ASP.NET Core 3.0 Preview 3'te kullanım dışı olarak işaretlendi. API'ler gelecek bir sürümde kaldırılacaktır.

Bağlam için bkz . dotnet/aspnetcore#3324. Tartışma için bkz . dotnet/aspnetcore#7756.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Yöntemler olarak Obsoleteişaretlenmedi.

Yeni davranış

Yöntemler olarak işaretlenir Obsolete.

Değişiklik nedeni

API'ler, önerilmez bir kullanım örneğini temsil etti. Yerelleştirme tasarımıyla ilgili karışıklıklar oluştu.

Bunun yerine kullanılması ResourceManagerStringLocalizer önerilir. Kültürün tarafından ayarlanmasına CurrentCultureizin verin. Bu bir seçenek değilse ResourceManagerWithCultureStringLocalizer'ın bir kopyasını oluşturun ve kullanın.

Kategori

ASP.NET Core

Etkilenen API’ler

Günlüğe kaydetme: DebugLogger sınıfı dahili hale getirildi

Core 3.0'ın DebugLoggerASP.NET önce erişim değiştiricisi idi public. ASP.NET Core 3.0'da erişim değiştirici olarak değiştirildi internal.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Değişiklik şu şekilde yapılıyor:

  • gibi ConsoleLoggerdiğer günlükçü uygulamalarıyla tutarlılığı zorunlu tutma.
  • API yüzeyini azaltın.

AddDebugILoggingBuilder Hata ayıklama günlüğünü etkinleştirmek için uzantı yöntemini kullanın. DebugLoggerProvider aynı zamanda hizmetin el ile kaydedilmesi gerektiğinde de public kullanılabilir.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Denetleyici eylem adlarından kırpılmış zaman uyumsuz sonek

dotnet/aspnetcore#4849 adresinin bir parçası olarak, ASP.NET Core MVC eylem adlarından soneki Async varsayılan olarak keser. ASP.NET Core 3.0'dan başlayarak bu değişiklik hem yönlendirmeyi hem de bağlantı oluşturmayı etkiler.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Aşağıdaki ASP.NET Core MVC denetleyicisini göz önünde bulundurun:

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

Eylem aracılığıyla Product/ListAsyncyönlendirilebilir. Bağlantı oluşturma için son ekin Async belirtilmesi gerekir. Örneğin:

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

Yeni davranış

ASP.NET Core 3.0'da eylem aracılığıyla Product/Listyönlendirilebilir. Bağlantı oluşturma kodu son Async eki atlamalıdır. Örneğin:

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

Bu değişiklik özniteliği kullanılarak [ActionName] belirtilen adları etkilemez. yeni davranış, içinde Startup.ConfigureServicesolarak ayarlanarak MvcOptions.SuppressAsyncSuffixInActionNamesfalse devre dışı bırakılabilir:

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

Değişiklik nedeni

Kural gereği, zaman uyumsuz .NET yöntemleri ile Asyncson eklenmiştir. Ancak, bir yöntem bir MVC eylemi tanımladığında, soneki Async kullanmak istenmeyen bir durum olur.

Uygulamanız adın Async sonekini koruyan MVC eylemlerine bağımlıysa aşağıdaki risk azaltmalarından birini seçin:

  • [ActionName] Özgün adı korumak için özniteliğini kullanın.
  • içinde olarak ayarlayarak MvcOptions.SuppressAsyncSuffixInActionNames yeniden adlandırmayı falseStartup.ConfigureServicestamamen devre dışı bırakın:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

MVC: JsonResult Microsoft.AspNetCore.Mvc.Core'a taşındı

JsonResult derlemeye Microsoft.AspNetCore.Mvc.Core taşındı. Bu tür, Microsoft.AspNetCore.Mvc.Formatters.Json dosyasında tanımlanmıştır. Kullanıcıların çoğunluğu için bu sorunu gidermek için öğesine Microsoft.AspNetCore.Mvc.Formatters.Json bir derleme düzeyi [TypeForwardedTo] özniteliği eklendi. Üçüncü taraf kitaplıkları kullanan uygulamalar sorunlarla karşılaşabilir.

Sürüm kullanıma sunulmuştur

3.0 Önizleme 6

Eski davranış

2.2 tabanlı kitaplık kullanan bir uygulama başarıyla derlensin.

Yeni davranış

2.2 tabanlı kitaplık kullanan bir uygulama derlemede başarısız oluyor. Aşağıdaki metnin varyasyonunu içeren bir hata sağlanır:

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'

Bu tür bir sorun örneği için bkz . dotnet/aspnetcore#7220.

Değişiklik nedeni

aspnet/Announcements#325'te açıklandığı gibi ASP.NET Core'un bileşiminde platform düzeyinde değişiklikler.

2.2 sürümünde derlenen kitaplıkların Microsoft.AspNetCore.Mvc.Formatters.Json tüm tüketiciler için sorunu gidermek için yeniden derlenmiş olması gerekebilir. Etkileniyorsa, kitaplık yazarına başvurun. ASP.NET Core 3.0'ı hedeflemek için kitaplığın yeniden derlenmesini isteyin.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Ön derleme aracı kullanım dışı bırakıldı

ASP.NET Core 1.1'de Razor dosyalarının Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (.cshtml dosyaları) yayımlanma zamanı derlemesi için destek eklemek için (MVC ön derleme aracı) paketi kullanıma sunulmuştur. ASP.NET Core 2.1'de Razor SDK'sı, ön derleme aracının özelliklerine göre genişletildi. Razor SDK'sı, Razor dosyalarını derleme ve yayımlama zamanı derleme desteği ekledi. SDK, uygulama başlatma zamanında geliştirirken derleme zamanında .cshtml dosyalarının doğruluğunu doğrular. Razor SDK varsayılan olarak açıktır ve kullanmaya başlamak için herhangi bir hareket gerekmez.

ASP.NET Core 3.0'da ASP.NET Core 1.1 dönem MVC ön derleme aracı kaldırıldı. Önceki paket sürümleri, düzeltme eki sürümünde önemli hata ve güvenlik düzeltmeleri almaya devam edecektir.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Paket, Microsoft.AspNetCore.Mvc.Razor.ViewCompilation MVC Razor görünümlerini önceden derlemek için kullanıldı.

Yeni davranış

Razor SDK'sı bu işlevselliği yerel olarak destekler. Paket Microsoft.AspNetCore.Mvc.Razor.ViewCompilation artık güncelleştirilmedi.

Değişiklik nedeni

Razor SDK daha fazla işlevsellik sağlar ve derleme zamanında .cshtml dosyalarının doğruluğunu doğrular. SDK ayrıca uygulama başlatma süresini de geliştirir.

ASP.NET Core 2.1 veya sonraki bir sürümü kullananlar için Razor SDK'sında ön derleme için yerel desteği kullanacak şekilde güncelleştirin. Hatalar veya eksik özellikler Razor SDK'sına geçişi engelliyorsa dotnet/aspnetcore adresinde bir sorun açın.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

MVC: "Pubternal" türleri dahili olarak değiştirildi

ASP.NET Core 3.0'da, MVC'deki tüm "pubternal" türleri desteklenen bir ad alanında veya internal uygun şekilde public güncelleştirildi.

Açıklama değiştirildi

ASP.NET Core'da "pubternal" türleri olarak public bildirilir ancak -suffixed ad alanında .Internalbulunur. Bu türler olsa da public, destek ilkesi yoktur ve hataya neden olan değişikliklere tabidir. Ne yazık ki, bu türlerin yanlışlıkla kullanılması yaygın olarak görülür ve bu da bu projelerde hataya neden olan değişikliklere ve çerçeveyi koruma becerisini sınırlamaya neden olmuştur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

MVC'deki bazı türler bir .Internal ad alanındaydıpublic. Bu türlerin destek ilkesi yoktu ve hataya neden olan değişikliklere tabiydi.

Yeni davranış

Bu tür türlerin tümü desteklenen bir ad alanında olacak public şekilde güncelleştirilir veya olarak internalişaretlenir.

Değişiklik nedeni

"Pubternal" türlerinin yanlışlıkla kullanılması yaygın olarak görülür ve bu da bu projelerde değişikliklerin bozulmasına ve çerçevenin korunmasının sınırlandırılmasıyla sonuçlanır.

Gerçekten public olan ve desteklenen yeni bir ad alanına taşınan türleri kullanıyorsanız, başvurularınızı yeni ad alanlarıyla eşleşecek şekilde güncelleştirin.

olarak internalişaretlenmiş türler kullanıyorsanız bir alternatif bulmanız gerekir. Daha önce "pubternal" türleri genel kullanım için hiçbir zaman desteklenmedi. Bu ad alanında uygulamalarınız için kritik öneme sahip belirli türler varsa dotnet/aspnetcore adresine bir sorun bildirin. İstenen türleri publicoluşturmak için dikkat edilmesi gereken noktalar bulunabilir.

Kategori

ASP.NET Core

Etkilenen API’ler

Bu değişiklik aşağıdaki ad alanları içindeki türleri içerir:

  • 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: Web API uyumluluğu dolgusu kaldırıldı

ASP.NET Core 3.0'dan Microsoft.AspNetCore.Mvc.WebApiCompatShim başlayarak paket artık kullanılamaz.

Açıklama değiştirildi

Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) paketi, mevcut Web API'si uygulamalarının ASP.NET Core'a geçirilmesini kolaylaştırmak için ASP.NET Core'da ASP.NET 4.x Web API 2 ile kısmi uyumluluk sağlar. Ancak WebApiCompatShim kullanan uygulamalar, son ASP.NET Core sürümlerinde api ile ilgili özelliklerin gönderiminden yararlanamaz. Bu özellikler arasında geliştirilmiş Open API belirtimi oluşturma, standart hata işleme ve istemci kodu oluşturma yer alır. 3.0'daki API çalışmalarına daha iyi odaklanmak için WebApiCompatShim kaldırıldı. WebApiCompatShim kullanan mevcut uygulamalar daha [ApiController] yeni modele geçirilmelidir.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Web API uyumluluk dolgusu bir geçiş aracıydı. Kullanıcı erişimini ASP.NET Core'a eklenen yeni işlevlerle kısıtlar.

Bu dolgunun kullanımını kaldırın ve doğrudan ASP.NET Core'daki benzer işlevlere geçin.

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API kaldırıldı

RazorTemplateEngine API kaldırıldı ve ile Microsoft.AspNetCore.Razor.Language.RazorProjectEnginedeğiştirildi.

Tartışma için bkz. GitHub sorunu dotnet/aspnetcore#25215.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Razor dosyalarını ayrıştırmak ve oluşturmak için bir şablon altyapısı oluşturulabilir ve kullanılabilir.

Yeni davranış

RazorProjectEngine razor dosyaları için ayrıştırma ve kod oluşturma ile aynı türde bilgiler RazorTemplateEngine oluşturulabilir ve sağlanabilir. RazorProjectEngine ayrıca ek yapılandırma düzeyleri sağlar.

Değişiklik nedeni

RazorTemplateEngine mevcut uygulamalarla çok sıkı bir şekilde eşlendi. Bu sıkı bağlama, Razor ayrıştırma/oluşturma işlem hattını düzgün bir şekilde yapılandırmaya çalışırken daha fazla soruya yol açtı.

yerine RazorTemplateEnginekullanınRazorProjectEngine. Aşağıdaki örnekleri göz önünde bulundurun.

RazorProjectEngine oluşturma ve yapılandırma
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 dosyası için kod oluşturma
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();

Kategori

ASP.NET Core

Etkilenen API’ler

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Çalışma zamanı derlemesi bir pakete taşındı

Razor görünümlerinin ve Razor Sayfalarının çalışma zamanı derleme desteği ayrı bir pakete taşındı.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Çalışma zamanı derlemesi ek paketlere gerek kalmadan kullanılabilir.

Yeni davranış

İşlev, Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation paketine taşındı.

Aşağıdaki API'ler daha önce içinde Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions çalışma zamanı derlemesini desteklemek için kullanılabilirdi. API'ler artık aracılığıyla Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptionskullanılabilir.

  • RazorViewEngineOptions.FileProviders şimdi MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences şimdi MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Ayrıca, Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange kaldırılmıştır. Dosya değişiklikleri üzerinde yeniden derleme, pakete başvurarak Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation varsayılan olarak etkinleştirilir.

Değişiklik nedeni

Roslyn'de ASP.NET Core paylaşılan çerçeve bağımlılığını kaldırmak için bu değişiklik gerekliydi.

Razor dosyalarının çalışma zamanı derlemesi veya yeniden derlenmesi gereken uygulamalar aşağıdaki adımları izlemelidir:

  1. Pakete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation bir başvuru ekleyin.

  2. projenin Startup.ConfigureServices yöntemini çağrısı içerecek şekilde AddRazorRuntimeCompilationgüncelleştirin. Örneğin:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategori

ASP.NET Core

Etkilenen API’ler

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Oturum durumu: Eski API'ler kaldırıldı

Oturum tanımlama bilgilerini yapılandırmaya yönelik eski API'ler kaldırıldı. Daha fazla bilgi için bkz . aspnet/Announcements#257.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Bu değişiklik, tanımlama bilgileri kullanan özellikleri yapılandırmak için API'ler arasında tutarlılığı zorunlu tutar.

Kaldırılan API'lerin kullanımını yeni değiştirmelerine geçirin. aşağıdaki örneği göz Startup.ConfigureServicesönünde bulundurun:

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;
    });
}

Kategori

ASP.NET Core

Etkilenen API’ler

Paylaşılan çerçeve: Derlemeler Microsoft.AspNetCore.App kaldırıldı

ASP.NET Core 3.0'dan başlayarak, ASP.NET Core paylaşılan çerçevesi (Microsoft.AspNetCore.App) yalnızca Microsoft tarafından tamamen geliştirilen, desteklenen ve hizmet veren birinci taraf derlemeleri içerir.

Açıklama değiştirildi

Değişikliği, ASP.NET Core "platformu" için sınırların yeniden tanımlanması olarak düşünün. Paylaşılan çerçeve GitHub aracılığıyla herkes tarafından kaynak olarak derlenebilir ve uygulamalarınıza .NET Core paylaşılan çerçevelerinin mevcut avantajlarını sunmaya devam edecektir. Bazı avantajlar arasında daha küçük dağıtım boyutu, merkezi düzeltme eki uygulama ve daha hızlı başlatma süresi bulunur.

Değişikliğin bir parçası olarak, bazı önemli hataya neden olan değişiklikler içinde Microsoft.AspNetCore.Appkullanıma sunulmuştur.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Proje dosyasındaki bir <PackageReference> öğe aracılığıyla başvuruda bulunılan Microsoft.AspNetCore.App projeler.

Ayrıca, Microsoft.AspNetCore.App aşağıdaki alt bileşenleri içerir:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (ile ön ekli Microsoft.EntityFrameworkCore.derlemeler)
  • Roslyn (Microsoft.CodeAnalysis)

Yeni davranış

başvurusu Microsoft.AspNetCore.App artık proje dosyasında bir <PackageReference> öğe gerektirmez. .NET Core SDK'sı, öğesinin kullanımının <PackageReference>yerini alan adlı <FrameworkReference>yeni bir öğeyi destekler.

Daha fazla bilgi için bkz . dotnet/aspnetcore#3612.

Entity Framework Core, NuGet paketleri olarak sunulur. Bu değişiklik, gönderim modelini .NET üzerindeki diğer tüm veri erişim kitaplıklarıyla uyumlu hale getirir. Çeşitli .NET platformlarını desteklerken yenilik yapmaya devam etmek için Entity Framework Core'a en basit yolu sağlar. Entity Framework Core'un paylaşılan çerçeve dışına taşınması, Microsoft tarafından geliştirilen, desteklenen ve hizmet sağlanabilir bir kitaplık olarak durumunu etkilemez. .NET Core destek ilkesi bunu kapsamaya devam eder.

Json.NET ve Entity Framework Core, ASP.NET Core ile çalışmaya devam eder. Ancak paylaşılan çerçeveye dahil edilmeyecektir.

Daha fazla bilgi için bkz . .NET Core 3.0'da JSON'un geleceği. Ayrıca paylaşılan çerçeveden kaldırılan ikili dosyaların tam listesine bakın.

Değişiklik nedeni

Bu değişiklik, NuGet paketleri ve paylaşılan çerçeveler arasındaki yinelemeyi basitleştirir Microsoft.AspNetCore.App ve azaltır.

Bu değişikliğin motivasyonu hakkında daha fazla bilgi için bu blog gönderisine bakın.

ASP.NET Core 3.0'dan başlayarak, projelerin içinde derlemeleri NuGet paketleri olarak kullanması Microsoft.AspNetCore.App artık gerekli değildir. ASP.NET Core paylaşılan çerçevesinin hedeflenmesi ve kullanımını basitleştirmek için, ASP.NET Core 1.0 artık üretilmeyen birçok NuGet paketi gönderildi. Bu paketlerin sağladığı API'ler için kullanarak <FrameworkReference>Microsoft.AspNetCore.Appuygulamalar tarafından kullanılabilir. Yaygın API örnekleri arasında Kestrel, MVC ve Razor sayılabilir.

Bu değişiklik, ASP.NET Core 2.x'te aracılığıyla Microsoft.AspNetCore.App başvuruda bulunılan tüm ikili dosyalar için geçerli değildir. Önemli özel durumlar şunlardır:

  • Microsoft.Extensions .NET Standard'ı hedeflemeye devam eden kitaplıklar NuGet paketleri olarak kullanılabilir (bkz https://github.com/dotnet/extensions. ).
  • ASP.NET Core ekibi tarafından üretilen ve öğesinin Microsoft.AspNetCore.Appparçası olmayan API'ler. Örneğin, aşağıdaki bileşenler NuGet paketleri olarak kullanılabilir:
    • Entity Framework Core
    • Üçüncü taraf tümleştirmesi sağlayan API'ler
    • Deneysel özellikler
    • Paylaşılan çerçevede olma gereksinimlerini karşılayamayan bağımlılıklara sahip API'ler
  • Json.NET desteğini koruyan MVC uzantıları. API, Json.NET ve MVC'nin kullanılmasını desteklemek için NuGet paketi olarak sağlanır. Daha fazla bilgi için ASP.NET Core geçiş kılavuzuna bakın.
  • SignalR .NET istemcisi .NET Standard'ı desteklemeye devam eder ve bir NuGet paketi olarak gönderir. Xamarin ve UWP gibi birçok .NET çalışma zamanında kullanılmak üzere tasarlanmıştır.

Daha fazla bilgi için bkz . 3.0'da paylaşılan çerçeve derlemeleri için paket üretmeyi durdurma. Tartışma için bkz . dotnet/aspnetcore#3757.

Kategori

ASP.NET Core

Etkilenen API’ler

Paylaşılan çerçeve: Microsoft.AspNetCore.All kaldırıldı

ASP.NET Core 3.0'dan başlayarak meta Microsoft.AspNetCore.All paket oluşturma ve eşleşen Microsoft.AspNetCore.All paylaşılan çerçeve artık üretilemeyecek. Bu paket ASP.NET Core 2.2'de kullanılabilir ve ASP.NET Core 2.1'de hizmet güncelleştirmelerini almaya devam edecektir.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Uygulamalar, .NET Core'da Microsoft.AspNetCore.All paylaşılan çerçeveyi Microsoft.AspNetCore.All hedeflemek için meta paketi kullanabilir.

Yeni davranış

.NET Core 3.0 paylaşılan bir Microsoft.AspNetCore.All çerçeve içermez.

Değişiklik nedeni

Microsoft.AspNetCore.All Meta paket çok sayıda dış bağımlılık içeriyor.

Çerçeveyi kullanmak Microsoft.AspNetCore.App için projenizi geçirin. 'de Microsoft.AspNetCore.All daha önce kullanılabilir olan bileşenler NuGet'te hala kullanılabilir. Bu bileşenler artık paylaşılan çerçeveye dahil olmak yerine uygulamanızla dağıtılır.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

SignalR: HandshakeProtocol.SuccessHandshakeData değiştirildi

HandshakeProtocol.SuccessHandshakeData alanı kaldırıldı ve belirli IHubProtocolbir verilen başarılı bir el sıkışma yanıtı oluşturan bir yardımcı yöntemle değiştirildi.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

HandshakeProtocol.SuccessHandshakeData bir public static ReadOnlyMemory<byte> tarlaydı.

Yeni davranış

HandshakeProtocol.SuccessHandshakeData , belirtilen protokole göre bir döndüren bir staticGetSuccessfulHandshake(IHubProtocol protocol)ReadOnlyMemory<byte> yöntemle değiştirildi.

Değişiklik nedeni

El sıkışma yanıtına sabit olmayan ve seçilen protokole bağlı olarak değişen ek alanlar eklendi.

Yok. Bu tür, kullanıcı kodundan kullanılmak üzere tasarlanmamıştır. Bu, publicSignalR sunucusu ve istemcisi arasında paylaşılabilmesi için şeklindedir. .NET'te yazılmış müşteri SignalR istemcileri tarafından da kullanılabilir. SignalR kullanıcıları bu değişiklikten etkilenmemelidir.

Kategori

ASP.NET Core

Etkilenen API’ler

HandshakeProtocol.SuccessHandshakeData

SignalR: Hub Bağlan ion ResetSendPing ve ResetTimeout yöntemleri kaldırıldı

ResetSendPing ve ResetTimeout yöntemleri SignalR HubConnection API'sinden kaldırıldı. Bu yöntemler başlangıçta yalnızca iç kullanıma yönelikti ancak ASP.NET Core 2.2'de genel kullanıma açık hale getirildi. Bu yöntemler ASP.NET Core 3.0 Preview 4 sürümünden itibaren kullanılamaz. Tartışma için bkz . dotnet/aspnetcore#8543.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

API'ler kullanılabilir.

Yeni davranış

API'ler kaldırılır.

Değişiklik nedeni

Bu yöntemler başlangıçta yalnızca iç kullanıma yönelikti ancak ASP.NET Core 2.2'de genel kullanıma açık hale getirildi.

Bu yöntemleri kullanmayın.

Kategori

ASP.NET Core

Etkilenen API’ler

SignalR: Hub Bağlan ionContext oluşturucuları değiştirildi

SignalR oluşturucuları HubConnectionContext , birden çok parametre yerine bir seçenek türünü kabul ederek geleceğe dönük ekleme seçeneklerine dönüştü. Bu değişiklik, iki oluşturucuyu bir seçenek türünü kabul eden tek bir oluşturucuyla değiştirir.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

HubConnectionContext iki oluşturucuya sahiptir:

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

Yeni davranış

İki oluşturucu kaldırıldı ve bir oluşturucu ile değiştirildi:

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

Değişiklik nedeni

Yeni oluşturucu yeni bir seçenekler nesnesi kullanır. Sonuç olarak, özellikleri HubConnectionContext daha fazla oluşturucu ve hataya neden olan değişiklikler yapılmadan gelecekte genişletilebilir.

Aşağıdaki oluşturucuyu kullanmak yerine:

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

Aşağıdaki oluşturucuyu kullanın:

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

Kategori

ASP.NET Core

Etkilenen API’ler

SignalR: JavaScript istemci paketi adı değiştirildi

ASP.NET Core 3.0 Preview 7'de SignalR JavaScript istemci paketi adı olarak @aspnet/signalr@microsoft/signalrdeğiştirildi. Ad değişikliği, Azure SignalR Hizmeti sayesinde SignalR'nin yalnızca ASP.NET Core uygulamalarında kullanışlı olduğu gerçeğini yansıtır.

Bu değişikliğe tepki vermek için package.json dosyalarınızdaki, require deyimlerinizdeki ve ECMAScript import deyimlerinizdeki başvuruları değiştirin. Bu yeniden adlandırmanın bir parçası olarak hiçbir API değişmez.

Tartışma için bkz . dotnet/aspnetcore#11637.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

İstemci paketi olarak adlandırıldı @aspnet/signalr.

Yeni davranış

İstemci paketi olarak adlandırılır @microsoft/signalr.

Değişiklik nedeni

Ad değişikliği, signalR'nin Azure SignalR Hizmeti sayesinde ASP.NET Core uygulamalarının ötesinde yararlı olduğunu gösterir.

Yeni paketine @microsoft/signalrgeçin.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

SignalR: Kullanım dışı olarak işaretlenen UseSignalR ve Use Bağlan ions yöntemleri

yöntemleri UseConnections ve UseSignalR sınıfları ConnectionsRouteBuilder ve HubRouteBuilder ASP.NET Core 3.0'da eski olarak işaretlenir.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

SignalR hub yönlendirmesi veya UseConnectionskullanılarak UseSignalR yapılandırıldı.

Yeni davranış

Yönlendirmeyi yapılandırmanın eski yolu kullanımdan kaldırıldı ve yerine uç nokta yönlendirmesi kullanıldı.

Değişiklik nedeni

Ara yazılım yeni uç nokta yönlendirme sistemine taşınıyor. Ara yazılım eklemenin eski yolu engelleniyor.

değerini ile UseEndpointsdeğiştirinUseSignalR:

Eski kod:

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

Yeni kod:

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

Kategori

ASP.NET Core

Etkilenen API’ler

SPA'lar: SpaServices ve NodeServices eski olarak işaretlendi

ASP.NET Core 2.1'den bu yana aşağıdaki NuGet paketlerinin tüm içeriği gereksizdir. Sonuç olarak, aşağıdaki paketler eski olarak işaretleniyor:

Aynı nedenle, aşağıdaki npm modülleri kullanım dışı olarak işaretleniyor:

Önceki paketler ve npm modülleri daha sonra .NET 5'te kaldırılacaktır.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Kullanım dışı bırakılan paketler ve npm modülleri, ASP.NET Core'un çeşitli Tek Sayfalı Uygulama (SPA) çerçeveleriyle tümleştirilmesi amaçlanmıştır. Bu çerçeveler Arasında Angular, React ve Redux ile React bulunur.

Yeni davranış

Microsoft.AspNetCore.SpaServices.Extensions NuGet paketinde yeni bir tümleştirme mekanizması var. Paket, ASP.NET Core 2.1'den bu yana Angular ve React proje şablonlarının temelini oluşturur.

Değişiklik nedeni

ASP.NET Core, Angular, React ve React with Redux gibi çeşitli Tek Sayfalı Uygulama (SPA) çerçeveleriyle tümleştirmeyi destekler. Başlangıçta, bu çerçevelerle tümleştirme, sunucu tarafı prerendering ve Webpack ile tümleştirme gibi senaryoları işleyen ASP.NET Core'a özgü bileşenlerle gerçekleştirilir. Zaman geçtikçe sektör standartları değişti. SPA çerçevelerinin her biri kendi standart komut satırı arabirimlerini yayımladı. Örneğin, Angular CLI ve create-react-app.

ASP.NET Core 2.1 Mayıs 2018'de yayınlandığında, takım standartlardaki değişikliğe yanıt verdi. SPA çerçevelerinin kendi araç zincirleriyle tümleştirmenin daha yeni ve basit bir yolu sağlanmıştır. Yeni tümleştirme mekanizması pakette Microsoft.AspNetCore.SpaServices.Extensions bulunur ve ASP.NET Core 2.1'den bu yana Angular ve React proje şablonlarının temelini oluşturur.

Eski ASP.NET Core'a özgü bileşenlerin ilgisiz olduğunu ve önerilmez olduğunu netleştirmek için:

  • 2.1 öncesi tümleştirme mekanizması kullanım dışı olarak işaretlenir.
  • Destekleyen npm paketleri kullanım dışı olarak işaretlenir.

Bu paketleri kullanıyorsanız, uygulamalarınızı şu işlevleri kullanacak şekilde güncelleştirin:

  • Pakette Microsoft.AspNetCore.SpaServices.Extensions .
  • Kullandığınız SPA çerçeveleri tarafından sağlanır

Sunucu tarafı önyükleme ve sık erişimli modülü yeniden yükleme gibi özellikleri etkinleştirmek için ilgili SPA çerçevesinin belgelerine bakın. içindeki Microsoft.AspNetCore.SpaServices.Extensionsişlevi eski değildir ve desteklenmeye devam edecektir.

Kategori

ASP.NET Core

Etkilenen API’ler

SPA'lar: SpaServices ve NodeServices artık konsol günlükçüsünü kullanamayacak

Microsoft.AspNetCore.SpaServices ve Microsoft.AspNetCore.NodeServices günlük yapılandırılmadığı sürece konsol günlüklerini görüntülemez.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

Microsoft.AspNetCore.SpaServices ve Microsoft.AspNetCore.NodeServices günlük yapılandırılmadığında otomatik olarak bir konsol günlükçü oluşturmak için kullanılır.

Yeni davranış

Microsoft.AspNetCore.SpaServices ve Microsoft.AspNetCore.NodeServices günlük yapılandırılmadığı sürece konsol günlüklerini görüntülemez.

Değişiklik nedeni

Diğer ASP.NET Core paketlerinin günlüğe kaydetmeyi uygulama şekliyle uyumlu olması gerekir.

Eski davranış gerekiyorsa konsol günlüğünü yapılandırmak için yönteminize Setup.ConfigureServices ekleyinservices.AddLogging(builder => builder.AddConsole()).

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Hedef çerçeve: .NET Framework desteği bırakıldı

.NET Framework, ASP.NET Core 3.0'dan başlayarak desteklenmeyen bir hedef çerçevedir.

Açıklama değiştirildi

.NET Framework 4.8, .NET Framework'ün son ana sürümüdür. Yeni ASP.NET Core uygulamaları .NET Core üzerinde derlenmelidir. .NET Core 3.0 sürümünden başlayarak, ASP.NET Core 3.0'ı .NET Core'un bir parçası olarak düşünebilirsiniz.

.NET Framework ile ASP.NET Core kullanan müşteriler, 2.1 LTS sürümünü kullanarak tam olarak desteklenen bir şekilde devam edebilir. 2.1 desteği ve bakımı en az 21 Ağustos 2021'e kadar devam eder. Bu tarih, .NET Destek İlkesi başına LTS sürümünün bildirildikten üç yıl sonradır. .NET Framework üzerinde ASP.NET Core 2.1 paketleri desteği, diğer paket tabanlı ASP.NET çerçeveleri için hizmet ilkesine benzer şekilde süresiz olarak genişletilecektir.

.NET Framework'ten .NET Core'a taşıma hakkında daha fazla bilgi için bkz . .NET Core'a taşıma.

Microsoft.Extensions paketler (günlüğe kaydetme, bağımlılık ekleme ve yapılandırma gibi) ve Entity Framework Core etkilenmez. .NET Standard'ı desteklemeye devam ederler.

Bu değişikliğin motivasyonu hakkında daha fazla bilgi için özgün blog gönderisine bakın.

Sürüm kullanıma sunulmuştur

3.0

Eski davranış

ASP.NET Core uygulamaları .NET Core veya .NET Framework üzerinde çalıştırılabilir.

Yeni davranış

ASP.NET Core uygulamaları yalnızca .NET Core üzerinde çalıştırılabilir.

Aşağıdaki eylemlerden birini uygulayın:

  • Uygulamanızı ASP.NET Core 2.1'de tutun.
  • Uygulamanızı ve bağımlılıklarınızı .NET Core'a geçirin.

Kategori

ASP.NET Core

Etkilenen API’ler

Hiçbiri

Core .NET kitaplıkları

Rapor sürümüne sahip API'ler artık dosya sürümünü değil ürünü raporla

.NET Core'da sürüm döndüren API'lerin çoğu artık dosya sürümü yerine ürün sürümünü döndürür.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerde , RuntimeInformation.FrameworkDescriptiongibi Environment.Versionyöntemler ve .NET Core derlemeleri için dosya özellikleri iletişim kutusu dosya sürümünü yansıtır. .NET Core 3.0'dan başlayarak ürün sürümünü yansıtır.

Aşağıdaki şekilde, Windows Gezgini dosya özellikleri iletişim kutusunda gösterildiği gibi .NET Core 2.2 (solda) ve .NET Core 3.0 (sağda) için System.Runtime.dll derlemesinin sürüm bilgileri arasındaki fark gösterilmektedir.

Difference in product version information

Sürüm kullanıma sunulmuştur

3.0

Yok. Bu değişiklik, sürüm algılamayı obtuse yerine sezgisel hale getirmelidir.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

Özel EncoderFallbackBuffer örnekleri özyinelemeli olarak geri dönemez

Özel EncoderFallbackBuffer örnekler özyinelemeli olarak geri döndürülemez. uygulaması EncoderFallbackBuffer.GetNextChar() , hedef kodlamaya dönüştürülebilir bir karakter dizisiyle sonuçlanmalıdır. Aksi takdirde bir özel durum oluşur.

Açıklama değiştirildi

Karakterden bayta dönüştürme işlemi sırasında çalışma zamanı hatalı biçimlendirilmiş veya çevrilemez UTF-16 dizilerini algılar ve bu karakterleri yöntemine EncoderFallbackBuffer.Fallback sağlar. Fallback yöntemi, özgün dönüştürülemez veriler için hangi karakterlerin değiştirileceğini belirler ve bu karakterler döngü içinde çağrılarak EncoderFallbackBuffer.GetNextChar boşaltılır.

Çalışma zamanı daha sonra bu değiştirme karakterlerini hedef kodlamaya dönüştürmeyi dener. Bu işlem başarılı olursa, çalışma zamanı özgün giriş dizesinde kaldığı yerden kodlamaya devam eder.

Daha önce, özel uygulamaları EncoderFallbackBuffer.GetNextChar() hedef kodlamaya dönüştürülemeyen karakter dizileri döndürebiliyor. Değiştirilen karakterler hedef kodlamaya kodlanamazsa, çalışma zamanı yöntemi değiştirme karakterleriyle bir kez daha çağırır EncoderFallbackBuffer.Fallback ve yöntemin yeni bir değiştirme dizisi döndürmesini EncoderFallbackBuffer.GetNextChar() bekler. Bu işlem, çalışma zamanı sonunda iyi biçimlendirilmiş, dönüştürülebilir bir değiştirme görene kadar veya maksimum özyineleme sayısına ulaşılana kadar devam eder.

.NET Core 3.0'dan başlayarak, özel uygulamaları EncoderFallbackBuffer.GetNextChar() hedef kodlamaya dönüştürülebilir karakter dizileri döndürmelidir. Değiştirilen karakterler hedef kodlamaya kodlanamazsa, bir ArgumentException oluşturulur. Çalışma zamanı artık örneğe özyinelemeli çağrılar EncoderFallbackBuffer yapmaz.

Bu davranış yalnızca aşağıdaki koşulların üçü de karşılandığında geçerlidir:

  • Çalışma zamanı, hedef kodlamaya dönüştürülemeyen, kötü biçimlendirilmiş bir UTF-16 dizisi veya UTF-16 dizisi algılar.
  • Özel EncoderFallback bir belirtildi.
  • Özel EncoderFallback girişimler, yeni bir hatalı biçimlendirilmiş veya dönüştürülemez UTF-16 dizisini değiştirme girişiminde bulunur.

Sürüm kullanıma sunulmuştur

3.0

Çoğu geliştiricinin herhangi bir işlem gerçekleştirmesi gerekmez.

Bir uygulama özel EncoderFallback ve EncoderFallbackBuffer sınıf kullanıyorsa, uygulamasının EncoderFallbackBuffer.Fallback geri dönüş arabelleğinin, yöntem çalışma zamanı tarafından ilk kez çağrıldığında Fallback hedef kodlamaya doğrudan dönüştürülebilen iyi biçimlendirilmiş UTF-16 verileriyle doldurulduğundan emin olun.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

Kayan nokta biçimlendirme ve ayrıştırma davranışı değiştirildi

Kayan nokta ayrıştırma ve biçimlendirme davranışı (ve türlerine Double göre) artık IEEE uyumlu.Single Bu, .NET'teki kayan nokta türlerinin davranışının diğer IEEE uyumlu dillerle eşleşmesini sağlar. Örneğin, double.Parse("SomeLiteral") C# tarafından için double x = SomeLiteralüretilen ile her zaman eşleşmelidir.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerde ve ile Double.ToStringSingle.ToStringbiçimlendirme ve , Double.TryParse, Single.Parseve Single.TryParse ile Double.Parseayrıştırma, IEEE uyumlu değildir. Sonuç olarak, bir değerin desteklenen standart veya özel biçim dizeleriyle gidiş dönüş yapacağı garanti etmek mümkün değildir. Bazı girişlerde, biçimlendirilmiş bir değeri ayrıştırma girişimi başarısız olabilir ve diğerleri için ayrıştırılan değer özgün değere eşit değildir.

.NET Core 3.0'dan başlayarak, kayan nokta ayrıştırma ve biçimlendirme işlemleri IEEE 754 uyumlu olur.

Aşağıdaki tabloda iki kod parçacığı ve çıkışın .NET Core 2.2 ile .NET Core 3.1 arasında nasıl değiştiği gösterilmektedir.

Kod parçacığı .NET Core 2.2'de çıktı .NET Core 3.1'de çıkış
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Daha fazla bilgi için .NET Core 3.0'da Kayan nokta ayrıştırma ve biçimlendirme geliştirmeleri blog gönderisine bakın.

Sürüm kullanıma sunulmuştur

3.0

.NET Core 3.0 blog gönderisindeki Kayan nokta ayrıştırma ve biçimlendirme geliştirmelerinin Mevcut kod üzerindeki olası etkisi bölümünde, önceki davranışı korumak istiyorsanız kodunuzda yapabileceğiniz bazı değişiklikler önerilmektedir.

  • Biçimlendirmedeki bazı farklılıklar için, farklı bir biçim dizesi belirterek önceki davranışa eşdeğer bir davranış elde edebilirsiniz.
  • Ayrıştırma farklılıkları için önceki davranışa geri dönme mekanizması yoktur.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

Kayan nokta ayrıştırma işlemleri artık başarısız olmaz veya OverflowException oluşturamaz

Kayan nokta ayrıştırma yöntemleri, sayısal değeri veya kayan nokta türü aralığının Single dışında olan bir dizeyi ayrıştırdığında artık bir OverflowException veya Double döndürmezfalse.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerinde ve Single.Parse yöntemleri, Double.Parse ilgili tür aralığının dışında olan değerler için bir OverflowException oluşturur. Double.TryParse ve Single.TryParse yöntemleri, aralık dışı sayısal değerlerin dize gösterimleri için döndürürfalse.

.NET Core 3.0'dan başlayarak, Double.Parsearalık dışı sayısal dizeler ayrıştırıldığında , Double.TryParse, Single.Parseve Single.TryParse yöntemleri artık başarısız olmaz. Bunun yerine, Double ayrıştırma yöntemleri değerini aşan Double.MaxValuedeğerler için döndürür Double.PositiveInfinity ve değerinden Double.MinValueküçük değerler için döndürürDouble.NegativeInfinity. Benzer şekilde, Single ayrıştırma yöntemleri değerini aşan Single.MaxValuedeğerler için döndürür Single.PositiveInfinity ve değerinden Single.MinValueküçük değerler için döndürürSingle.NegativeInfinity.

Bu değişiklik, geliştirilmiş IEEE 754:2008 uyumluluğu için yapılmıştır.

Sürüm kullanıma sunulmuştur

3.0

Bu değişiklik kodunuzu iki yoldan biriyle etkileyebilir:

  • Kodunuz, bir taşma oluştuğunda yürütülecek işleyiciye OverflowException bağlıdır. Bu durumda deyimini catch kaldırmanız ve olup olmadığını Double.IsInfinitySingle.IsInfinitytruetest eden bir If deyime gerekli kodları yerleştirmeniz gerekir.

  • Kodunuz kayan nokta değerlerinin olmadığını Infinityvarsayar. Bu durumda, ve NegativeInfinityöğesinin kayan nokta değerlerini PositiveInfinity denetlemek için gerekli kodu eklemeniz gerekir.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

InvalidAsynchronousStateException başka bir derlemeye taşındı

Sınıf InvalidAsynchronousStateException taşındı.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerinde, InvalidAsynchronousStateException sınıfı System.ComponentModel.TypeConverter derlemesinde bulunur.

.NET Core 3.0'dan başlayarak System.ComponentModel.Primitives derlemesinde bulunur.

Sürüm kullanıma sunulmuştur

3.0

Bu değişiklik yalnızca türün belirli bir derlemede InvalidAsynchronousStateException olduğunu varsayar gibi bir yöntemi Assembly.GetType veya aşırı yüklemesini Activator.CreateInstance çağırarak öğesini yüklemek için yansıma kullanan uygulamaları etkiler. Böyle bir durumda, türün yeni derleme konumunu yansıtacak şekilde yöntem çağrısında başvuruda bulunılan derlemeyi güncelleştirin.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

Yok.

Bozuk biçimlendirilmiş UTF-8 bayt dizilerini değiştirmek Unicode yönergelerini izler

UTF8Encoding Sınıf, bayt-karakter dönüştürme işlemi sırasında hatalı biçimlendirilmiş bir UTF-8 bayt dizisiyle karşılaştığında, bu diziyi çıkış dizesinde '' (U+FFFD DEĞİşTİrME KARAKTERİ) karakteriyle değiştirir. .NET Core 3.0, kodlama değiştirme işlemi sırasında bu değişikliği gerçekleştirmek için en iyi Unicode uygulamasını izleyerek .NET Core ve .NET Framework'ün önceki sürümlerinden farklıdır.

Bu, yeni System.Text.Unicode.Utf8 ve System.Text.Rune türler dahil olmak üzere .NET genelinde UTF-8 işlemeyi geliştirmek için daha büyük bir çabanın parçasıdır. Türüne UTF8Encoding , yeni tanıtılan türlerle tutarlı bir çıkış üretmesi için geliştirilmiş hata işleme mekanizmaları verilmiştir.

Açıklama değiştirildi

.NET Core 3.0'dan başlayarak, baytları karakterlere dönüştürürken sınıf, UTF8Encoding Unicode en iyi yöntemlerine göre karakter değişimi gerçekleştirir. Kullanılan değiştirme mekanizması, Üst Düzey Alt Parçaların U+FFFD Değişimi başlıklı başlıkta Unicode Standard, Sürüm 12.0, Sn. 3.9 (PDF) ile açıklanmıştır.

Bu davranış yalnızca giriş bayt dizisi kötü biçimlendirilmiş UTF-8 verileri içerdiğinde geçerlidir. Ayrıca, örneği ile throwOnInvalidBytes: trueUTF8Encoding oluşturulduysaUTF8Encoding, örnek U+FFFD değişimi yerine geçersiz girişler yapmaya devam eder. Oluşturucu hakkında UTF8Encoding daha fazla bilgi için bkz UTF8Encoding(Boolean, Boolean). .

Aşağıdaki tabloda bu değişikliğin etkisi geçersiz bir 3 baytlık girişle gösterilmiştir:

Kötü biçimlendirilmiş 3 baytlık giriş .NET Core 3.0 öncesi çıkış .NET Core 3.0 ile başlayan çıkış
[ ED A0 90 ] [ FFFD FFFD ] (2 karakterlik çıkış) [ FFFD FFFD FFFD ] (3 karakterli çıkış)

3 karakterli çıkış, daha önce bağlantılı Unicode Standart PDF'nin Tablo 3-9'a göre tercih edilen çıkıştır.

Sürüm kullanıma sunulmuştur

3.0

Geliştirici tarafından herhangi bir işlem yapılması gerekmez.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

TypeDescriptionProviderAttribute başka bir derlemeye taşındı

Sınıf TypeDescriptionProviderAttribute taşındı.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerinde, Sınıfı TypeDescriptionProviderAttribute System.ComponentModel.TypeConverter derlemesinde bulunur.

.NET Core 3.0'dan başlayarak System.ObjectModel derlemesinde bulunur.

Sürüm kullanıma sunulmuştur

3.0

Bu değişiklik yalnızca türün belirli bir derlemede TypeDescriptionProviderAttribute olduğunu varsayar gibi bir yöntemi Assembly.GetType veya aşırı yüklemesini Activator.CreateInstance çağırarak türü yüklemek için yansıma kullanan uygulamaları etkiler. Bu durumda, yöntem çağrısında başvuruda bulunılan derleme türün yeni derleme konumunu yansıtacak şekilde güncelleştirilmelidir.

Kategori

Windows Forms

Etkilenen API’ler

Yok.

ZipArchiveEntry artık tutarsız giriş boyutlarına sahip arşivleri işlemez

Zip arşivleri merkezi dizinde ve yerel üst bilgide hem sıkıştırılmış boyutu hem de sıkıştırılmamış boyutu listeler. Giriş verilerinin kendisi de boyutunu gösterir. .NET Core 2.2 ve önceki sürümlerde bu değerler hiçbir zaman tutarlılık açısından denetlenmedi. .NET Core 3.0'dan başlayarak artık.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerde, ZipArchiveEntry.Open() yerel üst bilgi zip dosyasının merkezi üst bilgisi ile aynı fikirde olmasa bile başarılı olur. Uzunluğu merkezi dizinde/yerel üst bilgide listelenen sıkıştırılmamış dosya boyutunu aşsa bile sıkıştırılmış akışın sonuna ulaşılana kadar veriler sıkıştırılır.

.NET Core 3.0'dan başlayarak yöntem, ZipArchiveEntry.Open() yerel üst bilgi ve merkezi üst bilginin bir girdinin sıkıştırılmış ve sıkıştırılmamış boyutları üzerinde aynı fikirde olup olmadığını denetler. Aksi takdirde yöntemi, arşivin yerel üst bilgisi ve/veya veri tanımlayıcısı liste boyutlarının zip dosyasının merkezi dizinine katılmaması durumunda bir InvalidDataException oluşturur. Bir girdi okunurken, sıkıştırılmış veriler üst bilgide listelenen sıkıştırılmamış dosya boyutuna yuvarlanır.

Bu değişiklik, bir ZipArchiveEntry öğesinin verilerinin boyutunu doğru bir şekilde temsil etmesini ve yalnızca bu miktarda verinin okunmasını sağlamak için yapılmıştır.

Sürüm kullanıma sunulmuştur

3.0

Bu sorunları sergileyen tüm zip arşivlerini yeniden paketleyebilirsiniz.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

FieldInfo.SetValue statik, yalnızca init alanları için özel durum oluşturuyor

.NET Core 3.0'dan başlayarak, statik bir alanda çağrılarak System.Reflection.FieldInfo.SetValuebir değer ayarlamaya çalıştığınızda bir InitOnly özel durum oluşturulur.

Açıklama değiştirildi

.NET Framework ve .NET Core'un 3.0 öncesi sürümlerinde, başlatıldıktan System.Reflection.FieldInfo.SetValuesonra sabit olan statik bir alanın değerini çağırarak ayarlayabilirsiniz (C#'de salt okunur). Ancak, böyle bir alanın bu şekilde ayarlanması hedef çerçeve ve iyileştirme ayarlarına göre öngörülemeyen davranışlara neden oldu.

.NET Core 3.0 ve sonraki sürümlerde statik bir InitOnly alanda çağrı SetValue yaptığınızda bir System.FieldAccessException özel durum oluşturulur.

İpucu

Alan InitOnly , yalnızca bildirildiğinde veya içeren sınıfın oluşturucusunda ayarlanabilen bir alantır. Başka bir deyişle başlatıldıktan sonra sabittir.

Sürüm kullanıma sunulmuştur

3.0

Statik oluşturucudaki statik InitOnly alanları başlatın. Bu, hem dinamik hem de dinamik olmayan türler için geçerlidir.

Alternatif olarak, özniteliğini alanından kaldırabilir FieldAttributes.InitOnly ve çağrısı FieldInfo.SetValueyapabilirsiniz.

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

IEnumerable<T> alan uzantı yöntemlerine GroupCollection geçirmek için kesinleştirme gerekir

üzerinde alan bir uzantı yöntemini IEnumerable<T>GroupCollectionçağırırken, türü tür ataması kullanarak kesinleştirmeniz gerekir.

Açıklama değiştirildi

.NET Core 3.0'dan başlayarak, System.Text.RegularExpressions.GroupCollectionIEnumerable<KeyValuePair<String,Group>> dahil olmak üzere IEnumerable<Group>uyguladığı diğer türlere ek olarak uygular. Bu, alan IEnumerable<T>bir uzantı yöntemini çağırırken belirsizliğe neden olur. Örneğin Enumerable.Countbir örnekte böyle bir uzantı yöntemini GroupCollection çağırırsanız aşağıdaki derleyici hatasını görürsünüz:

CS1061: 'GroupCollection' 'Count' için bir tanım içermiyor ve 'GroupCollection' türünün ilk bağımsız değişkenini kabul eden erişilebilir bir uzantı yöntemi 'Count' bulunamadı (using yönergesi veya derleme başvurusu eksik mi?)

.NET'in önceki sürümlerinde belirsizlik ve derleyici hatası yoktu.

Sürüm kullanıma sunulmuştur

3.0

Değişiklik nedeni

Bu kasıtsız bir hata değişikliğiydi. Bir süredir böyle olduğu için geri almayı planlamıyoruz. Buna ek olarak, böyle bir değişiklik kendi kendine bozulacak.

Örneğin GroupCollection , atama ile kabul IEnumerable<T> eden uzantı yöntemlerine yönelik disambiguate çağrıları.

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

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

Kategori

Core .NET kitaplıkları

Etkilenen API’ler

kabul eden herhangi bir IEnumerable<T> uzantı yöntemi etkilenir. Örneğin:

Şifreleme

Linux'ta kök sertifikalar için "BEGIN TRUSTED CERTIFICATE" söz dizimi artık desteklenmiyor

Linux ve diğer Unix benzeri sistemlerde (macOS değil) kök sertifikalar iki biçimde sunulabilir: standart BEGIN CERTIFICATE PEM üst bilgisi ve OpenSSL'ye özgü BEGIN TRUSTED CERTIFICATE PEM üst bilgisi. İkinci söz dizimi , .NET Core'un System.Security.Cryptography.X509Certificates.X509Chain sınıfıyla uyumluluk sorunlarına neden olan ek yapılandırmaya olanak tanır. BEGIN TRUSTED CERTIFICATE kök sertifika içeriği artık .NET Core 3.0'dan başlayarak zincir altyapısı tarafından yüklenmez.

Açıklama değiştirildi

Daha önce kök güven listesini doldurmak için hem hem de BEGIN CERTIFICATEBEGIN TRUSTED CERTIFICATE söz dizimleri kullanılıyordu. BEGIN TRUSTED CERTIFICATE Söz dizimi kullanıldıysa ve dosyada ek seçenekler belirtildiyse, X509Chain zincir güvenine açıkça izin verilmediğini (X509ChainStatusFlags.ExplicitDistrust bildirmiş olabilir). Ancak, sertifika önceden yüklenmiş bir dosyada söz dizimi ile BEGIN CERTIFICATE de belirtilmişse, zincir güvene izin verilir.

.NET Core 3.0'dan başlayarak, BEGIN TRUSTED CERTIFICATE içerik artık okunmaz. Sertifika standart bir BEGIN CERTIFICATE söz dizimi aracılığıyla da belirtilmezse, X509Chain köke güvenilmediğini (X509ChainStatusFlags.UntrustedRoot) bildirir.

Sürüm kullanıma sunulmuştur

3.0

Çoğu uygulama bu değişiklikten etkilenmez, ancak izin sorunları nedeniyle her iki kök sertifika kaynağını da göremeyen uygulamalar yükseltmeden sonra beklenmeyen UntrustedRoot hatalarla karşılaşabilir.

Birçok Linux dağıtımı (veya dağıtımı), kök sertifikaları iki konuma yazar: dosya başına bir sertifika dizini ve tek dosya birleştirme. Bazı dağıtımlarda, dosya başına tek sertifika dizini söz dizimini BEGIN TRUSTED CERTIFICATE kullanırken, dosya birleştirme standart BEGIN CERTIFICATE söz dizimini kullanır. Herhangi bir özel kök sertifikanın bu konumlardan en az birinde olduğu gibi BEGIN CERTIFICATE eklendiğinden ve her iki konumun da uygulamanız tarafından okunaabildiğinden emin olun.

Tipik dizin /etc/ssl/certs/ ve tipik birleştirilmiş dosya ise /etc/ssl/cert.pem'dir. /etc/ssl/ ile farklı olabilecek platforma özgü kökü belirlemek için komutunu openssl version -d kullanın. Örneğin, Ubuntu 18.04'te dizin /usr/lib/ssl/certs/ ve dosya /usr/lib/ssl/cert.pem şeklindedir. Ancak, /usr/lib/ssl/certs/, /etc/ssl/certs/ ile bir bağlantıdır ve /usr/lib/ssl/cert.pem yoktur.

$ 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

Kategori

Şifreleme

Etkilenen API’ler

EnvelopedCms varsayılan olarak AES-256 şifrelemesini kullanır

tarafından EnvelopedCms kullanılan varsayılan simetrik şifreleme algoritması TripleDES'ten AES-256'ya değiştirildi.

Açıklama değiştirildi

Önceki sürümlerde, EnvelopedCms bir oluşturucu aşırı yüklemesiyle simetrik şifreleme algoritması belirtmeden verileri şifrelemek için kullanıldığında, veriler TripleDES/3DES/3DEA/DES3-EDE algoritmasıyla şifrelenir.

.NET Core 3.0 ile başlayarak (System.Security.Cryptography.Pkcs NuGet paketinin 4.6.0 sürümü aracılığıyla), algoritma modernizasyonu ve varsayılan seçeneklerin güvenliğini geliştirmek için varsayılan algoritma AES-256 olarak değiştirildi. İleti alıcı sertifikasının (EC olmayan) Diffie-Hellman ortak anahtarı varsa, şifreleme işlemi temel platformdaki sınırlamalar nedeniyle başarısız CryptographicException olabilir.

Aşağıdaki örnek kodda, veriler .NET Core 2.2 veya daha önceki bir sürümde çalışıyorsa TripleDES ile şifrelenir. .NET Core 3.0 veya sonraki bir sürümde çalışıyorsa, AES-256 ile şifrelenir.

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

Sürüm kullanıma sunulmuştur

3.0

Değişiklik sizi olumsuz etkiliyorsa, aşağıdaki gibi türünde AlgorithmIdentifierbir parametre içeren bir EnvelopedCms oluşturucuda şifreleme algoritması tanımlayıcısını açıkça belirterek TripleDES şifrelemesini geri yükleyebilirsiniz:

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();

Kategori

Şifreleme

Etkilenen API’ler

RSAOpenSsl anahtar oluşturma için minimum boyut arttı

Linux'ta yeni RSA anahtarları oluşturmanın en düşük boyutu 384 bitten 512 bit'e yükseltildi.

Açıklama değiştirildi

.NET Core 3.0'dan RSA.Createbaşlayarak, , RSAOpenSslve RSACryptoServiceProvider Linux üzerindeki RSA örneklerinde özelliği tarafından LegalKeySizes bildirilen en düşük yasal anahtar boyutu 384'ten 512'ye yükseltildi.

Sonuç olarak, .NET Core 2.2 ve önceki sürümlerde gibi RSA.Create(384) bir yöntem çağrısı başarılı olur. .NET Core 3.0 ve sonraki sürümlerinde, yöntem çağrısı RSA.Create(384) boyutun çok küçük olduğunu belirten bir özel durum oluşturur.

Bu değişiklik, Linux'ta şifreleme işlemlerini gerçekleştiren OpenSSL'nin en düşük değeri 1.0.2 ve 1.1.0 sürümleri arasında yükselttiği için yapıldı. .NET Core 3.0, OpenSSL 1.1.x ile 1.0.x arasında tercih eder ve bildirilen en düşük sürüm bu yeni daha yüksek bağımlılık sınırlamasını yansıtacak şekilde yükseltilmiştir.

Sürüm kullanıma sunulmuştur

3.0

Etkilenen API'lerden herhangi birini çağırırsanız, oluşturulan anahtarların boyutunun sağlayıcının minimum değerinden küçük olmadığından emin olun.

Not

384 bit RSA zaten güvenli değil olarak kabul edilir (512 bit RSA olduğu gibi). NIST Özel Yayını 800-57 Bölüm 1 Düzeltme 4 gibi modern öneriler, yeni oluşturulan anahtarlar için en düşük boyut olarak 2048 bit önerir.

Kategori

Şifreleme

Etkilenen API’ler

.NET Core 3.0, OpenSSL 1.1.x'i OpenSSL 1.0.x'e tercih eder

Birden çok Linux dağıtımında çalışan Linux için .NET Core hem OpenSSL 1.0.x hem de OpenSSL 1.1.x'i destekleyebilir. .NET Core 2.1 ve .NET Core 2.2, önce 1.0.x'i arar, sonra 1.1.x'e geri döner; .NET Core 3.0 önce 1.1.x'i arar. Bu değişiklik, yeni şifreleme standartları için destek eklemek için yapılmıştır.

Bu değişiklik, .NET Core'da OpenSSL'e özgü birlikte çalışma türleriyle platform birlikte çalışma gerçekleştiren kitaplıkları veya uygulamaları etkileyebilir.

Açıklama değiştirildi

.NET Core 2.2 ve önceki sürümlerde çalışma zamanı OpenSSL 1.0.x'i 1.1.x üzerine yüklemeyi tercih eder. Bu, OpenSSL ile birlikte çalışma için ve SafeHandle türlerinin IntPtr tercihe göre libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 ile kullanıldığı anlamına gelir.

.NET Core 3.0 ile başlayarak, çalışma zamanı OpenSSL 1.0.x yerine OpenSSL 1.1.x'i yüklemeyi tercih eder, bu nedenle IntPtr OpenSSL ile birlikte çalışma için ve SafeHandle türleri tercihe göre libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 ile kullanılır. Sonuç olarak, OpenSSL ile doğrudan birlikte çalışan kitaplıkların ve uygulamaların .NET Core 2.1 veya .NET Core 2.2'den yükseltirken .NET Core tarafından kullanıma sunulan değerlerle uyumsuz işaretçileri olabilir.

Sürüm kullanıma sunulmuştur

3.0

OpenSSL ile doğrudan işlemler gerçekleştiren kitaplıkların ve uygulamaların.NET Core çalışma zamanıyla aynı OpenSSL sürümünü kullandıklarından emin olmak için dikkatli olmaları gerekir.

Doğrudan OpenSSL ile .NET Core şifreleme türlerini veya değerlerini kullanan IntPtr tüm kitaplıklar veya SafeHandle uygulamalar, işaretçilerin uyumlu olduğundan emin olmak için kullandıkları kitaplığın sürümünü yeni SafeEvpPKeyHandle.OpenSslVersion özelliğiyle karşılaştırmalıdır.

Kategori

Şifreleme

Etkilenen API’ler

CryptoStream.Dispose yalnızca yazarken son bloğu dönüştürür

İşlemleri CryptoStream.Dispose tamamlamak CryptoStream için kullanılan yöntemi artık okurken son bloğu dönüştürmeye çalışmaz.

Açıklama değiştirildi

Önceki .NET sürümlerinde, kullanıcı modda kullanırken CryptoStreamRead tamamlanmamış bir okuma gerçekleştirdiyse, Dispose yöntem bir özel durum oluşturabiliyordu (örneğin, doldurma ile AES kullanırken). Son blok dönüştürülmeye çalışıldığından ancak veriler eksik olduğundan özel durum oluştu.

.NET Core 3.0 ve sonraki sürümlerde, Dispose artık okuma sırasında son bloğu dönüştürmeye çalışmaz ve bu da tamamlanmamış okumalara olanak tanır.

Değişiklik nedeni

Bu değişiklik, bir özel durum yakalamaya gerek kalmadan bir ağ işlemi iptal edildiğinde şifreleme akışından tamamlanmamış okumaları etkinleştirir.

Sürüm kullanıma sunulmuştur

3.0

Çoğu uygulama bu değişiklikten etkilenmemelidir.

Uygulamanız daha önce tamamlanmamış bir okuma durumunda bir özel durum yakaladıysa, bu catch bloğu silebilirsiniz. Uygulamanız karma senaryolarında son bloğun dönüştürülmesini kullandıysa, akış atılmadan önce akışın tamamının okundığından emin olmanız gerekebilir.

Kategori

Şifreleme

Etkilenen API’ler

Entity Framework Core

Entity Framework Core hataya neden olan değişiklikler

Globalleştirme

"C" yerel ayarı sabit yerel ayara eşler

.NET Core 2.2 ve önceki sürümler, "C" yerel ayarını en_US_POSIX yerel ayarıyla eşleyen varsayılan ICU davranışına bağlıdır. en_US_POSIX yerel ayarı, büyük/küçük harfe duyarlı olmayan dize karşılaştırmalarını desteklemediğinden istenmeyen bir harmanlama davranışına sahiptir. Bazı Linux dağıtımları "C" yerel ayarını varsayılan yerel ayar olarak belirlediğinden, kullanıcılar beklenmeyen davranışlarla karşılaşıyordu.

Açıklama değiştirildi

.NET Core 3.0'dan başlayarak , "C" yerel ayarı eşlemesi en_US_POSIX yerine Sabit yerel ayarı kullanacak şekilde değiştirildi. Sabit eşleme için "C" yerel ayarı da tutarlılık için Windows'a uygulanır.

en_US_POSIX büyük/küçük harfe duyarsız sıralama/arama dize işlemlerini desteklemediğinden "C" öğesinin en_US_POSIX kültüre eşlenmesi müşteri karışıklığına neden oldu. "C" yerel ayarı bazı Linux dağıtımlarında varsayılan yerel ayar olarak kullanıldığından, müşteriler bu işletim sistemlerinde bu istenmeyen davranışla karşılaşmıştır.

Sürüm kullanıma sunulmuştur

3.0

Bu değişikliğin farkındalığından daha belirgin bir şey yoktur. Bu değişiklik yalnızca "C" yerel ayar eşlemesini kullanan uygulamaları etkiler.

Kategori

Globalleştirme

Etkilenen API’ler

Tüm harmanlama ve kültür API'leri bu değişiklikten etkilenir.

MSBuild

Kaynak bildirim dosyası adı değişikliği

.NET Core 3.0'dan başlayarak, varsayılan durumda MSBuild kaynak dosyaları için farklı bir bildirim dosyası adı oluşturur.

Sürüm kullanıma sunulmuştur

3.0

Açıklama değiştirildi

.NET Core 3.0'dan önce, proje dosyasındaki bir EmbeddedResource öğe için , ManifestResourceNameLogicalNameveya DependentUpon meta veriler belirtilmemişse, MSBuild deseninde <RootNamespace>.<ResourceFilePathFromProjectRoot>.resourcesbir bildirim dosyası adı oluşturdu. Proje dosyasında tanımlanmamışsa RootNamespace , varsayılan olarak proje adı olur. Örneğin, kök proje dizininde Form1.resx adlı bir kaynak dosyası için oluşturulan bildirim adı MyProject.Form1.resources idi.

.NET Core 3.0'dan başlayarak, bir kaynak dosyası aynı ada sahip bir kaynak dosyayla (örneğin, Form1.resx ve Form1.cs) birlikte bulunursa, MSBuild, düzende <Namespace>.<ClassName>.resourcesbildirim dosyası adını oluşturmak için kaynak dosyadaki tür bilgilerini kullanır. Ad alanı ve sınıf adı, birlikte bulunan kaynak dosyasındaki ilk türden ayıklanır. Örneğin, Form1.cs adlı bir kaynak dosyayla birlikte bulunan Form1.resx adlı kaynak dosyası için oluşturulan bildirim adı MyNamespace.Form1.resources şeklindedir. Dikkate almak gereken önemli nokta, dosya adının ilk bölümünün .NET Core'un önceki sürümlerinden (MyProject yerine MyNamespace) farklı olmasıdır.

Not

Proje dosyasındaki bir EmbeddedResource öğede belirtilen , ManifestResourceNameveya DependentUpon meta verileriniz LogicalNamevarsa, bu değişiklik bu kaynak dosyasını etkilemez.

Bu hataya neden olan değişiklik, özelliğin .NET Core projelerine eklenmesiyle EmbeddedResourceUseDependentUponConvention ortaya çıkmıştır. Varsayılan olarak, kaynak dosyaları açıkça bir .NET Core proje dosyasında listelenmez, bu nedenle oluşturulan .resources dosyasının nasıl adlandırılacağını belirtmek için meta verileri yokturDependentUpon. EmbeddedResourceUseDependentUponConvention varsayılan olan olarak ayarlandığındatrue, MSBuild birlikte bulunan bir kaynak dosyayı arar ve bu dosyadan bir ad alanı ve sınıf adı ayıklar. olarak falseayarlarsanızEmbeddedResourceUseDependentUponConvention, MSBuild bildirim adını önceki davranışa göre oluşturur ve bu da ve göreli dosya yolunu birleştirirRootNamespace.

Çoğu durumda, geliştirici tarafından herhangi bir eylem gerekmez ve uygulamanız çalışmaya devam etmelidir. Ancak, bu değişiklik uygulamanızı bozarsa şunları yapabilirsiniz:

  • Kodunuzu yeni bildirim adını bekleyecek şekilde değiştirin.

  • Proje dosyanızda olarak ayarlayarak EmbeddedResourceUseDependentUponConventionfalse yeni adlandırma kuralını geri çevirme.

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

Kategori

MSBuild

Etkilenen API’ler

Yok

Ağ

HttpRequestMessage.Version varsayılan değeri 1.1 olarak değiştirildi

Özelliğin System.Net.Http.HttpRequestMessage.Version varsayılan değeri 2.0'dan 1.1'e değiştirildi.

Sürüm kullanıma sunulmuştur

3.0

Açıklama değiştirildi

.NET Core 1.0 ile 2.0 arasında özelliğin System.Net.Http.HttpRequestMessage.Version varsayılan değeri 1.1'dir. .NET Core 2.1'den başlayarak 2.1 olarak değiştirildi.

.NET Core 3.0'dan başlayarak, özelliği tarafından System.Net.Http.HttpRequestMessage.Version döndürülen varsayılan sürüm numarası bir kez daha 1.1'dir.

2.0 varsayılan değerini döndüren özelliğine System.Net.Http.HttpRequestMessage.Version bağlıysa kodunuzu güncelleştirin.

Kategori

Ağ

Etkilenen API’ler

Ayrıca bkz.