Školení
Modul
Zabezpečení webové aplikace .NET pomocí architektury ASP.NET Core Identity Framework - Training
Zjistěte, jak přidat ověřování a autorizaci do webové aplikace .NET pomocí architektury ASP.NET Core Identity Framework.
Tento prohlížeč se už nepodporuje.
Upgradujte na Microsoft Edge, abyste mohli využívat nejnovější funkce, aktualizace zabezpečení a technickou podporu.
Pokud migrujete na verzi 3.0 .NET Core, ASP.NET Core nebo EF Core, můžou zásadní změny uvedené v tomto článku ovlivnit vaši aplikaci.
Zastaralé členy a přepínače kompatibility v ASP.NET Core 2.2 byly odebrány.
3,0
Vylepšení povrchu rozhraní API v průběhu času
Při cílení na .NET Core 2.2 použijte místo toho nová rozhraní API podle pokynů v zastaralých zprávách sestavení.
ASP.NET Core
Následující typy a členy byly označeny jako zastaralé pro ASP.NET Core 2.1 a 2.2:
Typy
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
Konstruktory
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)
Vlastnosti
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
Metody
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)
Kvůli lepší údržbě veřejného rozhraní API ASP.NET Core se většina typů v *.Internal
oborech názvů (označovaných jako "pubternal" rozhraní API) stala skutečně interní. Členové v těchto oborech názvů nikdy neměli být podporováni jako veřejně přístupná rozhraní API. Rozhraní API se můžou porušit v menších verzích a často to udělala. Kód, který závisí na těchto rozhraních API, se při aktualizaci na ASP.NET Core 3.0 přeruší.
Další informace najdete v tématu dotnet/aspnetcore#4932 a dotnet/aspnetcore#11312.
3,0
Ovlivněná rozhraní API jsou označena modifikátorem public
přístupu a existují v *.Internal
oborech názvů.
Ovlivněná rozhraní API jsou označena modifikátorem interního přístupu a kódem mimo toto sestavení se už nedají používat.
Pokyny pro tato "pubternal" rozhraní API byly, že:
Ponechání rozhraní API (i v *.Internal
oborech názvů) bylo pro zákazníky public
matoucí.
Přestaňte tato "pubternal" rozhraní API používat. Pokud máte dotazy k alternativním rozhraním API, otevřete problém v úložišti dotnet/aspnetcore .
Představte si například následující kód vyrovnávací paměti požadavku HTTP v projektu ASP.NET Core 2.2. V EnableRewind
oboru názvů existuje Microsoft.AspNetCore.Http.Internal
metoda rozšíření.
HttpContext.Request.EnableRewind();
V projektu ASP.NET Core 3.0 nahraďte EnableRewind
voláním EnableBuffering
metody rozšíření. Funkce ukládání do vyrovnávací paměti požadavku funguje stejně jako v minulosti. EnableBuffering
volá teď internal
rozhraní API.
HttpContext.Request.EnableBuffering();
ASP.NET Core
Všechna rozhraní API v Microsoft.AspNetCore.*
názvech a Microsoft.Extensions.*
oborech názvů, která mají Internal
segment v názvu oboru názvů. Příklad:
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 začne od 28. ledna 2019 vypínat přihlášení Google+ pro aplikace.
ASP.NET 4.x a ASP.NET Core k ověřování uživatelů účtu Google ve webových aplikacích používala rozhraní API pro přihlášení Google+. Ovlivněné balíčky NuGet jsou Microsoft.AspNetCore.Authentication.Google pro ASP.NET Core a Microsoft.Owin.Security.Google pro Microsoft.Owin
ASP.NET Webové formuláře a MVC.
Náhradní rozhraní API Googlu používají jiný zdroj a formát dat. Omezení rizik a řešení uvedená níže představují strukturální změny. Aplikace by měly ověřit, že samotná data stále splňují jejich požadavky. Například jména, e-mailové adresy, odkazy na profil a profilové fotky můžou poskytovat méně odlišné hodnoty než dříve.
Všechny verze. Tato změna je externí pro ASP.NET Core.
Pro Microsoft.Owin
verzi 3.1.0 a novější je zde uvedeno dočasné zmírnění. Aplikace by měly dokončit testování s zmírněním rizik, aby zkontrolovaly změny ve formátu dat. Existují plány vydání Microsoft.Owin
verze 4.0.1 s opravou. Aplikace používající jakoukoli předchozí verzi by se měly aktualizovat na verzi 4.0.1.
Zmírnění rizik v Owinu s webovými formuláři ASP.NET a MVC je možné přizpůsobit na ASP.NET Core 1.x. Opravy balíčků NuGet se neplánují, protože verze 1.x dosáhla stavu konce životnosti .
Pro Microsoft.AspNetCore.Authentication.Google
verzi 2.x nahraďte stávající volání AddGoogle
Startup.ConfigureServices
následujícím kódem:
.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");
});
Opravy z února 2.1 a 2.2 obsahovaly předchozí rekonfiguraci jako nové výchozí. Pro ASP.NET Core 2.0 se neplánuje žádná oprava, protože dosáhla konce životnosti.
Omezení rizik pro ASP.NET Core 2.x se dá použít také pro ASP.NET Core 3.0. V budoucích verzích Microsoft.AspNetCore.Authentication.Google
Preview verze 3.0 může být balíček odebrán. Uživatelé budou přesměrováni na Microsoft.AspNetCore.Authentication.OpenIdConnect
místo toho. Následující kód ukazuje, jak nahradit AddGoogle
znakem AddOpenIdConnect
.Startup.ConfigureServices
Tuto náhradu je možné použít s ASP.NET Core 2.0 a novějším a podle potřeby ji můžete přizpůsobit pro ASP.NET Core 1.x.
.AddOpenIdConnect("Google", o =>
{
o.ClientId = Configuration["Authentication:Google:ClientId"];
o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
o.Authority = "https://accounts.google.com";
o.ResponseType = OpenIdConnectResponseType.Code;
o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
Zastaralá Authentication
vlastnost HttpContext
byla odebrána.
V rámci dotnet/aspnetcore#6504 se odebrala zastaralá Authentication
vlastnost HttpContext
. Vlastnost Authentication
je od verze 2.0 zastaralá. Průvodce migrací byl publikován pro migraci kódu pomocí této zastaralé vlastnosti do nových náhradních rozhraní API. Zbývající nepoužívané třídy / rozhraní API související se starým zásobníkem ověřování ASP.NET Core 1.x byly odebrány v potvrzení dotnet/aspnetcore@d7a7c65.
Diskuzi najdete v tématu dotnet/aspnetcore#6533.
3,0
ASP.NET rozhraní API Core 1.0 byly nahrazeny rozšiřujícími metodami v Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Prohlédnou si průvodce migrací.
ASP.NET Core
V ASP.NET Core 3.0 Newtonsoft.Json
byly typy používané v rozhraních API pro ověřování nahrazeny System.Text.Json
typy. S výjimkou následujících případů zůstává základní použití ověřovacích balíčků nedotčeno:
Další informace najdete v tématu dotnet/aspnetcore#7105. Diskuzi najdete v tématu dotnet/aspnetcore#7289.
3,0
U odvozených implementací OAuth je nejběžnější změnou nahradit JObject.Parse
přepsání JsonDocument.Parse
CreateTicketAsync
, jak je znázorněno zde. JsonDocument
implementuje IDisposable
.
Následující seznam popisuje známé změny:
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
. Všechny odvozené implementace jsou podobně ovlivněny ClaimAction
.MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
JObject
.JsonElement
Vlastnost User
a RunClaimActions
metoda byly aktualizovány tak, aby odpovídaly.JsonDocument
místo JObject
. Vlastnost Response
byla aktualizována tak, aby odpovídala. OAuthTokenResponse
je nyní na jedno použití a bude uvolněna OAuthHandler
. Odvozené implementace OAuth přepsání ExchangeCodeAsync
nemusí odstranit JsonDocument
nebo OAuthTokenResponse
.JObject
na JsonDocument
.JObject
na JsonElement
.JObject
na JsonElement
. Metoda nahrazení je TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).ASP.NET Core
V ASP.NET Core 3.0 se podpis změnil OAuthHandler.ExchangeCodeAsync
z:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }
Do:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }
3,0
Řetězce code
byly redirectUri
předány jako samostatné argumenty.
Code
a RedirectUri
jsou vlastnosti, které OAuthCodeExchangeContext
lze nastavit prostřednictvím konstruktoru OAuthCodeExchangeContext
. Nový OAuthCodeExchangeContext
typ je jediný argument předaný OAuthHandler.ExchangeCodeAsync
.
Tato změna umožňuje poskytnutí dalších parametrů jiným způsobem než zásadním způsobem. Není nutné vytvářet nová ExchangeCodeAsync
přetížení.
Vytvořte s OAuthCodeExchangeContext
příslušnými code
hodnotami a redirectUri
s odpovídajícími hodnotami. Je AuthenticationProperties nutné zadat instanci. Tuto jednu OAuthCodeExchangeContext
instanci je možné předat OAuthHandler.ExchangeCodeAsync
místo více argumentů.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
AddAuthorization
Základní metody použité k pobytu Microsoft.AspNetCore.Authorization
byly přejmenovány na AddAuthorizationCore
. Staré AddAuthorization
metody stále existují, ale jsou v Microsoft.AspNetCore.Authorization.Policy
sestavení. Aplikace používající obě metody by neměly mít žádný vliv. Všimněte si, že Microsoft.AspNetCore.Authorization.Policy
nyní se dodává ve sdíleném rozhraní místo samostatného balíčku, jak je popsáno ve sdíleném rozhraní: Sestavení odebraná z Microsoft.AspNetCore.App.
3,0
AddAuthorization
metody existovaly v Microsoft.AspNetCore.Authorization
.
AddAuthorization
metody existují v Microsoft.AspNetCore.Authorization.Policy
. AddAuthorizationCore
je nový název starých metod.
AddAuthorization
je lepší název metody pro přidání všech běžných služeb potřebných k autorizaci.
Buď přidejte odkaz nebo Microsoft.AspNetCore.Authorization.Policy
použijte AddAuthorizationCore
místo toho.
ASP.NET Core
Od ASP.NET Core 3.0 MVC nepřidá allowAnonymousFilters pro atributy [AllowAnonymous], které byly zjištěny u kontrolerů a metod akcí. Tato změna se řeší místně pro deriváty z AuthorizeAttribute, ale jedná se o zásadní změnu pro IAsyncAuthorizationFilter a IAuthorizationFilter implementace. Takové implementace zabalené do atributu [TypeFilter] jsou oblíbeným a podporovaným způsobem, jak dosáhnout autorizace založené na atributech, pokud jsou vyžadovány konfigurace i injektáž závislostí.
3,0
IAllowAnonymous v kolekci AuthorizationFilterContext.Filters . Testování přítomnosti rozhraní bylo platným přístupem k přepsání nebo zakázání filtru u jednotlivých metod kontroleru.
IAllowAnonymous
v kolekci se už nezobrazuje AuthorizationFilterContext.Filters
. IAsyncAuthorizationFilter
implementace závislé na starém chování obvykle způsobují přerušované odpovědi HTTP 401 Neautorizováno nebo HTTP 403 Zakázáno.
V ASP.NET Core 3.0 byla zavedena nová strategie směrování koncových bodů.
Vyhledejte metadata IAllowAnonymous
koncového bodu . Příklad:
var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}
Příkladem této techniky je tato metoda HasAllowAnonymous.
ASP.NET Core
Nic
V ASP.NET Core 3.0 byla do souboru přidána IAuthorizationPolicyProvider
nová GetFallbackPolicyAsync
metoda . Tuto záložní zásadu používá middleware autorizace, pokud není zadána žádná zásada.
Další informace najdete v tématu dotnet/aspnetcore#9759.
3,0
IAuthorizationPolicyProvider
Implementace nepožadovala metoduGetFallbackPolicyAsync
.
IAuthorizationPolicyProvider
Implementace vyžadují metoduGetFallbackPolicyAsync
.
Byla nutná nová metoda, AuthorizationMiddleware
která se má použít v případě, že není zadána žádná zásada.
Přidejte metodu GetFallbackPolicyAsync
do implementací .IAuthorizationPolicyProvider
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
Verze ASP.NET Core 3.0 odebrala zastaralá rozhraní API MemoryCacheOptions.
Tato změna je následná úprava aspnet/Caching#221. Diskuzi najdete v tématu dotnet/extensions#1062.
3,0
MemoryCacheOptions.CompactOnMemoryPressure
nemovitost byla k dispozici.
Vlastnost MemoryCacheOptions.CompactOnMemoryPressure
byla odebrána.
Automatické komprimace mezipaměti způsobila problémy. Aby nedocházelo k neočekávanému chování, mezipaměť by měla být komprimována pouze v případě potřeby.
Pokud chcete komprimovat mezipaměť, přepošlujte MemoryCache
ji a v případě potřeby zavolejte Compact
.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
Balíček Microsoft.Extensions.Caching.SqlServer
bude místo balíčku používat nový Microsoft.Data.SqlClient
balíček System.Data.SqlClient
. Tato změna může způsobit mírné změny způsobující chybu chování. Další informace naleznete v tématu Představujeme nový Microsoft.Data.SqlClient.
3,0
Balíček Microsoft.Extensions.Caching.SqlServer
použil balíček System.Data.SqlClient
.
Microsoft.Extensions.Caching.SqlServer
teď balíček používá Microsoft.Data.SqlClient
.
Microsoft.Data.SqlClient
je nový balíček, který je sestaven z System.Data.SqlClient
. Tady budou odteď fungovat všechny nové funkce.
Zákazníci by se neměli starat o tuto změnu způsobující chybu, pokud nepoužívali typy vrácené balíčkem Microsoft.Extensions.Caching.SqlServer
a přetypovali je na System.Data.SqlClient
typy. Pokud například někdo přetypoval na DbConnection
starý typ SqlConnection, museli by přetypování změnit na nový Microsoft.Data.SqlClient.SqlConnection
typ.
ASP.NET Core
Nic
V ASP.NET Core 3.0 byly změněny typy ResponseCaching
"pubternal" na internal
.
Kromě toho, výchozí implementace a IResponseCachingKeyProvider
již nejsou přidány IResponseCachingPolicyProvider
do služeb jako součást AddResponseCaching
metody.
V ASP.NET Core jsou typy "pubternal" deklarovány jako public
, ale nacházejí se v oboru názvů s příponou .Internal
. I když jsou tyto typy veřejné, nemají žádné zásady podpory a podléhají zásadním změnám. Náhodné použití těchto typů je bohužel běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti udržovat architekturu.
3,0
Tyto typy byly veřejně viditelné, ale nepodporované.
Tyto typy jsou nyní internal
.
Rozsah internal
lépe odráží nepodporované zásady.
Typy kopírování používané vaší aplikací nebo knihovnou
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
závisí na knihovnách Azure Storage. Tyto knihovny přejmenovaly svá sestavení, balíčky a obory názvů. Počínaje ASP.NET Core 3.0 Azure.Extensions.AspNetCore.DataProtection.Blobs
používá nová Azure.Storage.
rozhraní API a balíčky s předponou.
V případě dotazů k rozhraním API služby Azure Storage použijte https://github.com/Azure/azure-storage-net. Diskuzi o tomto problému najdete v tématu dotnet/aspnetcore#19570.
3,0
Balíček odkazoval na WindowsAzure.Storage
balíček NuGet.
Balíček odkazuje na Microsoft.Azure.Storage.Blob
balíček NuGet.
Balíček odkazuje na Azure.Storage.Blob
balíček NuGet.
Tato změna umožňuje Azure.Extensions.AspNetCore.DataProtection.Blobs
migrovat na doporučené balíčky Azure Storage.
Pokud stále potřebujete používat starší rozhraní API služby Azure Storage s ASP.NET Core 3.0, přidejte do balíčku WindowsAzure.Storage nebo Microsoft.Azure.Storage přímou závislost. Tento balíček lze nainstalovat společně s novými Azure.Storage
rozhraními API.
V mnoha případech upgrade zahrnuje pouze změnu using
příkazů tak, aby používaly nové obory názvů:
- 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
Nic
Počínaje ASP.NET Core 3.0 nebude sada Windows Hosting Bundle obsahovat AspNetCoreModule (ANCM) V1.
ANCM V2 je zpětně kompatibilní s funkcí ANCM OutOfProcess a doporučuje se pro použití s aplikacemi ASP.NET Core 3.0.
Diskuzi najdete v tématu dotnet/aspnetcore#7095.
3,0
ANCM V1 je součástí sady windows Hosting Bundle.
ANCM V1 není součástí hostitelské sady Windows.
ANCM V2 je zpětně kompatibilní s funkcí ANCM OutOfProcess a doporučuje se pro použití s aplikacemi ASP.NET Core 3.0.
Použijte ANCM V2 s aplikacemi ASP.NET Core 3.0.
Pokud se vyžaduje ANCM V1, můžete ho nainstalovat pomocí sady windows hostingu ASP.NET Core 2.1 nebo 2.2.
Tato změna přeruší ASP.NET aplikace Core 3.0, které:
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
.<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
příponou .ASP.NET Core
Nic
Jedinými typy, které obecný hostitel podporuje pro Startup
injektáž konstruktoru třídy, jsou IHostEnvironment
, IWebHostEnvironment
a IConfiguration
. Aplikace, které používají WebHost
, nemají vliv.
Před ASP.NET Core 3.0 lze injektáž konstruktoru použít pro libovolné typy v konstruktoru Startup
třídy. V ASP.NET Core 3.0 se webový zásobník přeformuloval do obecné knihovny hostitelů. Změnu uvidíte v souboru Program.cs šablon:
ASP.NET Core 2.x:
ASP.NET Core 3.0:
Host
k sestavení aplikace používá jeden kontejner injektáže závislostí (DI). WebHost
používá dva kontejnery: jeden pro hostitele a druhý pro aplikaci. V důsledku toho Startup
konstruktor už nepodporuje injektáž vlastních služeb. Pouze IHostEnvironment
, IWebHostEnvironment
a IConfiguration
mohou být vloženy. Tato změna zabraňuje problémům s DI, jako je duplicitní vytvoření služby singleton.
3,0
Tato změna je důsledkem opětovného vytvoření webového zásobníku na obecnou knihovnu hostitelů.
Vložte služby do Startup.Configure
podpisu metody. Příklad:
public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
ASP.NET Core
Nic
Verze 13.0.19218.0 modulu ASP.NET Core (ANCM) pro hostování prostřednictvím služby IIS mimo proces umožňuje existující funkci přesměrování HTTPS pro aplikace ASP.NET Core 3.0 a 2.2.
Diskuzi najdete v tématu dotnet/AspNetCore#15243.
3,0
Šablona projektu ASP.NET Core 2.1 poprvé zavedla podporu metod middlewaru HTTPS, jako jsou UseHttpsRedirection a UseHsts. Povolení přesměrování HTTPS vyžadovalo přidání konfigurace, protože aplikace ve vývoji nepoužívají výchozí port 443. Http Strict Transport Security (HSTS) je aktivní pouze v případě, že požadavek již používá HTTPS. Localhost se ve výchozím nastavení přeskočí.
V ASP.NET Core 3.0 byl vylepšen scénář HTTPS služby IIS. Díky vylepšení může aplikace zjistit porty HTTPS serveru a UseHttpsRedirection
ve výchozím nastavení fungovat. Komponenta v procesu dosáhla zjišťování portů pomocí IServerAddresses
funkce, která má vliv pouze na ASP.NET aplikace Core 3.0, protože knihovna v procesu má verzi s architekturou. Komponenta mimo proces se změnila tak, aby automaticky přidala proměnnou ASPNETCORE_HTTPS_PORT
prostředí. Tato změna ovlivnila aplikace ASP.NET Core 2.2 i 3.0, protože komponenta mimo proces se sdílí globálně. aplikace ASP.NET Core 2.1 nejsou ovlivněné, protože ve výchozím nastavení používají předchozí verzi ANCM.
Předchozí chování bylo změněno v ASP.NET Core 3.0.1 a 3.1.0 Preview 3, aby se změny chování v ASP.NET Core 2.x změnily. Tyto změny mají vliv jenom na zastaralé aplikace služby IIS.
Jak je popsáno výše, instalace ASP.NET Core 3.0.0 měla vedlejší vliv také na aktivaci middlewaru UseHttpsRedirection
v aplikacích ASP.NET Core 2.x. V systému ASP.NET Core 3.0.1 a 3.1.0 Preview 3 byla provedena změna ancm, takže jejich instalace už nemá tento vliv na aplikace ASP.NET Core 2.x. Proměnná ASPNETCORE_HTTPS_PORT
prostředí vyplněná v ASP.NET Core 3.0.0 se změnila na ASPNETCORE_ANCM_HTTPS_PORT
v ASP.NET Core 3.0.1 a 3.1.0 Preview 3. UseHttpsRedirection
v těchto verzích byla také aktualizována, aby porozuměla novým i starým proměnným. ASP.NET Core 2.x se neaktualizuje. V důsledku toho se ve výchozím nastavení vrátí k předchozímu chování zakázání.
Vylepšené funkce ASP.NET Core 3.0
Pokud chcete, aby všichni klienti používali protokol HTTPS, nevyžaduje se žádná akce. Pokud chcete některým klientům povolit používání protokolu HTTP, proveďte jeden z následujících kroků:
Odeberte volání do UseHttpsRedirection
a UseHsts
z metody projektu Startup.Configure
a znovu nasaďte aplikaci.
V souboru web.config nastavte ASPNETCORE_HTTPS_PORT
proměnnou prostředí na prázdný řetězec. K této změně může dojít přímo na serveru bez opětovného nasazení aplikace. Příklad:
<aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >
<environmentVariables>
<environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
</environmentVariables>
</aspNetCore>
UseHttpsRedirection
může být stále:
ASPNETCORE_HTTPS_PORT
proměnné prostředí na odpovídající číslo portu (443 ve většině produkčních scénářů).ASPNETCORE_ANCM_HTTPS_PORT
s prázdnou řetězcovou hodnotou. Tato hodnota je nastavena stejným způsobem jako předchozí ASPNETCORE_HTTPS_PORT
příklad.Počítače se spuštěnými aplikacemi ASP.NET Core 3.0.0 by měly nainstalovat modul runtime ASP.NET Core 3.0.1 před instalací ASP.NET Core 3.1.0 Preview 3 ANCM. Tím zajistíte, že UseHttpsRedirection
bude fungovat podle očekávání pro aplikace ASP.NET Core 3.0.
Ve službě Aplikace Azure service se ANCM nasadí podle samostatného plánu od modulu runtime z důvodu své globální povahy. Po nasazení ASP.NET Core 3.0.1 a 3.1.0 byla služba ANCM nasazena do Azure s těmito změnami.
ASP.NET Core
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Byly zavedeny nové typy pro nahrazení existujících IHostingEnvironment
a IApplicationLifetime
typů.
3,0
Byly dva různé IHostingEnvironment
a IApplicationLifetime
různé typy od Microsoft.Extensions.Hosting
a Microsoft.AspNetCore.Hosting
.
Staré typy byly označeny jako zastaralé a nahrazeny novými typy.
Když Microsoft.Extensions.Hosting
byl zaveden v ASP.NET Core 2.1, některé typy jako IHostingEnvironment
a IApplicationLifetime
byly zkopírovány z Microsoft.AspNetCore.Hosting
. Některé změny ASP.NET Core 3.0 způsobují, že aplikace budou obsahovat jak obory Microsoft.Extensions.Hosting
Microsoft.AspNetCore.Hosting
názvů, tak i obory názvů. Jakékoli použití těchto duplicitních typů způsobí chybu kompilátoru "nejednoznačný odkaz" při odkazování na oba obory názvů.
Nahraďte všechna použití starých typů nově zavedenými typy následujícím způsobem:
Zastaralé typy (upozornění):
Nové typy:
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
Nové IHostEnvironment
IsDevelopment
a IsProduction
rozšiřující metody jsou v Microsoft.Extensions.Hosting
oboru názvů. Tento obor názvů může být potřeba přidat do projektu.
ASP.NET Core
V rámci vytváření ASP.NET Core za hraní ObjectPoolProvider
se odebrala z hlavní sady závislostí. Konkrétní komponenty, které se teď spoléhají na ObjectPoolProvider
to, že je teď přidávají samy.
Diskuzi najdete v tématu dotnet/aspnetcore#5944.
3,0
WebHostBuilder
ve ObjectPoolProvider
výchozím nastavení v kontejneru DI.
WebHostBuilder
v kontejneru DI už není ve výchozím nastavení k dispozici ObjectPoolProvider
.
Tato změna byla provedena, aby ASP.NET Core více platit za hraní.
Pokud vaše komponenta vyžaduje ObjectPoolProvider
, musí být přidána do závislostí prostřednictvím nástroje IServiceCollection
.
ASP.NET Core
Nic
V rámci vylepšení výkonu ASP.NET Core 3.0 se rozšiřitelnost DefaultHttpContext
odebrala. Třída je nyní sealed
. Další informace najdete v tématu dotnet/aspnetcore#6504.
Pokud testy jednotek používají Mock<DefaultHttpContext>
, použijte Mock<HttpContext>
nebo new DefaultHttpContext()
místo toho.
Diskuzi najdete v tématu dotnet/aspnetcore#6534.
3,0
Třídy mohou být odvozeny z DefaultHttpContext
.
Třídy nemohou odvozovat .DefaultHttpContext
Rozšiřitelnost byla původně poskytována tak, aby umožňovala sdružování HttpContext
, ale zavedla zbytečnou složitost a bránila jiným optimalizacím.
Pokud používáte Mock<DefaultHttpContext>
testy jednotek, začněte místo toho používat Mock<HttpContext>
.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
Počínaje verzí ASP.NET Core 3.0 Preview 5 se pole změnila Microsoft.Net.Http.Headers.HeaderNames z const
na static readonly
.
Diskuzi najdete v tématu dotnet/aspnetcore#9514.
3,0
Tato pole bývala const
.
Tato pole jsou nyní static readonly
.
Změna:
Rekompilujte proti verzi 3.0. Zdrojový kód používající tato pole již nemůže provést následujícími způsoby:
case
Jako v switch
příkazuconst
Pokud chcete změnu způsobující chybu obejít, přepněte na konstanty názvu záhlaví definované vlastním jménem nebo řetězcové literály.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
Infrastruktura, která zálohuje tělo odpovědi HTTP, se změnila. Pokud používáte HttpResponse
přímo, neměli byste provádět žádné změny kódu. Přečtěte si další informace, pokud zabalíte nebo nahradíte HttpResponse.Body
nebo přistupujete.HttpContext.Features
3,0
K textu odpovědi HTTP jsou přidružená tři rozhraní API:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
Pokud nahradíte HttpResponse.Body
, nahradí celý IHttpResponseBodyFeature
obálkou kolem daného datového proudu pomocí StreamResponseBodyFeature
k poskytnutí výchozích implementací pro všechna očekávaná rozhraní API. Nastavení původního datového proudu vrátí tuto změnu zpět.
Motivací je zkombinovat rozhraní API těla odpovědi do jednoho nového rozhraní funkcí.
Použijte IHttpResponseBodyFeature
místo, kde jste dříve používali IHttpResponseFeature.Body
, IHttpSendFileFeature
nebo IHttpBufferingFeature
.
ASP.NET Core
SameSite
je možnost pro soubory cookie, které můžou pomoct zmírnit některé útoky CSRF (Cross-Site Request Forgery). Při počátečním zavedení této možnosti se v různých rozhraních API ASP.NET Core použily nekonzistentní výchozí hodnoty. Nekonzistence vedla k matoucím výsledkům. Od ASP.NET Core 3.0 jsou tato výchozí nastavení lépe zarovnaná. K této funkci se musíte přihlásit na základě jednotlivých komponent.
3,0
Podobná rozhraní API core ASP.NET používala různé výchozí SameSiteMode hodnoty. Příklad nekonzistence je vidět v HttpResponse.Cookies.Append(String, String)
a HttpResponse.Cookies.Append(String, String, CookieOptions)
, který je ve výchozím nastavení SameSiteMode.None
a SameSiteMode.Lax
v uvedeném pořadí.
Všechna ovlivněná rozhraní API mají výchozí hodnotu SameSiteMode.None
.
Výchozí hodnota byla změněna tak, aby se SameSite
funkce opt-in.
Každá komponenta, která generuje soubory cookie, se musí rozhodnout, jestli SameSite
je vhodná pro své scénáře. Zkontrolujte využití ovlivněných rozhraní API a podle potřeby změňte konfiguraci SameSite
.
ASP.NET Core
Počínaje ASP.NET Core 3.0 jsou synchronní operace serveru ve výchozím nastavení zakázané.
AllowSynchronousIO
je možnost na každém serveru, který povoluje nebo zakazuje synchronní vstupně-výstupní rozhraní API, jako HttpRequest.Body.Read
je , HttpResponse.Body.Write
a Stream.Flush
. Tato rozhraní API jsou již dlouho zdrojem hladovění vláken a aplikace přestane reagovat. Počínaje ASP.NET Core 3.0 Preview 3 jsou tyto synchronní operace ve výchozím nastavení zakázané.
Ovlivněné servery:
Očekávejte podobné chyby:
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.
Každý server má AllowSynchronousIO
možnost, která řídí toto chování a výchozí pro všechny z nich je nyní false
.
Chování lze také přepsat na základě jednotlivých požadavků jako dočasné zmírnění rizik. Příklad:
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Pokud máte potíže s synchronním rozhraním API Dispose
nebo jiným datovým TextWriter
proudem, zavolejte místo toho nové DisposeAsync
rozhraní API.
Diskuzi najdete v tématu dotnet/aspnetcore#7644.
3,0
HttpRequest.Body.Read
, HttpResponse.Body.Write
a Stream.Flush
byly ve výchozím nastavení povoleny.
Tato synchronní rozhraní API jsou ve výchozím nastavení zakázaná:
Očekávejte podobné chyby:
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.
Tato synchronní rozhraní API jsou již dlouho zdrojem hladovění vláken a aplikace přestane reagovat. Počínaje ASP.NET Core 3.0 Preview 3 jsou synchronní operace ve výchozím nastavení zakázané.
Použijte asynchronní verze metod. Chování lze také přepsat na základě jednotlivých požadavků jako dočasné zmírnění rizik.
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
ASP.NET Core
Počínaje ASP.NET Core 3.0 už přetížení metody IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) již neexistuje.
3,0
Tato změna byla výsledkem přijetí funkce statických webových prostředků.
Volání IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) namísto přetížení, které přebírá dva argumenty. Pokud používáte Bootstrap 3, přidejte do souboru projektu také následující řádek <PropertyGroup>
:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
Počínaje ASP.NET Core 3.0 se ve výchozím nastavení uživatelského rozhraní identity používá verze 4 bootstrap.
3,0
Volání services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
metody bylo stejné jako volání metody. services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
Volání services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
metody je stejné jako volání metody. services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
Bootstrap 4 byl vydán během časového rámce ASP.NET Core 3.0.
Tato změna se vás týká, pokud používáte výchozí uživatelské rozhraní identity a přidali jste ho Startup.ConfigureServices
, jak je znázorněno v následujícím příkladu:
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
Proveďte jednu z následujících akcí:
Pomocí průvodce migrací migrujte aplikaci tak, aby používala Bootstrap 4.
Aktualizace Startup.ConfigureServices
pro vynucení použití bootstrap 3 Příklad:
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
ASP.NET Core
Nic
Ve výchozím nastavení SignInAsync
vyvolá výjimku pro objekty zabezpečení / identity, ve kterých IsAuthenticated
je false
.
3,0
SignInAsync
přijímá všechny objekty zabezpečení / identity, včetně identit, v nichž IsAuthenticated
je false
.
Ve výchozím nastavení SignInAsync
vyvolá výjimku pro objekty zabezpečení / identity, ve kterých IsAuthenticated
je false
. K potlačení tohoto chování existuje nový příznak, ale výchozí chování se změnilo.
Staré chování bylo problematické, protože ve výchozím nastavení byly tyto objekty objekty odmítnuty [Authorize]
/ RequireAuthenticatedUser()
.
Ve verzi ASP.NET Core 3.0 Preview 6 je RequireAuthenticatedSignIn
true
ve výchozím nastavení příznakAuthenticationOptions
. Nastavte tento příznak tak, aby false
se obnovilo staré chování.
ASP.NET Core
Nic
Počínaje ASP.NET Core 3.0 se do konstruktoru SignInManager
přidal nový IUserConfirmation<TUser>
parametr. Další informace najdete v tématu dotnet/aspnetcore#8356.
3,0
Motivací ke změně bylo přidání podpory pro nové toky e-mailu a potvrzení ve službě Identity.
Pokud ručně vytváříte SignInManager
, poskytněte implementaci IUserConfirmation
nebo si ji vezměte z injektáže závislostí, která se má poskytnout.
ASP.NET Core
ASP.NET Core 3.0 zavedl funkci statických webových prostředků a uživatelské rozhraní identit ji přijalo.
V důsledku toho, že uživatelské rozhraní identit přijímá funkci statických webových prostředků:
IdentityUIFrameworkVersion
vlastnosti v souboru projektu.3,0
Výchozí rozhraní uživatelského rozhraní pro uživatelské rozhraní identity bylo Bootstrap 3. Rozhraní uživatelského rozhraní lze nakonfigurovat pomocí parametru AddDefaultUI
volání metody .Startup.ConfigureServices
Výchozí architektura uživatelského rozhraní pro uživatelské rozhraní identity je Bootstrap 4. Architektura uživatelského rozhraní musí být nakonfigurovaná v souboru projektu místo volání AddDefaultUI
metody.
Přijetí funkce statických webových prostředků vyžadovalo, aby se konfigurace architektury uživatelského rozhraní přesunula do nástroje MSBuild. Rozhodnutí o tom, která architektura se má vložit, je rozhodnutí o době sestavení, nikoli rozhodnutí o modulu runtime.
Zkontrolujte uživatelské rozhraní webu a ujistěte se, že jsou nové komponenty Bootstrap 4 kompatibilní. V případě potřeby použijte IdentityUIFrameworkVersion
vlastnost MSBuild k návratu na Bootstrap 3. Přidejte vlastnost do elementu <PropertyGroup>
v souboru projektu:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
V rámci přesunu k přesunu "pubternálních" rozhraní API do public
, koncept objektu IConnectionAdapter
byl odebrán z Kestrel. Adaptéry připojení se nahrazují middlewarem připojení (podobně jako middleware HTTP v kanálu ASP.NET Core, ale pro připojení nižší úrovně). Protokoly HTTPS a protokolování připojení se přesunuly z adaptérů připojení do middlewaru připojení. Tyto metody rozšíření by měly bez problémů fungovat, ale podrobnosti implementace se změnily.
Další informace najdete v tématu dotnet/aspnetcore#11412. Diskuzi najdete v tématu dotnet/aspnetcore#11475.
3,0
Komponenty rozšiřitelnosti Kestrel byly vytvořeny pomocí IConnectionAdapter
.
Komponenty rozšiřitelnosti Kestrel se vytvářejí jako middleware.
Tato změna je určená k zajištění flexibilnější architektury rozšiřitelnosti.
Převeďte všechny implementace IConnectionAdapter
pro použití nového vzoru middlewaru, jak je znázorněno zde.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Sestavení Microsoft.AspNetCore.Server.Kestrel.Https bylo odebráno.
3,0
V ASP.NET Core 2.1 se obsah Microsoft.AspNetCore.Server.Kestrel.Https
přesunul do Microsoft.AspNetCore.Server.Kestrel.Core. Tato změna se prováděla jiným způsobem než zásadním způsobem pomocí [TypeForwardedTo]
atributů.
Microsoft.AspNetCore.Server.Kestrel.Https
na verzi 2.0 by měly aktualizovat všechny závislosti jádra ASP.NET na verzi 2.1 nebo novější. Jinak se můžou při načtení do aplikace ASP.NET Core 3.0 přerušit.Microsoft.AspNetCore.Server.Kestrel.Https
balíček NuGet.ASP.NET Core
Nic
V předchozích verzích přidal Kestrel do kolekce hlaviček požadavků hlavičky blokovaných přívěsů HTTP/1.1, když se text požadavku načte na konec. Toto chování způsobilo obavy ohledně nejednoznačnosti mezi hlavičkami a přívěsy. Rozhodli jsme se přesunout přívěsy do nové kolekce.
Přívěsy požadavků HTTP/2 nebyly v ASP.NET Core 2.2 k dispozici, ale nyní jsou k dispozici také v této nové kolekci v ASP.NET Core 3.0.
Pro přístup k těmto přívěsům byly přidány nové metody rozšíření žádosti.
Po přečtení celého textu požadavku jsou k dispozici přívěsy HTTP/1.1.
Po přijetí z klienta jsou k dispozici přívěsy HTTP/2. Klient nebude posílat přívěsy, dokud server alespoň neusměrní celý text požadavku do vyrovnávací paměti. Možná budete muset přečíst text požadavku, aby se uvolnilo místo vyrovnávací paměti. Přívěsy jsou vždy k dispozici, pokud přečtete text požadavku na konec. Přívěsy označují konec těla.
3,0
Do kolekce by se přidaly HttpRequest.Headers
hlavičky žádosti o přívěs.
Hlavičky žádosti o přívěs nejsou v kolekci HttpRequest.Headers
k dispozici. Pro přístup k nim použijte následující metody HttpRequest
rozšíření:
GetDeclaredTrailers()
- Získá žádost "Přívěs" hlavička, která uvádí, které přívěsy mají očekávat po těle.SupportsTrailers()
- Označuje, zda žádost podporuje příjem hlaviček přívěsu.CheckTrailersAvailable()
- Určuje, zda žádost podporuje přívěsy a zda jsou k dispozici pro čtení.GetTrailer(string trailerName)
- Získá požadovanou koncovou hlavičku z odpovědi.Přívěsy jsou klíčovou funkcí ve scénářích, jako je gRPC. Sloučení přívěsů s hlavičkami požadavku bylo matoucí pro uživatele.
Pro přístup k přívěsům použijte metody HttpRequest
rozšíření související s přívěsem.
ASP.NET Core
V rámci přechodu z rozhraní API "pubternal" se rozhraní API přenosové vrstvy Kestrel zveřejňují jako veřejné rozhraní v knihovně Microsoft.AspNetCore.Connections.Abstractions
.
3,0
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
.ListenOptions.NoDelay
bylo k dispozici.IConnectionListener
bylo zavedeno v Microsoft.AspNetCore.Connections.Abstractions
knihovně, aby se z knihovny zpřístupnily ...Transport.Abstractions
nejpoužívanější funkce.NoDelay
je k dispozici v možnostech přenosu (LibuvTransportOptions
a SocketTransportOptions
).SchedulingMode
už není k dispozici.ASP.NET Core 3.0 se přesunula z rozhraní API "pubternal".
ASP.NET Core
Nic
ResourceManagerWithCultureStringLocalizer třídy a WithCulture interface člen jsou často zdrojem nejasnosti pro uživatele lokalizace, zejména při vytváření vlastní IStringLocalizer
implementace. Tyto položky dávají uživateli dojem, že IStringLocalizer
instance je "podle jazyka, podle prostředku". Ve skutečnosti by instance měly být pouze "pro jednotlivé prostředky". Hledaný jazyk je určen časem CultureInfo.CurrentUICulture
spuštění. Aby se zabránilo nejasnostem, rozhraní API byla v ASP.NET Core 3.0 označena jako zastaralá. Rozhraní API budou v budoucí verzi odebrána.
Kontext najdete v tématu dotnet/aspnetcore#3324. Diskuzi najdete v tématu dotnet/aspnetcore#7756.
3,0
Metody nebyly označeny jako Obsolete
.
Metody jsou označeny Obsolete
.
Rozhraní API představovala případ použití, který se nedoporučuje. Došlo k nejasnostem ohledně návrhu lokalizace.
Doporučujeme místo toho použít ResourceManagerStringLocalizer
. Nechte jazykovou verzi nastavit CurrentCulture
. Pokud to není možnost, vytvořte a použijte kopii ResourceManagerWithCultureStringLocalizer.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Před ASP.NET Core 3.0 DebugLogger
byl public
modifikátor přístupu . V ASP.NET Core 3.0 se modifikátor přístupu změnil na internal
.
3,0
Tato změna se provádí v následujících:
ConsoleLogger
.K povolení protokolování ladění použijte metodu AddDebug ILoggingBuilder
rozšíření. DebugLoggerProvider je stále public
v případě, že je potřeba službu zaregistrovat ručně.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
V rámci adresování dotnet/aspnetcore#4849 ASP.NET Core MVC ve výchozím nastavení oříznou příponu Async
z názvů akcí. Počínaje ASP.NET Core 3.0 má tato změna vliv na generování směrování i propojení.
3,0
Zvažte následující ASP.NET kontroleru Core MVC:
public class ProductController : Controller
{
public async IActionResult ListAsync()
{
var model = await DbContext.Products.ToListAsync();
return View(model);
}
}
Akce je směrovatelná přes Product/ListAsync
. Generování propojení vyžaduje zadání přípony Async
. Příklad:
<a asp-controller="Product" asp-action="ListAsync">List</a>
V ASP.NET Core 3.0 je akce směrovatelná přes Product/List
. Kód generování propojení by měl vynechat příponu Async
. Příklad:
<a asp-controller="Product" asp-action="List">List</a>
Tato změna nemá vliv na názvy zadané pomocí atributu [ActionName]
. Nové chování je možné zakázat nastavením MvcOptions.SuppressAsyncSuffixInActionNames
v:false
Startup.ConfigureServices
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Podle konvence jsou asynchronní metody .NET příponou Async
. Pokud však metoda definuje akci MVC, je nežádoucí použít příponu Async
.
Pokud vaše aplikace závisí na akcích MVC, které zachová příponu Async
názvu, zvolte jednu z následujících omezení rizik:
[ActionName]
K zachování původního názvu použijte atribut.false
:Startup.ConfigureServices
MvcOptions.SuppressAsyncSuffixInActionNames
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
Nic
JsonResult
byla přesunuta do Microsoft.AspNetCore.Mvc.Core
sestavení. Tento typ se používá k definování v Souboru Microsoft.AspNetCore.Mvc.Formatters.Json. Byl přidán atribut [TypeForwardedTo] na úrovni sestavení, aby Microsoft.AspNetCore.Mvc.Formatters.Json
se tento problém vyřešil pro většinu uživatelů. Aplikace, které používají knihovny třetích stran, můžou narazit na problémy.
3.0 Preview 6
Aplikace, která úspěšně sestavuje knihovnu založenou na 2.2
Kompilace aplikace využívající knihovnu založenou na verzi 2.2 selže. Zobrazí se chyba obsahující variantu následujícího textu:
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'
Příklad takového problému najdete v tématu dotnet/aspnetcore#7220.
Změny na úrovni platformy ve složení ASP.NET Core, jak je popsáno v aspnet/Announcements#325.
Knihovny kompilované ve verzi Microsoft.AspNetCore.Mvc.Formatters.Json
2.2 může být potřeba znovu zkompilovat, aby se problém vyřešil pro všechny uživatele. Pokud se to týká, obraťte se na autora knihovny. Požádejte o rekompilace knihovny tak, aby cílila na ASP.NET Core 3.0.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
V ASP.NET Core 1.1 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
byl zaveden balíček (nástroj pro předkompilace MVC) pro přidání podpory pro kompilaci souborů Razor (soubory .cshtml ). V ASP.NET Core 2.1 byla sada Razor SDK zavedena, aby se rozšířila o funkce nástroje pro předkompilace. Sada Razor SDK přidala podporu pro kompilaci souborů Razor a jejich čas publikování. Sada SDK ověřuje správnost souborů .cshtml v době sestavení a současně vylepšuje dobu spuštění aplikace. Sada Razor SDK je ve výchozím nastavení zapnutá a k jejímu spuštění není potřeba žádné gesto.
V ASP.NET Core 3.0 se odebral nástroj prekompilace MVC ASP.NET Core 1.1.1. Starší verze balíčků budou dál dostávat důležité chyby a opravy zabezpečení v vydání opravy.
3,0
Balíček Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
se použil k předběžné kompilaci zobrazení Razor MVC.
Sada Razor SDK nativně podporuje tuto funkci. Balíček Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
se už neaktualizuje.
Sada Razor SDK poskytuje více funkcí a ověřuje správnost souborů .cshtml v době sestavení. Sada SDK také zlepšuje dobu spuštění aplikace.
Pro uživatele ASP.NET Core 2.1 nebo novější aktualizujte tak, aby používali nativní podporu pro předkompilace v sadě Razor SDK. Pokud chyby nebo chybějící funkce brání migraci do sady Razor SDK, otevřete problém na adrese dotnet/aspnetcore.
ASP.NET Core
Nic
V ASP.NET Core 3.0 byly všechny typy "pubternal" v MVC aktualizovány tak, aby byly public
buď v podporovaném oboru názvů, nebo internal
podle potřeby.
V ASP.NET Core se typy pubternal deklarují jako public
typy s příponou -, ale nacházejí se v oboru názvů s příponou .Internal
-. I když se jedná public
o tyto typy, nemají žádné zásady podpory a podléhají zásadním změnám. Náhodné použití těchto typů je bohužel běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti udržovat architekturu.
3,0
Některé typy v MVC byly public
ale v .Internal
oboru názvů. Tyto typy neměly žádné zásady podpory a podléhaly zásadním změnám.
Všechny tyto typy se aktualizují tak, aby byly public
v podporovaném oboru názvů nebo byly označeny jako internal
.
Náhodné použití "pubternálních" typů bylo běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti udržovat architekturu.
Pokud používáte typy, které se skutečně public
staly a byly přesunuty do nového podporovaného oboru názvů, aktualizujte odkazy tak, aby odpovídaly novým oborům názvů.
Pokud používáte typy, které jsou označené jako internal
, budete muset najít alternativu. Dříve "pubternální" typy nebyly nikdy podporovány pro veřejné použití. Pokud jsou v těchto oborech názvů určité typy, které jsou pro vaše aplikace důležité, zapište problém na adrese dotnet/aspnetcore. Je možné vzít v úvahu požadavky na typy public
.
ASP.NET Core
Tato změna zahrnuje typy v následujících oborech názvů:
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
Počínaje verzí ASP.NET Core 3.0 Microsoft.AspNetCore.Mvc.WebApiCompatShim
už balíček není k dispozici.
Balíček Microsoft.AspNetCore.Mvc.WebApiCompatShim
(WebApiCompatShim) poskytuje částečnou kompatibilitu v ASP.NET Core s webovým rozhraním API 2 ASP.NET 4.x, aby se zjednodušila migrace stávajících implementací webového rozhraní API na ASP.NET Core. Aplikace využívající WebApiCompatShim ale nemají prospěch z funkcí souvisejících s rozhraním API v posledních verzích ASP.NET Core. Mezi tyto funkce patří vylepšené generování specifikace Open API, standardizované zpracování chyb a generování kódu klienta. Aby se lépe zaměřilo úsilí rozhraní API ve verzi 3.0, webApiCompatShim byl odebrán. Stávající aplikace používající WebApiCompatShim by se měly migrovat na novější [ApiController]
model.
3,0
Shim kompatibility webového rozhraní API byl nástroj pro migraci. Omezuje přístup uživatelů k novým funkcím přidanám v ASP.NET Core.
Odeberte použití tohoto shimu a migrujte přímo na podobné funkce v samotném ASP.NET Core.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
Rozhraní RazorTemplateEngine
API bylo odebráno a nahrazeno znakem Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
.
Diskuzi najdete v tématu o problému GitHubu dotnet/aspnetcore#25215.
3,0
Modul šablony lze vytvořit a použít k analýze a generování kódu pro soubory Razor.
RazorProjectEngine
lze vytvořit a poskytnout stejný typ informací, jako RazorTemplateEngine
je parsování a generování kódu pro soubory Razor. RazorProjectEngine
poskytuje také další úrovně konfigurace.
RazorTemplateEngine
byla příliš úzce svázána s existujícími implementacemi. Tato úzká spojka vedla k dalším otázkám při pokusu o správnou konfiguraci kanálu analýzy a generování Razor.
Používejte RazorProjectEngine
místo RazorTemplateEngine
. Podívejte se na následující příklady.
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
Podpora kompilace běhových zobrazení Razor a Razor Pages se přesunula do samostatného balíčku.
3,0
Kompilace modulu runtime je k dispozici bez nutnosti dalších balíčků.
Funkce byla přesunuta do balíčku Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
Pro podporu kompilace modulu runtime byly dříve k dispozici Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
následující rozhraní API. Rozhraní API jsou nyní k dispozici prostřednictvím Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions
.
RazorViewEngineOptions.FileProviders
je teď MvcRazorRuntimeCompilationOptions.FileProviders
RazorViewEngineOptions.AdditionalCompilationReferences
je teď MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths
Kromě toho Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange
byla odebrána. Rekompilace změn souboru je ve výchozím nastavení povolena odkazem na Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
balíček.
Tato změna byla nutná k odebrání závislosti sdílené architektury ASP.NET Core na Roslynu.
Aplikace, které vyžadují kompilaci modulu runtime nebo rekompilace souborů Razor, by měly provést následující kroky:
Přidejte odkaz na Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
balíček.
Aktualizujte metodu projektu Startup.ConfigureServices
tak, aby zahrnovala volání AddRazorRuntimeCompilation
. Příklad:
services.AddMvc()
.AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Byla odebrána zastaralá rozhraní API pro konfiguraci souborů cookie relace. Další informace najdete v tématu aspnet/Announcements#257.
3,0
Tato změna vynucuje konzistenci napříč rozhraními API pro konfiguraci funkcí, které používají soubory cookie.
Migrace využití odebraných rozhraní API na novější nahrazení Podívejte se na následující příklad v Startup.ConfigureServices
:
public void ConfigureServices(ServiceCollection services)
{
services.AddSession(options =>
{
// Removed obsolete APIs
options.CookieName = "SessionCookie";
options.CookieDomain = "contoso.com";
options.CookiePath = "/";
options.CookieHttpOnly = true;
options.CookieSecure = CookieSecurePolicy.Always;
// new API
options.Cookie.Name = "SessionCookie";
options.Cookie.Domain = "contoso.com";
options.Cookie.Path = "/";
options.Cookie.HttpOnly = true;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});
}
ASP.NET Core
Počínaje ASP.NET Core 3.0 obsahuje sdílená architektura ASP.NET Core (Microsoft.AspNetCore.App
) pouze sestavení první strany, která jsou plně vyvinutá, podporovaná a použitelná microsoftem.
Změnu si můžete představit jako předdefinování hranic pro platformu ASP.NET Core. Sdílená architektura bude zdrojově sestavitelná kýmkoli prostřednictvím GitHubu a bude i nadále nabízet stávající výhody sdílených architektur .NET Core pro vaše aplikace. Mezi výhody patří menší velikost nasazení, centralizované opravy a rychlejší spuštění.
V rámci této změny jsou zavedeny Microsoft.AspNetCore.App
některé zásadní změny .
3,0
Projekty odkazované Microsoft.AspNetCore.App
prostřednictvím <PackageReference>
elementu v souboru projektu.
Kromě toho Microsoft.AspNetCore.App
obsahovaly následující dílčí podkomponenty:
Newtonsoft.Json
)Microsoft.EntityFrameworkCore.
)Microsoft.CodeAnalysis
)Odkaz, který Microsoft.AspNetCore.App
už nevyžaduje <PackageReference>
prvek v souboru projektu. Sada .NET Core SDK podporuje nový prvek s názvem <FrameworkReference>
, který nahrazuje použití <PackageReference>
.
Další informace najdete v tématu dotnet/aspnetcore#3612.
Entity Framework Core se dodává jako balíčky NuGet. Tato změna zarovná model expedice se všemi ostatními knihovnami pro přístup k datům v .NET. Poskytuje Entity Framework Core nejjednodušší způsob, jak pokračovat v inovování a zároveň podporovat různé platformy .NET. Přesun Entity Framework Core ze sdílené architektury nemá žádný vliv na její stav jako knihovnu vyvinutou, podporovanou a použitelnou microsoftem. Zásady podpory .NET Core se i nadále týkají.
Json.NET a Entity Framework Core nadále pracují s ASP.NET Core. Nebudou však zahrnuty do sdílené architektury.
Další informace najdete v tématu Budoucnost JSON v .NET Core 3.0. Podívejte se také na úplný seznam binárních souborů odebraných ze sdílené architektury.
Tato změna zjednodušuje spotřebu Microsoft.AspNetCore.App
balíčků NuGet a sdílených architektur a snižuje jejich duplicitu.
Další informace o motivaci k této změně najdete v tomto blogovém příspěvku.
Počínaje ASP.NET Core 3.0 už není nutné, aby projekty spotřebovávají sestavení jako Microsoft.AspNetCore.App
balíčky NuGet. Kvůli zjednodušení cílení a použití sdílené architektury ASP.NET Core se řada balíčků NuGet dodává, protože ASP.NET Core 1.0 se už nevygenerují. Rozhraní API, která tyto balíčky poskytují, jsou stále k dispozici pro aplikace pomocí <FrameworkReference>
Microsoft.AspNetCore.App
Mezi běžné příklady rozhraní API patří Kestrel, MVC a Razor.
Tato změna se nevztahuje na všechny binární soubory odkazované prostřednictvím Microsoft.AspNetCore.App
ASP.NET Core 2.x. Mezi velmi vhodné výjimky patří:
Microsoft.Extensions
knihovny, které nadále cílí na .NET Standard, jsou k dispozici jako balíčky NuGet (viz https://github.com/dotnet/extensions).Microsoft.AspNetCore.App
. Například následující komponenty jsou k dispozici jako balíčky NuGet: Další informace naleznete v tématu Zastavení vytváření balíčků pro sestavení sdílených architektur v 3.0. Diskuzi najdete v tématu dotnet/aspnetcore#3757.
ASP.NET Core
Počínaje ASP.NET Core 3.0 Microsoft.AspNetCore.All
se metabalík a odpovídající Microsoft.AspNetCore.All
sdílená architektura už nevygenerují. Tento balíček je k dispozici v ASP.NET Core 2.2 a bude nadále dostávat servisní aktualizace v ASP.NET Core 2.1.
3,0
Aplikace můžou metabalíč použít Microsoft.AspNetCore.All
k cílení na sdílenou architekturu Microsoft.AspNetCore.All
v .NET Core.
.NET Core 3.0 neobsahuje sdílenou architekturu Microsoft.AspNetCore.All
.
Metabalíčky Microsoft.AspNetCore.All
obsahovaly velký počet externích závislostí.
Migrujte projekt tak, aby používal architekturu Microsoft.AspNetCore.App
. Komponenty, které byly dříve dostupné, Microsoft.AspNetCore.All
jsou stále dostupné na NuGetu. Tyto komponenty se teď nasazují s vaší aplikací místo toho, aby se zahrnuly do sdílené architektury.
ASP.NET Core
Nic
Pole HandshakeProtocol.SuccessHandshakeData bylo odebráno a nahrazeno pomocnou metodou, která vygeneruje úspěšnou odpověď handshake vzhledem ke konkrétnímu IHubProtocol
.
3,0
HandshakeProtocol.SuccessHandshakeData
public static ReadOnlyMemory<byte>
bylo pole.
HandshakeProtocol.SuccessHandshakeData
byla nahrazena metodou static
GetSuccessfulHandshake(IHubProtocol protocol)
, která vrací ReadOnlyMemory<byte>
na základě zadaného protokolu.
Do odpovědi handshake byly přidána další pole, která nejsou konstantní a mění se v závislosti na vybraném protokolu.
Nezaokrouhlovat. Tento typ není určený pro použití z uživatelského kódu. public
Je to proto, aby bylo možné ho sdílet mezi serverem SignalR a klientem. Mohou ho také používat klienti SignalR pro zákazníky napsané v .NET. Na uživatele služby SignalR by tato změna neměla mít vliv.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
Metody ResetSendPing
a ResetTimeout
metody byly odebrány z rozhraní API služby SignalR HubConnection
. Tyto metody byly původně určeny pouze pro interní použití, ale byly zpřístupněny ve ASP.NET Core 2.2. Tyto metody nebudou dostupné od verze ASP.NET Core 3.0 Preview 4. Diskuzi najdete v tématu dotnet/aspnetcore#8543.
3,0
K dispozici byla rozhraní API.
Rozhraní API se odeberou.
Tyto metody byly původně určeny pouze pro interní použití, ale byly zpřístupněny ve ASP.NET Core 2.2.
Tyto metody nepoužívejte.
ASP.NET Core
Konstruktory služby SignalR HubConnectionContext
se změnily tak, aby přijímaly typ možností, nikoli více parametrů, na možnosti pro budoucí kontrolu pravopisu. Tato změna nahrazuje dva konstruktory jedním konstruktorem, který přijímá typ možností.
3,0
HubConnectionContext
má dva konstruktory:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
Dva konstruktory byly odebrány a nahrazeny jedním konstruktorem:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
Nový konstruktor používá nový objekt možností. V důsledku toho lze v budoucnu rozšířit funkce HubConnectionContext
, aniž by bylo nutné provádět další konstruktory a rozbíjející změny.
Místo použití následujícího konstruktoru:
HubConnectionContext connectionContext = new HubConnectionContext(
connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Použijte následující konstruktor:
HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);
ASP.NET Core
V ASP.NET Core 3.0 Preview 7 se název balíčku klienta SignalR JavaScript změnil z @aspnet/signalr
na @microsoft/signalr
. Změna názvu odráží skutečnost, že služba SignalR je užitečná ve více než jen ASP.NET aplikacích Core, a to díky službě Azure SignalR.
Pokud chcete na tuto změnu reagovat, změňte odkazy ve vašich package.json souborech, require
příkazech a příkazech ECMAScript import
. V rámci tohoto přejmenování se nezmění žádné rozhraní API.
Diskuzi najdete v tématu dotnet/aspnetcore#11637.
3,0
Klientský balíček byl pojmenován @aspnet/signalr
.
Klientský balíček má název @microsoft/signalr
.
Změna názvu vysvětluje, že služba SignalR je užitečná mimo ASP.NET aplikací Core, a to díky službě Azure SignalR.
Přepněte na nový balíček @microsoft/signalr
.
ASP.NET Core
Nic
Metody UseConnections
a UseSignalR
třídy ConnectionsRouteBuilder
a HubRouteBuilder
jsou označené jako zastaralé v ASP.NET Core 3.0.
3,0
Směrování rozbočovače SignalR bylo nakonfigurováno pomocí UseSignalR
nebo UseConnections
.
Starý způsob konfigurace směrování byl zastaralý a nahrazen směrováním koncového bodu.
Middleware se přesouvá do nového systému směrování koncových bodů. Starý způsob přidávání middlewaru je zastaralý.
NahraditUseSignalR
:UseEndpoints
Starý kód:
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Nový kód:
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
ASP.NET Core
Obsah následujících balíčků NuGet byl od ASP.NET Core 2.1 nepotřebný. V důsledku toho jsou následující balíčky označeny jako zastaralé:
Z stejného důvodu jsou následující moduly npm označené jako zastaralé:
Předchozí balíčky a moduly npm se později odeberou v .NET 5.
3,0
Zastaralé balíčky a moduly npm byly určeny k integraci ASP.NET Core s různými architekturami jednostránkové aplikace (SPA). Mezi tyto architektury patří Angular, React a React s Reduxem.
V balíčku NuGet Microsoft.AspNetCore.SpaServices.Extensions existuje nový mechanismus integrace. Balíček zůstává základem šablon projektů Angular a React od ASP.NET Core 2.1.
ASP.NET Core podporuje integraci s různými architekturami jednostránkové aplikace (SPA), včetně Angular, React a React s Reduxem. Integrace s těmito architekturami byla zpočátku provedena s komponentami specifických pro ASP.NET Core, které zpracovávaly scénáře, jako je předkončování na straně serveru a integrace s Webpackem. Jak to bylo v čase, oborové standardy se změnily. Každá z architektur SPA vydala vlastní standardní rozhraní příkazového řádku. Například Angular CLI a create-react-app.
Když byl ASP.NET Core 2.1 vydán v květnu 2018, tým odpověděl na změnu standardů. Byl poskytnut novější a jednodušší způsob integrace s vlastními sadami nástrojů architektury SPA. Nový integrační mechanismus existuje v balíčku Microsoft.AspNetCore.SpaServices.Extensions
a zůstává základem šablon projektů Angular a React od ASP.NET Core 2.1.
Abychom si vysvětlili, že starší komponenty specifické pro jádro ASP.NET nejsou relevantní a nedoporučuje se:
Pokud používáte tyto balíčky, aktualizujte aplikace tak, aby používaly tyto funkce:
Microsoft.AspNetCore.SpaServices.Extensions
V balíčku.Pokud chcete povolit funkce, jako je předrenderování na straně serveru a opětovné načtení horkého modulu, přečtěte si dokumentaci pro odpovídající architekturu SPA. Funkce není Microsoft.AspNetCore.SpaServices.Extensions
zastaralá a bude nadále podporována.
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 a Microsoft.AspNetCore.NodeServices nezobrazí protokoly konzoly, pokud není nakonfigurované protokolování.
3,0
Microsoft.AspNetCore.SpaServices
a Microsoft.AspNetCore.NodeServices
používá se k automatickému vytvoření protokolovacího nástroje konzoly, pokud není nakonfigurované protokolování.
Microsoft.AspNetCore.SpaServices
a Microsoft.AspNetCore.NodeServices
nezobrazí protokoly konzoly, pokud není nakonfigurované protokolování.
Je potřeba sladit s tím, jak ostatní balíčky ASP.NET Core implementují protokolování.
Pokud je požadováno staré chování, ke konfiguraci protokolování konzoly přidejte services.AddLogging(builder => builder.AddConsole())
do své Setup.ConfigureServices
metody.
ASP.NET Core
Nic
Počínaje ASP.NET Core 3.0 je .NET Framework nepodporovanou cílovou architekturou.
.NET Framework 4.8 je poslední hlavní verzí rozhraní .NET Framework. Nové aplikace ASP.NET Core by měly být založené na .NET Core. Počínaje verzí .NET Core 3.0 si můžete představit ASP.NET Core 3.0 jako součást .NET Core.
Zákazníci, kteří používají ASP.NET Core s rozhraním .NET Framework, můžou v plně podporované verzi 2.1 LTS pokračovat. Podpora a údržba pro verzi 2.1 pokračuje až do 21. srpna 2021. Toto datum je tři roky po deklaraci verze LTS podle zásad podpory .NET. Podpora balíčků ASP.NET Core 2.1 v rozhraní .NET Framework se bude neomezeně rozšiřovat, podobně jako zásady údržby pro jiné architektury založené na balíčcích ASP.NET.
Další informace o přenosu z rozhraní .NET Framework do .NET Core najdete v tématu Portování do .NET Core.
Microsoft.Extensions
na balíčky (například protokolování, injektáž závislostí a konfigurace) a Entity Framework Core to nemá vliv. Budou i nadále podporovat .NET Standard.
Další informace o motivaci k této změně najdete v původním blogovém příspěvku.
3,0
ASP.NET aplikace Core se můžou spouštět na rozhraní .NET Core nebo .NET Framework.
ASP.NET aplikace Core je možné spouštět pouze v .NET Core.
Proveďte jednu z následujících akcí:
ASP.NET Core
Nic
Mnoho rozhraní API, která vrací verze v .NET Core, teď vrací verzi produktu, nikoli verzi souboru.
V .NET Core 2.2 a předchozích verzích, metody, jako Environment.VersionRuntimeInformation.FrameworkDescriptionje , a dialogové okno vlastností souboru pro sestavení .NET Core odráží verzi souboru. Počínaje .NET Core 3.0 odrážejí verzi produktu.
Následující obrázek znázorňuje rozdíl v informacích o verzi pro sestavení System.Runtime.dll pro .NET Core 2.2 (vlevo) a .NET Core 3.0 (vpravo), jak je znázorněno v dialogovém okně vlastností souboru Průzkumníka Windows.
3,0
Nezaokrouhlovat. Tato změna by měla intuitivně intuitivně rozpoznávat verze, ne obtěžovat.
Knihovny Core .NET
Vlastní EncoderFallbackBuffer instance se nedají rekurzivně vrátit. Implementace EncoderFallbackBuffer.GetNextChar() musí mít za následek posloupnost znaků, která se konvertibilní na cílové kódování. V opačném případě dojde k výjimce.
Během operace převodu znaků na bajt modul runtime zjistí špatně vytvořené nebo nekonvertovatelné sekvence UTF-16 a poskytne těmto znakům metodu EncoderFallbackBuffer.Fallback . Metoda Fallback
určuje, které znaky mají být nahrazeny původními nekonvertitelnými daty, a tyto znaky jsou vyprázdněné voláním EncoderFallbackBuffer.GetNextChar smyčky.
Modul runtime se pak pokusí tyto znaky nahrazení překódovat do cílového kódování. Pokud je tato operace úspěšná, modul runtime pokračuje v překódování z místa, kde skončil v původním vstupním řetězci.
Dříve vlastní implementace EncoderFallbackBuffer.GetNextChar() mohou vracet sekvence znaků, které nejsou konvertibilní na cílové kódování. Pokud nahrazené znaky nelze překódovat do cílového kódování, modul runtime vyvolá EncoderFallbackBuffer.Fallback metodu znovu s náhradními znaky a očekává, že EncoderFallbackBuffer.GetNextChar() metoda vrátí novou náhradní sekvenci. Tento proces pokračuje, dokud modul runtime nakonec neuvidí správně formátovanou, konvertibilní náhradu nebo dokud se nedosáhne maximálního počtu rekurzí.
Od verze .NET Core 3.0 musí vlastní implementace EncoderFallbackBuffer.GetNextChar() vracet sekvence znaků, které jsou konvertibilní na cílové kódování. Pokud náhradní znaky nelze překódovat do cílového kódování, vyvolá se chyba ArgumentException . Modul runtime už nebude provádět rekurzivní volání instance EncoderFallbackBuffer .
Toto chování platí pouze v případě, že jsou splněny všechny tři z následujících podmínek:
3,0
Většinavývojářůch
Pokud aplikace používá vlastní EncoderFallback a EncoderFallbackBuffer třídu, ujistěte se, že implementace EncoderFallbackBuffer.Fallback záložní vyrovnávací paměti s dobře vytvořenými daty UTF-16, která jsou přímo konvertibilní na cílové kódování při Fallback prvním vyvolání metody modulem runtime.
Knihovny Core .NET
Chování při analýze a formátování s plovoucí desetinou čárkou (podle typů Double Single ) je teď kompatibilní se standardem IEEE. Tím zajistíte, že chování typů s plovoucí desetinou čárkou v rozhraní .NET odpovídá chování jiných jazyků kompatibilních se standardem IEEE. Například by se měl vždy shodovat s tím, double.Parse("SomeLiteral")
co jazyk C# vytvoří .double x = SomeLiteral
V .NET Core 2.2 a starších verzích formátování pomocí a Single.ToStringparsování pomocí , Double.TryParseSingle.Parsea Single.TryParse nejsou kompatibilní se standardem Double.ToString Double.ParseIEEE. V důsledku toho není možné zaručit, že se hodnota zaokrouhlí s jakýmkoli podporovaným standardním nebo vlastním formátovacím řetězcem. U některých vstupů může pokus o parsování formátované hodnoty selhat a u jiných se analyzovaná hodnota nerovná původní hodnotě.
Počínaje .NET Core 3.0 jsou operace analýzy a formátování s plovoucí desetinou čárkou kompatibilní se standardem IEEE 754.
Následující tabulka ukazuje dva fragmenty kódu a způsob změny výstupu mezi .NET Core 2.2 a .NET Core 3.1.
Fragment kódu | Výstup v .NET Core 2.2 | Výstup v .NET Core 3.1 |
---|---|---|
Console.WriteLine((-0.0).ToString()); |
0 | 0 až |
var value = -3.123456789123456789; Console.WriteLine(value == double.Parse(value.ToString())); |
False |
True |
Další informace najdete v blogovém příspěvku .NET Core 3.0 o parsování a formátování s plovoucí desetinou čárkou.
3,0
Potenciální dopad na existující část kódu vylepšení parsování a formátování s plovoucí desetinou čárkou v blogovém příspěvku .NET Core 3.0 navrhuje některé změny, které můžete v kódu provést, pokud chcete zachovat předchozí chování.
Knihovny Core .NET
Metody parsování s plovoucí desetinnou čárkou už při analýze řetězce, jehož číselná hodnota je mimo rozsah typu s Double plovoucí desetinnou čárkou, už nevyvolají OverflowException ani nevrátífalse
.Single
V .NET Core 2.2 a starších verzích Double.Parse můžou OverflowException metody vyvolat Single.Parse hodnoty, které nejsou v rozsahu příslušného typu. Metody Double.TryParse a Single.TryParse návraty false
pro řetězcové reprezentace číselných hodnot mimo rozsah.
Počínaje rozhraním .NET Core 3.0 Double.ParseDouble.TryParseSingle.Parseuž selžou metody a Single.TryParse metody při analýze číselných řetězců mimo rozsah. Double Místo toho metody analýzy vrátí Double.PositiveInfinity hodnoty, které překračují Double.MaxValue, a vrátí Double.NegativeInfinity hodnoty, které jsou menší než Double.MinValue. Single Podobně metody analýzy vrací Single.PositiveInfinity hodnoty, které překračují Single.MaxValue, a vrátí Single.NegativeInfinity hodnoty, které jsou menší než Single.MinValue.
Tato změna byla provedena pro lepší dodržování předpisů IEEE 754:2008.
3,0
Tato změna může ovlivnit váš kód dvěma způsoby:
Váš kód závisí na obslužné rutině OverflowException , která se má provést, když dojde k přetečení. V tomto případě byste měli příkaz odebrat catch
a umístit veškerý potřebný kód do If
příkazu, který testuje, zda Double.IsInfinity nebo Single.IsInfinity je true
.
Váš kód předpokládá, že hodnoty s plovoucí desetinou čárkou nejsou Infinity
. V tomto případě byste měli přidat potřebný kód pro kontrolu hodnot s plovoucí desetinou čárkou PositiveInfinity
a NegativeInfinity
.
Knihovny Core .NET
Třída InvalidAsynchronousStateException byla přesunuta.
V .NET Core 2.2 a starších verzích InvalidAsynchronousStateException se třída nachází v sestavení System.ComponentModel.TypeConverter .
Počínaje .NET Core 3.0 se nachází v sestavení System.ComponentModel.Primitives .
3,0
Tato změna má vliv pouze na aplikace, které používají reflexi k načtení InvalidAsynchronousStateException volání metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě aktualizujte sestavení odkazované ve volání metody tak, aby odráželo nové umístění sestavení typu.
Knihovny Core .NET
Nezaokrouhlovat.
Když třída UTF8Encoding během operace převodu bajtů na znak zaznamená špatně vytvořenou sekvenci UTF-8 bajtů, nahradí ji znakem ' (U+FFFD REPLACE CHARACTER) ve výstupním řetězci. .NET Core 3.0 se liší od předchozích verzí .NET Core a rozhraní .NET Framework podle osvědčeného postupu kódování Unicode pro provedení této náhrady během operace překódování.
To je součástí většího úsilí o zlepšení zpracování UTF-8 v rámci .NET, včetně nových System.Text.Unicode.Utf8 a System.Text.Rune typů. Tento UTF8Encoding typ získal vylepšenou mechaniku zpracování chyb, aby vytvořil výstup konzistentní s nově zavedenými typy.
Počínaje .NET Core 3.0 při překódování bajtů na znaky UTF8Encoding třída provádí nahrazení znaků na základě osvědčených postupů unicode. Použitý mechanismus nahrazení popisuje Standard Unicode verze 12.0, s. 3.9 (PDF) v nadpisu s názvem U+FFFD Subparts.
Toto chování platí pouze v případě, že vstupní bajtová sekvence obsahuje špatně vytvořená data UTF-8. Kromě toho, pokud UTF8Encoding instance byla vytvořena throwOnInvalidBytes: true
s , UTF8Encoding
instance bude nadále vyvolána na neplatný vstup místo provedení U+FFFD nahrazení. Další informace o konstruktoru UTF8Encoding
naleznete v tématu UTF8Encoding(Boolean, Boolean).
Následující tabulka ukazuje dopad této změny s neplatným vstupem o 3 bajty:
3 bajtový vstup s neformulovanou dvěma bajty | Výstup před .NET Core 3.0 | Výstup začínající na .NET Core 3.0 |
---|---|---|
[ ED A0 90 ] |
[ FFFD FFFD ] (Výstup se 2 znaky) |
[ FFFD FFFD FFFD ] (Výstup se 3 znaky) |
3-char výstup je upřednostňovaný výstup podle tabulky 3-9 dříve propojeného Unicode Standard PDF.
3,0
Na straně vývojáře není nutná žádná akce.
Knihovny Core .NET
Třída TypeDescriptionProviderAttribute byla přesunuta.
V .NET Core 2.2 a starších verzích se TypeDescriptionProviderAttribute třída nachází v sestavení System.ComponentModel.TypeConverter .
Počínaje rozhraním .NET Core 3.0 se nachází v sestavení System.ObjectModel .
3,0
Tato změna má vliv pouze na aplikace, které používají reflexi k načtení TypeDescriptionProviderAttribute typu voláním metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě by se sestavení odkazované ve volání metody mělo aktualizovat tak, aby odráželo nové umístění sestavení typu.
Windows Forms
Nezaokrouhlovat.
Seznam archivů zip komprimované i nekomprimované velikosti v centrálním adresáři a místní hlavičce. Samotná vstupní data také označují svou velikost. V .NET Core 2.2 a starších verzích nebyly tyto hodnoty nikdy zkontrolovány na konzistenci. Počínaje .NET Core 3.0 jsou teď.
V .NET Core 2.2 a starších verzích je úspěšné, ZipArchiveEntry.Open() i když místní hlavička nesouhlasí s centrální hlavičkou souboru ZIP. Data se dekompresí do dosažení konce komprimovaného datového proudu, i když jeho délka překračuje nekomprimovanou velikost souboru uvedenou v centrální hlavičce adresáře nebo místního adresáře.
Počínaje rozhraním .NET Core 3.0 metoda kontroluje, ZipArchiveEntry.Open() jestli místní hlavička a centrální hlavička souhlasí s komprimovanými a nekomprimovanými velikostmi položky. Pokud tomu tak není, metoda vyvolá InvalidDataException , pokud místní záhlaví archivu nebo seznam popisovačů dat, které nesouhlasí s centrálním adresářem souboru ZIP. Při čtení položky se dekomprimovaná data zkrátí na nekomprimovanou velikost souboru uvedenou v záhlaví.
Tato změna byla provedena, aby se zajistilo, že ZipArchiveEntry správně představuje velikost dat a že je přečteno pouze takové množství dat.
3,0
Znovu zabalte archiv zip, který vykazuje tyto problémy.
Knihovny Core .NET
Počínaje rozhraním .NET Core 3.0 se vyvolá výjimka při pokusu o nastavení hodnoty na statickém InitOnly poli voláním System.Reflection.FieldInfo.SetValue.
V rozhraní .NET Framework a verzích .NET Core před verzí 3.0 můžete nastavit hodnotu statického pole, které je po inicializaci (jen pro čtení v jazyce C#) voláním System.Reflection.FieldInfo.SetValue. Nastavení takového pole tímto způsobem však vedlo k nepředvídatelným chováním na základě cílové architektury a nastavení optimalizace.
V .NET Core 3.0 a novějších verzích se při volání SetValue statického InitOnly pole System.FieldAccessException vyvolá výjimka.
Tip
Pole InitOnly je pole, které lze nastavit pouze v době, kdy je deklarována nebo v konstruktoru pro obsahující třídu. Jinými slovy, po inicializaci je konstantní.
3,0
Inicializace statických InitOnly polí ve statickém konstruktoru To platí pro dynamické i ne dynamicky.
Případně můžete atribut z pole odebrat FieldAttributes.InitOnly a potom volat FieldInfo.SetValue.
Knihovny Core .NET
Při volání rozšiřující metody, která přebírá IEnumerable<T>
na , GroupCollectionmusíte nejednoznačit typ pomocí přetypování.
Počínaje .NET Core 3.0 System.Text.RegularExpressions.GroupCollection implementuje IEnumerable<KeyValuePair<String,Group>>
kromě dalších typů, které implementuje, včetně IEnumerable<Group>
. Výsledkem je nejednoznačnost při volání rozšiřující metody, která přebírá IEnumerable<T>. Pokud takovou metodu GroupCollection rozšíření voláte například Enumerable.Countv instanci, zobrazí se následující chyba kompilátoru:
CS1061: GroupCollection neobsahuje definici pro Count a nelze najít žádnou přístupnou metodu rozšíření Count, která přijímá první argument typu GroupCollection (chybí direktiva using nebo odkaz na sestavení?)
V předchozích verzích rozhraní .NET nebyla žádná nejednoznačnost a chyba kompilátoru.
3,0
To byla neúmyslná změna způsobující chybu. Protože to bylo už nějakou dobu podobné, neplánujeme ho vrátit. Kromě toho by se taková změna sama o sobě rozbila.
Například GroupCollection nejednoznačné volání rozšiřujících metod, které přijímají přetypování IEnumerable<T>
.
// Without a cast - causes CS1061.
match.Groups.Count(_ => true)
// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);
Knihovny Core .NET
Všechna rozšiřující metoda, která přijímá, je ovlivněna IEnumerable<T> . Příklad:
System.Linq.Enumerable
Většina metod, napříkladSystem.Linq.Enumerable.CountKořenové certifikáty v systémech Linux a jiných systémů unixových (ale ne macOS) se dají prezentovat ve dvou formách: standardní BEGIN CERTIFICATE
hlavička PEM a hlavička PEM specifická pro BEGIN TRUSTED CERTIFICATE
OpenSSL. Druhá syntaxe umožňuje další konfiguraci, která způsobila problémy s kompatibilitou třídy .NET Core System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATE
Obsah kořenového certifikátu již není načten řetězovým modulem začínajícím v .NET Core 3.0.
Dříve byly použity jak syntaxe BEGIN CERTIFICATE
BEGIN TRUSTED CERTIFICATE
, tak i k naplnění kořenového seznamu důvěryhodnosti. Pokud se BEGIN TRUSTED CERTIFICATE
syntaxe použila a v souboru byly zadány další možnosti, X509Chain mohly být hlášeny, že vztah důvěryhodnosti řetězu byl explicitně zakázán (X509ChainStatusFlags.ExplicitDistrust). Pokud byl však certifikát zadán také se BEGIN CERTIFICATE
syntaxí v dříve načteném souboru, byl povolený vztah důvěryhodnosti řetězu.
Od verze .NET Core 3.0 BEGIN TRUSTED CERTIFICATE
se obsah už nepřečte. Pokud certifikát není zadán také prostřednictvím standardní BEGIN CERTIFICATE
syntaxe, sestavy, X509Chain které kořen není důvěryhodný (X509ChainStatusFlags.UntrustedRoot).
3,0
Na většinu aplikací tato změna nemá vliv, ale aplikace, které nevidí oba kořenové zdroje certifikátů kvůli problémům s oprávněními, můžou po upgradu dojít k neočekávaným UntrustedRoot
chybám.
Mnoho distribucí Linuxu (nebo distribucí) zapisuje kořenové certifikáty do dvou umístění: adresář s jedním certifikátem na soubor a zřetězení jednoho souboru. V některých distribucích používá BEGIN TRUSTED CERTIFICATE
adresář one-certificate-per-file syntaxi, zatímco zřetězení souboru používá standardní BEGIN CERTIFICATE
syntaxi. Ujistěte se, že jsou všechny vlastní kořenové certifikáty přidány jako BEGIN CERTIFICATE
v nejméně jednom z těchto umístění a že obě umístění může vaše aplikace číst.
Typický adresář je /etc/ssl/certs/ a typický zřetězený soubor je /etc/ssl/cert.pem. Pomocí příkazu openssl version -d
určete kořen specifický pro platformu, který se může lišit od /etc/ssl/. Například na Ubuntu 18.04 je adresář /usr/lib/ssl/certs/ a soubor je /usr/lib/ssl/cert.pem. /usr/lib/ssl/certs/ je symlink na /etc/ssl/certs/ a /usr/lib/ssl/cert.pem neexistuje.
$ 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
Kryptografie
Výchozí algoritmus symetrického šifrování, který EnvelopedCms
používá, se změnil z TripleDES na AES-256.
Pokud se v předchozích verzích EnvelopedCms používá k šifrování dat bez zadání symetrického šifrovacího algoritmu prostřednictvím přetížení konstruktoru, data se šifrují pomocí algoritmu TripleDES/3DES/3DEA/DES3-EDE.
Počínaje .NET Core 3.0 (prostřednictvím verze 4.6.0 balíčku NuGet System.Security.Cryptography.Pkcs ) se výchozí algoritmus změnil na AES-256 pro modernizaci algoritmů a zlepšil zabezpečení výchozích možností. Pokud má certifikát příjemce zprávy veřejný klíč Diffie-Hellman (jiný než EC), může operace šifrování selhat s CryptographicException ohledem na omezení základní platformy.
V následujícím vzorovém kódu se data šifrují pomocí TripleDES, pokud běží na .NET Core 2.2 nebo starším. Pokud běží na .NET Core 3.0 nebo novějším, je šifrovaný pomocí AES-256.
EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();
3,0
Pokud vás změna negativně ovlivní, můžete šifrování TripleDES obnovit explicitním zadáním identifikátoru šifrovacího algoritmu v EnvelopedCms konstruktoru, který obsahuje parametr typu AlgorithmIdentifier, například:
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();
Kryptografie
Minimální velikost pro generování nových klíčů RSA v Linuxu se zvýšila z 384bitové na 512bitovou.
Od verze .NET Core 3.0 se minimální velikost právního klíče hlášená LegalKeySizes
vlastností instancí RSA z RSA.Createa RSAOpenSslRSACryptoServiceProvider v Linuxu zvýšila z 384 na 512.
V důsledku toho v .NET Core 2.2 a starších verzích volání metody, jako RSA.Create(384)
je úspěšné. V .NET Core 3.0 a novějších verzích vyvolá volání RSA.Create(384)
metody výjimku, která značí, že velikost je příliš malá.
Tato změna byla provedena, protože OpenSSL, která provádí kryptografické operace v Linuxu, zvýšilo své minimum mezi verzemi 1.0.2 a 1.1.0. .NET Core 3.0 upřednostňuje OpenSSL 1.1.x až 1.0.x a minimální hlášená verze byla vyvolána tak, aby odrážela toto nové vyšší omezení závislostí.
3,0
Pokud voláte některá z ovlivněných rozhraní API, ujistěte se, že velikost vygenerovaných klíčů není menší než minimum poskytovatele.
Poznámka
384bitové RSA se už považuje za nezabezpečené (stejně jako 512bitové RSA). Moderní doporučení, jako je například speciální publikace NIST 800–57 část 1 revize 4, navrhují 2048bitovou verzi jako minimální velikost pro nově generované klíče.
Kryptografie
.NET Core pro Linux, která funguje v různých distribucích Linuxu, podporuje OpenSSL 1.0.x i OpenSSL 1.1.x. .NET Core 2.1 a .NET Core 2.2 nejprve vyhledejte verzi 1.0.x a pak se vraťte na verzi 1.1.x; .NET Core 3.0 nejprve hledá verzi 1.1.x. Tato změna byla provedena tak, aby se přidala podpora nových kryptografických standardů.
Tato změna může mít vliv na knihovny nebo aplikace, které interop platformy s typy spolupráce specifické pro OpenSSL v .NET Core.
V .NET Core 2.2 a starších verzích dává modul runtime přednost načítání OpenSSL 1.0.x než 1.1.x. To znamená, že a SafeHandle typy pro interoperabilitu IntPtr s OpenSSL se používají s libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 podle preference.
Počínaje .NET Core 3.0, modul runtime dává přednost načítání OpenSSL 1.1.x přes OpenSSL 1.0.x, takže IntPtr a SafeHandle typy pro interoperabilitu s OpenSSL se používají s libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 podle preferencí. V důsledku toho mohou knihovny a aplikace, které interoperují s OpenSSL přímo, mít nekompatibilní ukazatele s hodnotami vystavenými .NET Core při upgradu z .NET Core 2.1 nebo .NET Core 2.2.
3,0
Knihovny a aplikace, které provádějí přímé operace pomocí OpenSSL, musí být opatrní, aby se zajistilo, že používají stejnou verzi OpenSSL jako modul runtime .NET Core.
Všechny knihovny nebo aplikace, které používají IntPtr nebo SafeHandle používají hodnoty z kryptografických typů .NET Core přímo s OpenSSL, by měly porovnat verzi knihovny, kterou používají s novou SafeEvpPKeyHandle.OpenSslVersion vlastností, aby byly ukazatele kompatibilní.
Kryptografie
Metoda CryptoStream.Dispose , která se používá k dokončení CryptoStream
operací, se už při čtení nepokouší transformovat konečný blok.
Pokud uživatel v předchozích verzích .NET při použití CryptoStream v Read režimu provedl neúplné čtení, Dispose může metoda vyvolat výjimku (například při použití AES s odsazením). Výjimka byla vyvolána, protože se poslední blok pokusil o transformaci, ale data nebyla dokončena.
V .NET Core 3.0 a novějších verzích Dispose se už při čtení nepokusí transformovat konečný blok, který umožňuje neúplné čtení.
Tato změna umožňuje neúplná čtení z kryptografického streamu při zrušení síťové operace, aniž by bylo nutné zachytit výjimku.
3,0
Na většinu aplikací by tato změna neměla mít vliv.
Pokud vaše aplikace dříve chytila výjimku v případě neúplného čtení, můžete tento catch
blok odstranit.
Pokud vaše aplikace ve scénářích hash použila transformaci konečného bloku, možná budete muset před odstraněním celého datového proudu zajistit, aby se celý datový proud četl.
Kryptografie
Zásadní změny entity Framework Core
.NET Core 2.2 a starší verze závisí na výchozím chování jednotky ICU, které mapuje národní prostředí "C" na en_US_POSIX národní prostředí. Národní prostředí en_US_POSIX má nežádoucí chování kolace, protože nepodporuje porovnávání řetězců bez rozlišování velkých a malých písmen. Vzhledem k tomu, že některé linuxové distribuce nastavily národní prostředí "C" jako výchozí národní prostředí, došlo k neočekávanému chování uživatelů.
Od verze .NET Core 3.0 se mapování národního prostředí jazyka C změnilo tak, aby místo en_US_POSIX používalo invariantní národní prostředí. Národní prostředí "C" na invariantní mapování je také použito pro systém Windows kvůli konzistenci.
Mapování "C" na en_US_POSIX jazykové verzi způsobilo nejasnost zákazníků, protože en_US_POSIX nepodporuje operace řazení a vyhledávání řetězců nerozlišující malá a velká písmena. Vzhledem k tomu, že národní prostředí "C" se používá jako výchozí národní prostředí v některých distribucích Linuxu, zaznamenali zákazníci toto nežádoucí chování v těchto operačních systémech.
3,0
Nic konkrétního než povědomí o této změně. Tato změna má vliv pouze na aplikace, které používají mapování národního prostředí jazyka C.
Globalizace
Tato změna ovlivňuje všechna kolace a rozhraní API jazykové verze.
Počínaje .NET Core 3.0 ve výchozím případě nástroj MSBuild vygeneruje pro soubory prostředků jiný název souboru manifestu.
3,0
Před .NET Core 3.0, pokud nebyla zadána žádná LogicalName
ManifestResourceName
, nebo DependentUpon
metadata pro EmbeddedResource
položku v souboru projektu, nástroj MSBuild vygeneroval název souboru manifestu ve vzoru <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources
. Pokud RootNamespace
není v souboru projektu definováno, je výchozí název projektu. Například vygenerovaný název manifestu pro soubor prostředků s názvem Form1.resx v kořenovém adresáři projektu byl MyProject.Form1.resources.
Počínaje .NET Core 3.0, pokud je soubor prostředků společně přidělený se zdrojovým souborem se stejným názvem (například Form1.resx a Form1.cs), nástroj MSBuild používá informace o typu ze zdrojového souboru k vygenerování názvu souboru manifestu ve vzoru <Namespace>.<ClassName>.resources
. Obor názvů a název třídy se extrahují z prvního typu v spolulokovaném zdrojovém souboru. Například vygenerovaný název manifestu pro soubor prostředků s názvem Form1.resx , který je společně přidělený zdrojovým souborem s názvem Form1.cs je MyNamespace.Form1.resources. Klíčovou věcí, kterou je třeba poznamenat, je, že první část názvu souboru se liší od předchozích verzí .NET Core (MyNamespace místo MyProject).
Poznámka
Pokud máte LogicalName
, ManifestResourceName
nebo DependentUpon
metadata zadaná pro EmbeddedResource
položku v souboru projektu, tato změna nemá vliv na tento soubor zdroje.
Tato změna způsobující chybu byla zavedena přidáním EmbeddedResourceUseDependentUponConvention
vlastnosti do projektů .NET Core. Ve výchozím nastavení nejsou soubory prostředků explicitně uvedeny v souboru projektu .NET Core, takže nemají žádná DependentUpon
metadata k určení, jak pojmenovat vygenerovaný soubor .resources . Pokud EmbeddedResourceUseDependentUponConvention
je nastavena na true
, což je výchozí, NÁSTROJ MSBuild vyhledá společnělokovaný zdrojový soubor a extrahuje obor názvů a název třídy z daného souboru. Pokud nastavíte EmbeddedResourceUseDependentUponConvention
hodnotu false
, nástroj MSBuild vygeneruje název manifestu podle předchozího chování, které kombinuje RootNamespace
a relativní cestu k souboru.
Ve většině případů se nevyžaduje žádná akce na straně vývojáře a vaše aplikace by měla dál fungovat. Pokud ale tato změna aplikaci přeruší, můžete:
Změňte kód tak, aby očekával nový název manifestu.
Odhlaste se z nové zásady vytváření názvů nastavením EmbeddedResourceUseDependentUponConvention
v false
souboru projektu.
<PropertyGroup>
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>
MSBuild
–
Výchozí hodnota System.Net.Http.HttpRequestMessage.Version vlastnosti se změnila z 2.0 na 1.1.
3,0
V .NET Core 1.0 až 2.0 je výchozí hodnota System.Net.Http.HttpRequestMessage.Version vlastnosti 1.1. Od verze .NET Core 2.1 se změnila na 2.1.
Počínaje rozhraním .NET Core 3.0 je výchozí číslo verze vrácené System.Net.Http.HttpRequestMessage.Version vlastností znovu 1.1.
Aktualizujte kód, pokud závisí na System.Net.Http.HttpRequestMessage.Version vlastnosti, která vrací výchozí hodnotu 2.0.
Sítě
.NET Core 3.0 zavedl změnu způsobu, jakým ovládací prvky textového editoru System.Windows.DataObject vytvářejí při přetahování textu do jiného ovládacího prvku. Změna zakázala automatické převody, což způsobí, že operace zachová data jako DataFormats.Text nebo DataFormats.UnicodeText místo převodu na DataFormats.StringFormat.
.NET Core 3.0
Windows Presentation Foundation
Datový typ při System.Windows.DataObject přetažení textu z ovládacího prvku textového editoru byl DataFormats.StringFormat.
Datový typ při System.Windows.DataObject přetažení textu z ovládacího prvku textového editoru je DataFormats.Text nebo DataFormats.UnicodeText.
Tato změna je změna chování.
Změna byla neúmyslná.
Tato změna se vrátila v .NET 7. Upgradujte na .NET 7 nebo novější.
Zpětná vazba k produktu .NET
.NET je open source projekt. Vyberte odkaz pro poskytnutí zpětné vazby:
Školení
Modul
Zabezpečení webové aplikace .NET pomocí architektury ASP.NET Core Identity Framework - Training
Zjistěte, jak přidat ověřování a autorizaci do webové aplikace .NET pomocí architektury ASP.NET Core Identity Framework.
Dokumentace
Zásadní změny v .NET Core 3.1 - .NET
Uvádí zásadní změny ve verzi 3.1 .NET Core a ASP.NET Core.
Migrace z ASP.NET Core 2.2 na verzi 3.0
Zjistěte, jak migrovat projekt ASP.NET Core 2.2 na ASP.NET Core 3.0.
Změna způsobující chybu: Zastaralá a odebraná rozhraní API - .NET
Informace o zásadní změně v ASP.NET Core 6.0 s názvem Zastaralé a odebraná rozhraní API