Eğitim
Modül
ASP.NET Core Identity çerçevesi ile bir .NET web uygulamasının güvenliğini sağlama - Training
ASP.NET Core Identity çerçevesini kullanarak .NET web uygulamasına kimlik doğrulaması ve yetkilendirme eklemeyi öğrenin.
Bu tarayıcı artık desteklenmiyor.
En son özelliklerden, güvenlik güncelleştirmelerinden ve teknik destekten faydalanmak için Microsoft Edge’e yükseltin.
.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 2.2'deki eski üyeler ve uyumluluk anahtarları kaldırıldı.
3.0
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.
ASP.NET Core
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.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.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.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
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
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.
3.0
Etkilenen API'ler erişim değiştiricisi ile public
işaretlenir ve ad alanları içinde *.Internal
bulunur.
Etkilenen API'ler iç erişim değiştiricisi ile işaretlenir ve artık bu derlemenin dışındaki kodlar tarafından kullanılamaz.
Bu "pubternal" API'ler için rehberlik şu şekildedir:
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();
ASP.NET Core
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
Google, 28 Ocak 2019'da uygulamalar için Google+ Oturum Açma'yı kapatmaya başlıyor.
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.
Tüm sürümler. Bu değişiklik ASP.NET Core dışındadır.
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 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.
sürüm 2.x için Microsoft.AspNetCore.Authentication.Google
, var olan içindeki çağrınızı AddGoogle
Startup.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 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.ConfigureServices
ile 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();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
üzerindeki HttpContext
kullanım dışı bırakılan Authentication
özellik kaldırıldı.
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.
3.0
ASP.NET Core 1.0 API'lerinin yerini içindeki Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensionsuzantı yöntemleri aldı.
ASP.NET Core
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.
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:
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
. tüm türetilmiş uygulamaları ClaimAction
benzer şekilde etkilenir.MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
JsonElement
değiştirilmiştirJObject
. User
Özellik ve RunClaimActions
yöntem eşleşecek şekilde güncelleştirildi.JObject
türünde JsonDocument
bir parametre kabul eder. Response
özelliği eşleşecek şekilde güncelleştirildi. OAuthTokenResponse
artık atılabilirdir ve tarafından OAuthHandler
atılır. Geçersiz kılınan ExchangeCodeAsync
türetilmiş OAuth uygulamalarının veya OAuthTokenResponse
atılması JsonDocument
gerekmez.JObject
JsonDocument
değiştirildi.JObject
JsonElement
değiştirildi.JObject
JsonElement
değiştirildi. Değiştirme yöntemi şeklindedir TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).ASP.NET Core
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; }
3.0
code
ve redirectUri
dizeleri ayrı bağımsız değişkenler olarak geçirildi.
Code
ve RedirectUri
oluşturucu aracılığıyla ayarlanabilen özelliklerdir OAuthCodeExchangeContext
OAuthCodeExchangeContext
. Yeni OAuthCodeExchangeContext
tür, öğesine OAuthHandler.ExchangeCodeAsync
geçirilen tek bağımsız değişkendir.
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.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
Içinde yer Microsoft.AspNetCore.Authorization
almak için kullanılan temel AddAuthorization
yöntemler olarak AddAuthorizationCore
yeniden 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.
3.0
AddAuthorization
yöntemleri içinde Microsoft.AspNetCore.Authorization
mevcutdu.
AddAuthorization
yöntemleri içinde Microsoft.AspNetCore.Authorization.Policy
bulunur. AddAuthorizationCore
eski yöntemlerin yeni adıdır.
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
.
ASP.NET Core
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.
3.0
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ı.
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.
ASP.NET Core 3.0'da yeni bir uç nokta yönlendirme stratejisi kullanıma sunulmuştur.
Uç nokta meta verilerini için IAllowAnonymous
arayı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.
ASP.NET Core
Hiçbiri
ASP.NET Core 3.0'da öğesine IAuthorizationPolicyProvider
yeni 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.
3.0
uygulamaları IAuthorizationPolicyProvider
bir GetFallbackPolicyAsync
yöntem gerektirmedi.
uygulamaları IAuthorizationPolicyProvider
bir GetFallbackPolicyAsync
yöntem gerektirir.
İlke belirtilmediğinde yeninin kullanması için yeni AuthorizationMiddleware
bir yöntem gerekiyordu.
GetFallbackPolicyAsync
yöntemini uygulamalarınıza IAuthorizationPolicyProvider
ekleyin.
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
ASP.NET Core 3.0 sürümü, eski MemoryCacheOptions API'lerini kaldırdı.
Bu değişiklik aspnet/Caching#221'e yönelik bir izlemedir. Tartışma için bkz . dotnet/extensions#1062.
3.0
MemoryCacheOptions.CompactOnMemoryPressure
özelliği kullanılabilir durumdaydı.
MemoryCacheOptions.CompactOnMemoryPressure
özelliği kaldırıldı.
Ö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.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
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.
3.0
Paket Microsoft.Extensions.Caching.SqlServer
, System.Data.SqlClient
paketi kullandı.
Microsoft.Extensions.Caching.SqlServer
artık paketini kullanıyor Microsoft.Data.SqlClient
.
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 SqlConnection türüne bir DbConnection
yayın yapıyorduysa, atamayı yeni Microsoft.Data.SqlClient.SqlConnection
türle değiştirmesi gerekir.
ASP.NET Core
Hiçbiri
ASP.NET Core 3.0'da ResponseCaching
içindeki "pubternal" türleri olarak internal
değiştirildi.
Ayrıca ve varsayılan uygulamaları IResponseCachingPolicyProvider
IResponseCachingKeyProvider
artık yönteminin AddResponseCaching
bir parçası olarak hizmetlere eklenmez.
ASP.NET Core'da "pubternal" türleri olarak public
bildirilir ancak ile .Internal
ekli 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.
3.0
Bu türler genel olarak görünür durumdaydı, ancak desteklenmiyordu.
Bu türler artık internal
şeklindedir.
Kapsam internal
desteklenmeyen ilkeyi daha iyi yansıtır.
Uygulamanız veya kitaplığınız tarafından kullanılan kopyalama türleri.
ASP.NET Core
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
Azure.Extensions.AspNetCore.DataProtection.Blobs
Azure 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.Blobs
Azure.Storage.
ön ekli API'leri ve paketleri kullanır.
Azure Depolama API'leri hakkında sorular için kullanın https://github.com/Azure/azure-storage-net. Bu sorunla ilgili tartışma için bkz . dotnet/aspnetcore#19570.
3.0
Paket, NuGet paketine başvuruda bulundu WindowsAzure.Storage
.
Paket, NuGet paketine Microsoft.Azure.Storage.Blob
başvurur.
Paket, NuGet paketine Azure.Storage.Blob
başvurur.
Bu değişiklik, önerilen Azure Depolama paketlerine geçiş yapılmasını sağlar Azure.Extensions.AspNetCore.DataProtection.Blobs
.
ASP.NET Core 3.0 ile eski Azure Depolama API'lerini kullanmaya devam etmeniz gerekiyorsa WindowsAzure.Storage veya Microsoft.Azure.Storage 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;
ASP.NET Core
Hiçbiri
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.
3.0
ANCM V1, Windows Barındırma Paketi'ne dahildir.
ANCM V1, Windows Barındırma Paketi'ne dahil değildir.
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:
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
kullanmayı açıkça kabul etti.<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
.ASP.NET Core
Hiçbiri
Genel konağın sınıf oluşturucu eklemesi için Startup
desteklediği türler yalnızca , IWebHostEnvironment
ve IConfiguration
'dırIHostEnvironment
. kullanan WebHost
uygulamalar etkilenmez.
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:
ASP.NET Core 3.0:
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
, IWebHostEnvironment
ve IConfiguration
eklenebilir. Bu değişiklik, tek bir hizmetin yinelenen oluşturulması gibi DI sorunlarını önler.
3.0
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)
ASP.NET Core
Hiçbiri
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.
3.0
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.
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.
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:
ASPNETCORE_HTTPS_PORT
(çoğu üretim senaryosunda 443) ASP.NET Core 2.x'te el ile etkinleştirildi.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ı.
ASP.NET Core
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Mevcut IHostingEnvironment
ve IApplicationLifetime
türleri değiştirmek için yeni türler kullanıma sunulmuştur.
3.0
ve'den Microsoft.Extensions.Hosting
Microsoft.AspNetCore.Hosting
iki farklı IHostingEnvironment
ve IApplicationLifetime
türü vardı.
Eski türler eski olarak işaretlendi ve yeni türlerle değiştirildi.
Microsoft.Extensions.Hosting
ASP.NET Core 2.1'de kullanıma sunulduğunda ve gibi IHostingEnvironment
IApplicationLifetime
bazı türler uygulamasından Microsoft.AspNetCore.Hosting
kopyalanmış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:
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
Yeni IHostEnvironment
IsDevelopment
ve IsProduction
uzantı yöntemleri ad alanındadır Microsoft.Extensions.Hosting
. Bu ad alanının projenize eklenmesi gerekebilir.
ASP.NET Core
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.
3.0
WebHostBuilder
ObjectPoolProvider
, DI kapsayıcısında varsayılan olarak sağlar.
WebHostBuilder
artık DI kapsayıcısında varsayılan olarak sağlamaz ObjectPoolProvider
.
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 IServiceCollection
eklenmesi gerekir.
ASP.NET Core
Hiçbiri
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.
3.0
Sınıflar' dan DefaultHttpContext
türetilebilir.
Sınıflar'dan DefaultHttpContext
türetemez.
Genişletilebilirlik başlangıçta havuzuna izin HttpContext
vermek 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.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
ASP.NET Core 3.0 Preview 5'ten başlayarak içindeki Microsoft.Net.Http.Headers.HeaderNames alanlar olarak const
static readonly
değiştirildi.
Tartışma için bkz . dotnet/aspnetcore#9514.
3.0
Bu alanlar eskiden şeklindedir const
.
Bu alanlar artık static readonly
şeklindedir.
Değişiklik:
3.0'a karşı yeniden derleme. Aşağıdaki yollarla bu alanları kullanan kaynak kodu artık bunu yapamaz:
switch
olduğu case
gibiconst
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.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
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.Body
HttpContext.Features
daha fazla bilgi edinin.
3.0
HTTP yanıt gövdesiyle ilişkilendirilmiş üç API vardı:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
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.
Motivasyon, yanıt gövdesi API'lerini tek bir yeni özellik arabiriminde birleştirmektir.
Daha önce , veya IHttpBufferingFeature
kullanırken kullandığınız IHttpResponseFeature.Body
yeri kullanınIHttpResponseBodyFeature
. IHttpSendFileFeature
ASP.NET Core
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.
3.0
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.Lax
olan bir tutarsızlık örneği görülürHttpResponse.Cookies.Append(String, String)
.HttpResponse.Cookies.Append(String, String, CookieOptions)
Etkilenen tüm API'ler varsayılan olarak olarak kullanılır SameSiteMode.None
.
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
.
ASP.NET Core
ASP.NET Core 3.0'dan başlayarak, zaman uyumlu sunucu işlemleri varsayılan olarak devre dışı bırakılır.
AllowSynchronousIO
, ve Stream.Flush
gibi HttpRequest.Body.Read
HttpResponse.Body.Write
zaman 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:
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.
3.0
HttpRequest.Body.Read
, HttpResponse.Body.Write
ve Stream.Flush
varsayılan olarak izin verildi.
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.
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;
}
ASP.NET Core
ASP.NET Core 3.0'dan başlayarak IdentityBuilderUIExtensions.AddDefaultUI (IdentityBuilder,UIFramework) yöntemi aşırı yüklemesi artık mevcut değildir.
3.0
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
ASP.NET Core 3.0'dan başlayarak Kimlik kullanıcı arabirimi varsayılan olarak Bootstrap'ın 4. sürümünü kullanır.
3.0
Yöntem services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
çağrısı ile aynıydı services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
Yöntem services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
çağrısı, services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
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:
Geçiş kılavuzunu kullanarak uygulamanızı Bootstrap 4 kullanacak şekilde geçirin.
Bootstrap 3 kullanımını zorunlu kılmak için güncelleştirin Startup.ConfigureServices
. Örneğin:
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
ASP.NET Core
Hiçbiri
Varsayılan olarak, SignInAsync
içinde olduğu IsAuthenticated
false
sorumlular / kimlikler için bir özel durum oluşturur.
3.0
SignInAsync
içindeki kimlikler de dahil olmak üzere tüm sorumluları / kimlikleri IsAuthenticated
kabul eder false
.
Varsayılan olarak, SignInAsync
içinde olduğu IsAuthenticated
false
sorumlular / kimlikler için bir özel durum oluşturur. Bu davranışı gizlemeye ilişkin yeni bir bayrak var, ancak varsayılan davranış değişti.
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 AuthenticationOptions
true
bir RequireAuthenticatedSignIn
bayrak vardır. Eski davranışı geri yüklemek için bu bayrağı olarak false
ayarlayın.
ASP.NET Core
Hiçbiri
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.
3.0
Değişikliğin nedeni, Identity'de yeni e-posta /onay akışları için destek eklemekti.
El ile bir SignInManager
oluş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.
ASP.NET Core
ASP.NET Core 3.0 statik bir web varlıkları özelliği kullanıma sunulmuştur ve Kimlik kullanıcı arabirimi bunu benimsemiştir.
Kimlik kullanıcı arabiriminin statik web varlıkları özelliğini benimsemesinin bir sonucu olarak:
IdentityUIFrameworkVersion
gerçekleştirilir.3.0
Kimlik kullanıcı arabirimi için varsayılan UI çerçevesi Bootstrap 3'dü. UI çerçevesi, içindeki Startup.ConfigureServices
yöntem çağrısına AddDefaultUI
bir parametre kullanılarak yapılandırılabilir.
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.
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
"Pubternal" API'lerini 'a public
taşıma işleminin bir parçası olarak kestrel'den kaldırılmıştır IConnectionAdapter
. Bağlantı 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.
3.0
Kestrel genişletilebilirlik bileşenleri kullanılarak IConnectionAdapter
oluşturulmuştur.
Kestrel genişletilebilirlik bileşenleri ara yazılım olarak oluşturulur.
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.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Derleme Microsoft.AspNetCore.Server.Kestrel.Https kaldırıldı.
3.0
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ı.
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.Microsoft.AspNetCore.Server.Kestrel.Https
yönelik tüm doğrudan başvuruları kaldırmalıdır.ASP.NET Core
Hiçbiri
Ö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.
3.0
İstek fragman üst bilgileri koleksiyona HttpRequest.Headers
eklenir.
İ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.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.
ASP.NET Core
"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.
3.0
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
mevcuttur.ListenOptions.NoDelay
kullanılabilir durumdaydı.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.ASP.NET Core 3.0 , "pubternal" API'lerinden uzaklaştı.
ASP.NET Core
Hiçbiri
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'da 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.
3.0
Yöntemler olarak Obsolete
işaretlenmedi.
Yöntemler olarak işaretlenir Obsolete
.
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 CurrentCulture
izin verin. Bu bir seçenek değilse ResourceManagerWithCultureStringLocalizer'ın bir kopyasını oluşturun ve kullanın.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Core 3.0'ın DebugLogger
ASP.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
.
3.0
Değişiklik şu şekilde yapılıyor:
ConsoleLogger
diğer günlükçü uygulamalarıyla tutarlılığı zorunlu tutma.AddDebug ILoggingBuilder
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.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
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.
3.0
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/ListAsync
yönlendirilebilir. Bağlantı oluşturma için son ekin Async
belirtilmesi gerekir. Örneğin:
<a asp-controller="Product" asp-action="ListAsync">List</a>
ASP.NET Core 3.0'da eylem aracılığıyla Product/List
yö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.ConfigureServices
olarak ayarlanarak MvcOptions.SuppressAsyncSuffixInActionNames
false
devre dışı bırakılabilir:
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Kural gereği, zaman uyumsuz .NET yöntemleri ile Async
son 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.MvcOptions.SuppressAsyncSuffixInActionNames
yeniden adlandırmayı false
Startup.ConfigureServices
tamamen devre dışı bırakın:services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
Hiçbiri
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.
3.0 Önizleme 6
2.2 tabanlı kitaplık kullanan bir uygulama başarıyla derlensin.
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.
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
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.
3.0
Paket, Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
MVC Razor görünümlerini önceden derlemek için kullanıldı.
Razor SDK'sı bu işlevselliği yerel olarak destekler. Paket Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
artık güncelleştirilmedi.
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.
ASP.NET Core
Hiçbiri
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.
ASP.NET Core'da "pubternal" türleri olarak public
bildirilir ancak -suffixed ad alanında .Internal
bulunur. 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.
3.0
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.
Bu tür türlerin tümü desteklenen bir ad alanında olacak public
şekilde güncelleştirilir veya olarak internal
işaretlenir.
"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 internal
iş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 public
oluşturmak için dikkat edilmesi gereken noktalar bulunabilir.
ASP.NET Core
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
ASP.NET Core 3.0'dan Microsoft.AspNetCore.Mvc.WebApiCompatShim
başlayarak paket artık kullanılamaz.
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.
3.0
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
RazorTemplateEngine
API kaldırıldı ve ile Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
değiştirildi.
Tartışma için bkz. GitHub sorunu dotnet/aspnetcore#25215.
3.0
Razor dosyalarını ayrıştırmak ve oluşturmak için bir şablon altyapısı oluşturulabilir ve kullanılabilir.
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.
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 RazorTemplateEngine
kullanınRazorProjectEngine
. Aşağıdaki örnekleri göz önünde bulundurun.
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
});
RazorProjectItem item = projectEngine.FileSystem.GetItem(
@"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);
// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();
ASP.NET Core
RazorTemplateEngine
RazorTemplateEngineOptions
Razor görünümlerinin ve Razor Sayfalarının çalışma zamanı derleme desteği ayrı bir pakete taşındı.
3.0
Çalışma zamanı derlemesi ek paketlere gerek kalmadan kullanılabilir.
İş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.MvcRazorRuntimeCompilationOptions
kullanı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.
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:
Pakete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
bir başvuru ekleyin.
projenin Startup.ConfigureServices
yöntemini çağrısı içerecek şekilde AddRazorRuntimeCompilation
güncelleştirin. Örneğin:
services.AddMvc()
.AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Oturum tanımlama bilgilerini yapılandırmaya yönelik eski API'ler kaldırıldı. Daha fazla bilgi için bkz . aspnet/Announcements#257.
3.0
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;
});
}
ASP.NET Core
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.
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.App
kullanıma sunulmuştur.
3.0
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:
Newtonsoft.Json
)Microsoft.EntityFrameworkCore.
derlemeler)Microsoft.CodeAnalysis
)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.
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.App
uygulamalar 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. ).Microsoft.AspNetCore.App
parçası olmayan API'ler. Örneğin, aşağıdaki bileşenler NuGet paketleri olarak kullanılabilir: 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.
ASP.NET Core
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.
3.0
Uygulamalar, .NET Core'da Microsoft.AspNetCore.All
paylaşılan çerçeveyi Microsoft.AspNetCore.All
hedeflemek için meta paketi kullanabilir.
.NET Core 3.0 paylaşılan bir Microsoft.AspNetCore.All
çerçeve içermez.
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.
ASP.NET Core
Hiçbiri
HandshakeProtocol.SuccessHandshakeData alanı kaldırıldı ve belirli IHubProtocol
bir verilen başarılı bir el sıkışma yanıtı oluşturan bir yardımcı yöntemle değiştirildi.
3.0
HandshakeProtocol.SuccessHandshakeData
bir public static ReadOnlyMemory<byte>
tarlaydı.
HandshakeProtocol.SuccessHandshakeData
, belirtilen protokole göre bir döndüren bir static
GetSuccessfulHandshake(IHubProtocol protocol)
ReadOnlyMemory<byte>
yöntemle değiştirildi.
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, public
SignalR 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.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
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.
3.0
API'ler kullanılabilir.
API'ler kaldırılır.
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.
ASP.NET Core
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.
3.0
HubConnectionContext
iki oluşturucuya sahiptir:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
İki oluşturucu kaldırıldı ve bir oluşturucu ile değiştirildi:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
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);
ASP.NET Core
ASP.NET Core 3.0 Preview 7'de SignalR JavaScript istemci paketi adı olarak @aspnet/signalr
@microsoft/signalr
değ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.
3.0
İstemci paketi olarak adlandırıldı @aspnet/signalr
.
İstemci paketi olarak adlandırılır @microsoft/signalr
.
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/signalr
geçin.
ASP.NET Core
Hiçbiri
yöntemleri UseConnections
ve UseSignalR
sınıfları ConnectionsRouteBuilder
ve HubRouteBuilder
ASP.NET Core 3.0'da eski olarak işaretlenir.
3.0
SignalR hub yönlendirmesi veya UseConnections
kullanılarak UseSignalR
yapılandırıldı.
Yönlendirmeyi yapılandırmanın eski yolu kullanımdan kaldırıldı ve yerine uç nokta yönlendirmesi kullanıldı.
Ara yazılım yeni uç nokta yönlendirme sistemine taşınıyor. Ara yazılım eklemenin eski yolu engelleniyor.
değerini ile UseEndpoints
değiştirinUseSignalR
:
Eski kod:
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Yeni kod:
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
ASP.NET Core
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.
3.0
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.
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.
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:
Bu paketleri kullanıyorsanız, uygulamalarınızı şu işlevleri kullanacak şekilde güncelleştirin:
Microsoft.AspNetCore.SpaServices.Extensions
.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.Extensions
işlevi eski değildir ve desteklenmeye devam edecektir.
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
Microsoft.AspNetCore.SpaServices ve Microsoft.AspNetCore.NodeServices günlük yapılandırılmadığı sürece konsol günlüklerini görüntülemez.
3.0
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.
Microsoft.AspNetCore.SpaServices
ve Microsoft.AspNetCore.NodeServices
günlük yapılandırılmadığı sürece konsol günlüklerini görüntülemez.
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())
.
ASP.NET Core
Hiçbiri
.NET Framework, ASP.NET Core 3.0'dan başlayarak desteklenmeyen bir hedef çerçevedir.
.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.
3.0
ASP.NET Core uygulamaları .NET Core veya .NET Framework üzerinde çalıştırılabilir.
ASP.NET Core uygulamaları yalnızca .NET Core üzerinde çalıştırılabilir.
Aşağıdaki eylemlerden birini uygulayın:
ASP.NET Core
Hiçbiri
.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.
.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.
3.0
Yok. Bu değişiklik, sürüm algılamayı obtuse yerine sezgisel hale getirmelidir.
Core .NET kitaplıkları
Ö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.
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:
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.
Core .NET kitaplıkları
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.
.NET Core 2.2 ve önceki sürümlerde ve ile Double.ToString Single.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.
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.
Core .NET kitaplıkları
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
.
.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.
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.IsInfinity Single.IsInfinity true
test eden bir If
deyime gerekli kodları yerleştirmeniz gerekir.
Kodunuz kayan nokta değerlerinin olmadığını Infinity
varsayar. Bu durumda, ve NegativeInfinity
öğesinin kayan nokta değerlerini PositiveInfinity
denetlemek için gerekli kodu eklemeniz gerekir.
Core .NET kitaplıkları
Sınıf InvalidAsynchronousStateException taşındı.
.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.
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.
Core .NET kitaplıkları
Yok.
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.
.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: true
UTF8Encoding
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.
3.0
Geliştirici tarafından herhangi bir işlem yapılması gerekmez.
Core .NET kitaplıkları
Sınıf TypeDescriptionProviderAttribute taşındı.
.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.
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.
Windows Forms
Yok.
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.
.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.
3.0
Bu sorunları sergileyen tüm zip arşivlerini yeniden paketleyebilirsiniz.
Core .NET kitaplıkları
.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.
.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.
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.
Core .NET kitaplıkları
üzerinde alan bir uzantı yöntemini IEnumerable<T>
GroupCollectionçağırırken, türü tür ataması kullanarak kesinleştirmeniz gerekir.
.NET Core 3.0'dan başlayarak, System.Text.RegularExpressions.GroupCollection IEnumerable<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.
3.0
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);
Core .NET kitaplıkları
kabul eden herhangi bir IEnumerable<T> uzantı yöntemi etkilenir. Örneğin:
System.Linq.Enumerable
çoğu, örneğin, System.Linq.Enumerable.CountLinux 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.
Daha önce kök güven listesini doldurmak için hem hem de BEGIN CERTIFICATE
BEGIN 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.
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
Şifreleme
tarafından EnvelopedCms
kullanılan varsayılan simetrik şifreleme algoritması TripleDES'ten AES-256'ya 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();
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();
Şifreleme
Linux'ta yeni RSA anahtarları oluşturmanın en düşük boyutu 384 bitten 512 bit'e yükseltildi.
.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.
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.
Şifreleme
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.
.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.
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.
Şifreleme
İşlemleri CryptoStream.Dispose tamamlamak CryptoStream
için kullanılan yöntemi artık okurken son bloğu dönüştürmeye çalışmaz.
Önceki .NET sürümlerinde, kullanıcı modda kullanırken CryptoStream Read 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.
Bu değişiklik, bir özel durum yakalamaya gerek kalmadan bir ağ işlemi iptal edildiğinde şifreleme akışından tamamlanmamış okumaları etkinleştirir.
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.
Şifreleme
Entity Framework Core hataya neden olan değişiklikler
.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.
.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.
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.
Globalleştirme
Tüm harmanlama ve kültür API'leri bu değişiklikten etkilenir.
.NET Core 3.0'dan başlayarak, varsayılan durumda MSBuild kaynak dosyaları için farklı bir bildirim dosyası adı oluşturur.
3.0
.NET Core 3.0'dan önce, proje dosyasındaki bir EmbeddedResource
öğe için , ManifestResourceName
LogicalName
veya DependentUpon
meta veriler belirtilmemişse, MSBuild deseninde <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources
bir 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>.resources
bildirim 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 , ManifestResourceName
veya DependentUpon
meta verileriniz LogicalName
varsa, 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 false
ayarlarsanı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 EmbeddedResourceUseDependentUponConvention
false
yeni adlandırma kuralını geri çevirme.
<PropertyGroup>
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>
MSBuild
Yok
Özelliğin System.Net.Http.HttpRequestMessage.Version varsayılan değeri 2.0'dan 1.1'e değiştirildi.
3.0
.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.
Ağ
.NET Core 3.0, metin düzenleyici denetimlerinin metni başka bir System.Windows.DataObject denetime sürüklerken nasıl oluşturacağı konusunda bir değişiklik yaptı. Değişiklik otomatik dönüştürmeyi devre dışı bırakarak işlemin verileri olarak veya DataFormats.UnicodeText yerine olarak DataFormats.Text tutmasına DataFormats.StringFormatneden olur.
.NET Core 3.0
Windows Presentation Foundation
Metin düzenleyici denetiminden metin sürüklenirken üzerindeki System.Windows.DataObject veri türü oldu DataFormats.StringFormat.
Metin düzenleyicisi denetiminden metin sürüklenirken veri System.Windows.DataObject türü veya DataFormats.UnicodeTextşeklindedirDataFormats.Text.
Bu değişiklik davranışsal bir değişikliktir.
Değişiklik istemeden oldu.
Bu değişiklik .NET 7'de geri döndürüldü. .NET 7 veya sonraki bir sürümüne yükseltin.
.NET geri bildirimi
.NET, açık kaynak bir projedir. Geri bildirim sağlamak için bir bağlantı seçin:
Eğitim
Modül
ASP.NET Core Identity çerçevesi ile bir .NET web uygulamasının güvenliğini sağlama - Training
ASP.NET Core Identity çerçevesini kullanarak .NET web uygulamasına kimlik doğrulaması ve yetkilendirme eklemeyi öğrenin.
Belgeler
.NET Core 3.1'de hataya neden olan değişiklikler - .NET
.NET Core ve ASP.NET Core'un 3.1 sürümündeki hataya neden olan değişiklikleri listeler.
.NET Core 2.1'de hataya neden olan değişiklikler - .NET
.NET Core'un 2.1 sürümündeki hataya neden olan değişiklikleri listeler.
.NET 5'te hataya neden olan değişiklikler - .NET
.NET 5'te hataya neden olan değişikliklere gidin.