Rozbíjení změn v .NET Core 3.0

  • Článek
  • 33 min ke čtení

Pokud migrujete na verzi 3.0 rozhraní .NET Core, ASP.NET Core nebo EF Core, mohou mít na vaši aplikaci vliv nejnovější změny uvedené v tomto článku.

ASP.NET Core

Odebrání zastaralých rozhraní API pro antiforgery, CORS, diagnostiku, MVC a směrování

Zastaralé členy a přepínače kompatibility v ASP.NET Core verze 2.2 byly odebrány.

Zavedená verze

3.0

Důvod změny

Vylepšení plochy rozhraní API v průběhu času

Při cílení na .NET Core 2.2 postupujte podle pokynů v zastaralých zprávách sestavení a řiďte se novými rozhraními API.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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.CollectionModelBinder'1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary'2)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
  • Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

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

Odebrána rozhraní API "Pubternal"

Aby se lépe zachovala veřejná plocha rozhraní API ASP.NET Core, většina typů v *.Internal oborech názvů (označovaných jako "pubternal" rozhraní API) se stane skutečně interní. U členů v těchto oborech názvů nikdy nechtěla být podporovaná jako veřejná rozhraní API. Rozhraní API se můžou v podverzích poškodit a často se jedná o. 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 naleznete v tématech dotnet/aspnetcore # 4932 a dotnet/aspnetcore # 11312.

Představená verze

3,0

Staré chování

Ovlivněná rozhraní API jsou označená public modifikátorem přístupu a existují v *.Internal oborech názvů.

Nové chování

Ovlivněná rozhraní API jsou označená modifikátorem interního přístupu a již nemohou být používána kódem mimo toto sestavení.

Důvod změny

Pokyny pro tato "pubternal" rozhraní API:

  • Může se změnit bez předchozího upozornění.
  • Nevedly se zásady rozhraní .NET, aby se zabránilo zásadním změnám.

Ukončení rozhraní API public (dokonce i v *.Internal oborech názvů) bylo matoucí pro zákazníky.

Ukončete používání těchto "pubternal" rozhraní API. Pokud máte dotazy týkající se alternativních rozhraní API, otevřete problém v úložišti dotnet/aspnetcore .

Zvažte například následující kód pro ukládání požadavků HTTP do vyrovnávací paměti v projektu ASP.NET Core 2,2. EnableRewindMetoda rozšíření existuje v Microsoft.AspNetCore.Http.Internal oboru názvů.

HttpContext.Request.EnableRewind();

V projektu ASP.NET Core 3,0 nahraďte EnableRewind volání voláním EnableBuffering metody rozšíření. Funkce ukládání požadavků do vyrovnávací paměti funguje stejně jako v minulosti. EnableBuffering volá internal rozhraní API Now.

HttpContext.Request.EnableBuffering();

Kategorie

Jádro ASP.NET

Ovlivněná rozhraní API

Všechna rozhraní API v Microsoft.AspNetCore.* Microsoft.Extensions.* oborech názvů a, 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

Ověřování: Google + zastaralé a nahrazené

Google se zahájí vypnutí služby Google + Sign-in pro aplikace hned po 28. lednu 2019.

Popis změny

ASP.NET 4. x a ASP.NET Core používaly rozhraní API pro přihlašování Google + k ověřování uživatelů účtu Google ve službě Web Apps. Ovlivněné balíčky NuGet jsou Microsoft. AspNetCore. Authentication. Google pro ASP.NET Core a Microsoft. Owin. Security. google pro Microsoft.Owin s ASP.NET webovými formuláři a MVC.

Rozhraní API pro nahrazení Google používají jiný zdroj dat a formát. Rizika a řešení uvedená níže jsou k dispozici pro strukturální změny. Aplikace by měly ověřit, že samotná data stále splňují jejich požadavky. Například názvy, e-mailové adresy, odkazy na profily a profily profilů můžou poskytovat nepřesné odlišné hodnoty.

Představená verze

Všechny verze. Tato změna je externě ASP.NET Core.

Owin s webovými formuláři ASP.NET a MVC

V případě Microsoft.Owin 3.1.0 a novějších verzí je zdepopsaný dočasný dopad. Aplikace by měly dokončit testování s rizikem, aby kontrolovaly změny ve formátu dat. Existují plány pro vydání Microsoft.Owin 4.0.1 s opravou. Aplikace používající jakoukoli předchozí verzi by se měly aktualizovat na verzi 4.0.1.

ASP.NET Core 1. x

Zmírnění rizika v Owin s webovými formuláři ASP.NET a MVC se dá přizpůsobit ASP.NET Core 1. x. Opravy balíčků NuGet nejsou plánované, protože 1. x dosáhlo stavu konce životnosti .

ASP.NET Core 2. x

Pro Microsoft.AspNetCore.Authentication.Google verzi 2. x nahraďte stávající volání v aplikaci 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 zahrnovaly předchozí znovu konfiguraci jako nové výchozí nastavení. Pro ASP.NET Core 2,0 není plánována žádná oprava, protože dosáhla konce životnosti.

ASP.NET Core 3,0

Zmírnění rizika poskytnutého ASP.NET Core 2. x se dá použít i pro ASP.NET Core 3,0. V budoucích verzích 3,0 Preview Microsoft.AspNetCore.Authentication.Google může být balíček odebraný. Uživatelé budou přesměrováni na Microsoft.AspNetCore.Authentication.OpenIdConnect místo. Následující kód ukazuje, jak nahradit AddGoogle nástrojem AddOpenIdConnect v Startup.ConfigureServices . Tato náhrada se dá použít s ASP.NET Core 2,0 a novějším a dá se podle potřeby 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();

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Authentication.Google

Ověřování: vlastnost HttpContext. Authentication byla odebrána.

Vystaralá Authentication vlastnost HttpContext byla odebrána.

Popis změny

Jako součást dotnet/aspnetcore # 6504 Authentication HttpContext byla odebrána Vyřazená vlastnost. AuthenticationVlastnost se od verze 2,0 nepoužívá. 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 ASP.NET Core 1. x zásobník ověřování byly odebrány v potvrzení dotnet/aspnetcore@d7a7c65 .

Diskuzi najdete v tématu dotnet/aspnetcore # 6533.

Představená verze

3.0

Důvod změny

rozhraní api ASP.NET Core 1,0 byla nahrazena metodami rozšíření v Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions .

Viz Průvodce migrací.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ověřování: Newtonsoft.Jsna nahrazené typy

Ve ASP.NET Core 3.0 byly typy používané v rozhraních API pro ověřování Newtonsoft.Json 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ů neovlvljené:

  • Třídy odvozené od zprostředkovatelů OAuth, například třídy z aspnet-contrib.
  • Pokročilé implementace manipulace s deklaracemi.

Další informace najdete v tématu dotnet/aspnetcore#7105. Diskuzi najdete v tématu dotnet/aspnetcore#7289.

Zavedená verze

3.0

U odvozených implementací OAuth je nejběžnější změnou nahrazení v přepsání , jak JObject.Parse JsonDocument.Parse je CreateTicketAsync znázorněno tady. JsonDocument implementuje IDisposable .

V následujícím seznamu jsou popsané známé změny:

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ověřování: změnil se podpis OAuthHandler ExchangeCodeAsync.

V ASP.NET Core 3,0 se signatura OAuthHandler.ExchangeCodeAsync změnila 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; }

Představená verze

3.0

Staré chování

codeŘetězce a redirectUri byly předány jako samostatné argumenty.

Nové chování

Code a RedirectUri jsou vlastnosti OAuthCodeExchangeContext , které lze nastavit prostřednictvím OAuthCodeExchangeContext konstruktoru. Nový OAuthCodeExchangeContext typ je jediný argument předaný do OAuthHandler.ExchangeCodeAsync .

Důvod změny

Tato změna umožňuje, aby byly další parametry poskytovány nediskriminujícím způsobem. Není nutné vytvářet nová ExchangeCodeAsync přetížení.

Vytvořte objekt OAuthCodeExchangeContext s odpovídajícími code redirectUri hodnotami a. AuthenticationPropertiesJe nutné zadat instanci. Tato jediná OAuthCodeExchangeContext instance může být předána OAuthHandler.ExchangeCodeAsync místo více argumentů.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorizace: přetížení AddAuthorization se přesunulo do jiného sestavení.

Základní AddAuthorization metody, které se nacházejí v rámci, Microsoft.AspNetCore.Authorization byly přejmenovány na AddAuthorizationCore . Staré AddAuthorization metody stále existují, ale místo toho jsou v Microsoft.AspNetCore.Authorization.Policy sestavení. U aplikací, které používají obě metody, by se měl zobrazit žádný vliv. Všimněte si, že se Microsoft.AspNetCore.Authorization.Policy teď dodává do sdíleného rozhraní místo samostatného balíčku, jak je popsáno ve sdíleném rozhraní: sestavení odebraná z Microsoft. AspNetCore. app.

Představená verze

3.0

Staré chování

AddAuthorization metody existovaly v Microsoft.AspNetCore.Authorization .

Nové chování

AddAuthorization metody existují v Microsoft.AspNetCore.Authorization.Policy . AddAuthorizationCore je nový název pro staré metody.

Důvod změny

AddAuthorization je lepší název metody pro přidání všech běžných služeb potřebných pro autorizaci.

Buď místo toho přidejte odkaz na Microsoft.AspNetCore.Authorization.Policy nebo použít AddAuthorizationCore .

Kategorie

Jádro ASP.NET

Ovlivněná rozhraní API

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

Autorizace: IAllowAnonymous se odebral z AuthorizationFilterContext. filters.

Od ASP.NET Core 3,0 MVC nepřidává AllowAnonymousFilters pro atributy [AllowAnonymous] , které byly zjištěny na řadičích a metodách akcí. Tato změna se řeší místně pro odvozeniny, ale jedná se o zásadní AuthorizeAttribute změnu pro IAsyncAuthorizationFilter IAuthorizationFilter implementaci a implementace. Takové implementace zabalené v atributu [TypeFilter] jsou oblíbeným a podporovaným způsobem, jak dosáhnout silného typu ověřování založeného na atributech, pokud jsou vyžadovány konfigurace i vkládání závislostí.

Představená verze

3.0

Staré chování

IAllowAnonymous objevilo se 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.

Nové chování

IAllowAnonymous v kolekci se již nezobrazuje AuthorizationFilterContext.Filters . IAsyncAuthorizationFilter implementace, které jsou závislé na starém chování obvykle způsobují přerušované odpovědi HTTP 401 Neautorizováno nebo HTTP 403 zakázané.

Důvod změny

V ASP.NET Core 3,0 byla představena nová strategie směrování koncových bodů.

Vyhledejte metadata koncového bodu pro IAllowAnonymous . Například:

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

V této metodě HasAllowAnonymousse zobrazuje příklad této techniky.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Autorizace: implementace IAuthorizationPolicyProvider vyžadují novou metodu.

V ASP.NET Core 3,0 GetFallbackPolicyAsync byla do aplikace přidána nová metoda IAuthorizationPolicyProvider . Tuto záložní zásadu používá middleware autorizace, pokud není zadána žádná zásada.

Další informace naleznete v tématu dotnet/aspnetcore # 9759.

Představená verze

3.0

Staré chování

Implementace IAuthorizationPolicyProvider nevyžadují GetFallbackPolicyAsync metodu.

Nové chování

Implementace IAuthorizationPolicyProvider vyžadují GetFallbackPolicyAsync metodu.

Důvod změny

Nová metoda byla nutná pro nové použití, AuthorizationMiddleware Pokud není zadána žádná zásada.

Přidejte GetFallbackPolicyAsync metodu do vašich implementací IAuthorizationPolicyProvider .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Ukládání do mezipaměti: byla odebrána vlastnost CompactOnMemoryPressure

Verze ASP.NET Core 3,0 odebrala zastaralá rozhraní API MemoryCacheOptions.

Popis změny

Tato změna je následná pro ASPNET/Caching # 221. Diskuzi najdete v tématu dotnet/Extensions # 1062.

Představená verze

3.0

Staré chování

MemoryCacheOptions.CompactOnMemoryPressure vlastnost byla k dispozici.

Nové chování

MemoryCacheOptions.CompactOnMemoryPressureVlastnost byla odebrána.

Důvod změny

Automatické komprimace mezipaměti způsobilo problémy. Aby nedocházelo k neočekávanému chování, měla by být mezipaměť komprimována pouze v případě potřeby.

Pro komprimaci mezipaměti, downcast na MemoryCache a volání v Compact případě potřeby.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

MemoryCacheOptions.CompactOnMemoryPressure

Ukládání do mezipaměti: Microsoft. Extensions. Caching. SqlServer používá nový balíček SqlClient.

Microsoft.Extensions.Caching.SqlServerBalíček použije nový Microsoft.Data.SqlClient balíček místo System.Data.SqlClient balíčku. Tato změna by mohla způsobit mírné změny v chování. Další informace najdete v tématu představení nového Microsoft. data. SqlClient.

Představená verze

3.0

Staré chování

Microsoft.Extensions.Caching.SqlServerBalíček použil System.Data.SqlClient balíček.

Nové chování

Microsoft.Extensions.Caching.SqlServer nyní používá Microsoft.Data.SqlClient balíček.

Důvod změny

Microsoft.Data.SqlClient je nový balíček, který je vytvořen z System.Data.SqlClient . Je to místo, kde se všechny nové funkce budou dělat hned na.

Zákazníci by neměli mít obavy o tuto zásadní změnu, pokud nepoužívaly typy vrácené Microsoft.Extensions.Caching.SqlServer balíčkem a přetypování do System.Data.SqlClient typů. Pokud někdo například přetypování DbConnection na starý typ SqlConnection, musel by změnit přetypování na nový Microsoft.Data.SqlClient.SqlConnection typ.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Ukládání do mezipaměti: ResponseCaching typy "pubternal" se změnily na interní

V ASP.NET Core 3,0 typy "pubternal" v nástroji ResponseCaching byly změněny na internal .

Kromě toho výchozí implementace IResponseCachingPolicyProvider a IResponseCachingKeyProvider již nejsou přidány do služeb jako součást AddResponseCaching metody.

Popis změny

V ASP.NET Core jsou typy "pubternal" deklarovány jako, ale nacházejí se public v oboru názvů s příponou .Internal . I když jsou tyto typy veřejné, nemají žádné zásady podpory a podléhají změnám. Omlouváme se, ale náhodné použití těchto typů je běžné, což vedlo k zásadním změnám těchto projektů a omezení schopnosti zachovat rozhraní.

Představená verze

3.0

Staré chování

Tyto typy byly veřejně viditelné, ale nepodporované.

Nové chování

Tyto typy jsou nyní internal .

Důvod změny

internalObor lépe odráží nepodporované zásady.

Kopírování typů používaných vaší aplikací nebo knihovnou.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ochrana dat: DataProtection. BLOBs používá nová rozhraní Azure Storage API.

Azure.Extensions.AspNetCore.DataProtection.Blobs závisí na knihovně Azure Storage. Tyto knihovny přejmenovaly jejich sestavení, balíčky a obory názvů. Počínaje ASP.NET Core 3,0 Azure.Extensions.AspNetCore.DataProtection.Blobs používá nová Azure.Storage. Předpevná rozhraní API a balíčky.

Pro otázky týkající se rozhraní Azure Storage API použijte https://github.com/Azure/azure-storage-net . Diskuzi o tomto problému najdete v tématu dotnet/aspnetcore # 19570.

Představená verze

3.0

Staré chování

Balíček odkazoval na WindowsAzure.Storage balíček NuGet. Balíček odkazuje na Microsoft.Azure.Storage.Blob balíček NuGet.

Nové chování

Balíček odkazuje na Azure.Storage.Blob balíček NuGet.

Důvod změny

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í Azure Storage API s ASP.NET Core 3,0, přidejte přímou závislost do balíčku windowsazure. Storage nebo Microsoft. Azure. Storage. Tento balíček se dá nainstalovat spolu s novými Azure.Storage rozhraními API.

V mnoha případech upgrade zahrnuje pouze změnu using příkazů pro použití nových oborů 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;

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Hostování: AspNetCoreModule v1 odebrané ze sady hostování Windows

Počínaje ASP.NET Core 3,0 sada hostitelů Windows nebude obsahovat AspNetCoreModule (ANCM) v1.

ANCM v2 je zpětně kompatibilní s ANCM OutOfProcess a doporučuje se pro použití s aplikacemi ASP.NET Core 3,0.

Diskuzi najdete v tématu dotnet/aspnetcore # 7095.

Představená verze

3.0

Staré chování

ANCM v1 je součástí sady hostování systému Windows.

Nové chování

ANCM v1 není součástí hostitelské sady Windows.

Důvod změny

ANCM v2 je zpětně kompatibilní s 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 je požadováno ANCM V1, může být nainstalováno pomocí hostitelské sady Windows ASP.NET Core 2,1 nebo 2,2.

Tato změna způsobí přerušení aplikací ASP.NET Core 3,0, které:

  • Výslovný souhlas s používáním ANCM V1 s <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> .
  • Mít vlastní soubor web.config s <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Hostování: obecný hostitel omezuje úvodní vkládání spouštěcího konstruktoru.

Jediný typ, který je podporován pro Startup vkládání konstruktoru třídy, je IHostEnvironment , IWebHostEnvironment a IConfiguration . Používání aplikací WebHost je neovlivněno.

Popis změny

Před ASP.NET Core 3,0 bylo možné použít injektáže konstruktoru pro libovolný typ v Startup konstruktoru třídy. V ASP.NET Core 3,0 byl webový zásobník znovu založen na obecné knihovně hostitelů. Můžete zobrazit změnu v souboru program.cs šablony:

ASP.NET Core 2. x:

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

ASP.NET Core 3,0:

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

Host k sestavení aplikace používá jeden kontejner vkládání závislostí (DI). WebHost používá dva kontejnery: jeden pro hostitele a jeden pro aplikaci. V důsledku toho Startup konstruktor již nepodporuje vlastní vkládání služeb. IHostEnvironment IWebHostEnvironment Vložit lze pouze,, a IConfiguration . Tato změna zabraňuje chybám typu DI, jako je vytváření duplicitních služeb typu singleton.

Představená verze

3.0

Důvod změny

Tato změna je v důsledku opětovného hostování webového zásobníku do obecné knihovny hostitelů.

Vloží služby do Startup.Configure signatury metody. Například:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Hostování: přesměrování protokolu HTTPS je povolené pro vnitroprocesové aplikace IIS.

13.0.19218.0 modulu ASP.NET Core (ANCM) pro hostování prostřednictvím služby IIS mimo procesy 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.

Představená verze

3.0

Staré chování

Šablona projektu ASP.NET Core 2,1 nejprve představila podporu middlewarových metod protokolu HTTPS jako UseHttpsRedirection a UseHsts . Povolení přesměrování protokolu HTTPS vyžaduje přidání konfigurace, protože aplikace ve vývoji nepoužívají výchozí port 443. HSTS (http Strict Transport Security) je aktivní jenom v případě, že požadavek už používá protokol HTTPS. Localhost je ve výchozím nastavení vynecháno.

Nové chování

V ASP.NET Core 3,0 byl scénář služby IIS HTTPS Vylepšený. Díky vylepšení může aplikace zjistit porty HTTPS serveru a UseHttpsRedirection ve výchozím nastavení provádět práci. Vnitroprocesové komponenta provedla zjišťování portů pomocí IServerAddresses funkce, která má vliv pouze na aplikace ASP.NET Core 3,0, protože knihovna v procesu je označena verzí rozhraní. Součást mimo proces se změnila tak, aby automaticky přidala ASPNETCORE_HTTPS_PORT proměnnou prostředí. Tato změna ovlivnila aplikace ASP.NET Core 2,2 a 3,0, protože součást mimo proces je sdílena 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 upraveno v ASP.NET Core 3.0.1 a 3.1.0 Preview 3 pro vrácení změn chování v ASP.NET Core 2. x. Tyto změny ovlivní pouze vnitroprocesové aplikace služby IIS.

Jak je uvedeno výše, instalace ASP.NET Core 3.0.0 měla vedlejší účinek také k aktivaci UseHttpsRedirection middleware v aplikacích ASP.NET Core 2. x. V ASP.NET Core 3.0.1 a 3.1.0 Preview 3 se provedla změna, takže jejich instalace už nemá vliv na ASP.NET Core 2. x aplikací. ASPNETCORE_HTTPS_PORTProměnná prostředí, kterou ANCM naplně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 byla aktualizována také v těchto vydáních, aby bylo možné pochopit nové i staré proměnné. ASP.NET Core 2. x se nebude aktualizovat. V důsledku toho se vrátí k předchozímu chování, které je ve výchozím nastavení zakázáno.

Důvod změny

Vylepšená funkce ASP.NET Core 3,0.

Pokud chcete, aby všichni klienti používali protokol HTTPS, není nutná žádná akce. Pokud chcete některým klientům dovolit používat protokol HTTP, proveďte jeden z následujících kroků:

  • Odeberte volání do UseHttpsRedirection a UseHsts z metody vašeho projektu Startup.Configure a aplikaci znovu nasaďte.

  • V souboru web.config nastavte ASPNETCORE_HTTPS_PORT proměnnou prostředí na prázdný řetězec. Tato změna se může provádět přímo na serveru bez opětovného nasazení aplikace. Napří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 mít pořád následující:

  • Aktivováno ručně v ASP.NET Core 2. x nastavením ASPNETCORE_HTTPS_PORT proměnné prostředí na příslušné číslo portu (443 ve většině produkčních scénářů).
  • Deaktivováno v ASP.NET Core 3. x definováním ASPNETCORE_ANCM_HTTPS_PORT s hodnotou prázdného řetězce. Tato hodnota je nastavena stejným způsobem jako v předchozím ASPNETCORE_HTTPS_PORT příkladu.

Počítače, na kterých běží ASP.NET Core aplikace 3.0.0, by před instalací ASP.NET Core 3.1.0 Preview 3 ANCM měli nainstalovat ASP.NET Core 3.0.1 runtime. Tím zajistíte, že UseHttpsRedirection bude pro aplikace ASP.NET Core 3,0 nadále fungovat podle očekávání.

V Azure App Service se ANCM nasadí podle vlastního plánu z modulu runtime z důvodu jeho globální povahy. ANCM se ASP.NET Core po nasazení 3.0.1 a 3.1.0 do Azure nasadily s těmito změnami.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hostování: typy IHostingEnvironment a IApplicationLifetime označené jako zastaralé a nahrazené

Byly zavedeny nové typy, které nahradí existující IHostingEnvironment IApplicationLifetime typy a.

Představená verze

3.0

Staré chování

Existují dva různé IHostingEnvironment typy a IApplicationLifetime Microsoft.Extensions.Hosting Microsoft.AspNetCore.Hosting .

Nové chování

Staré typy byly označeny jako zastaralé a nahrazeny novými typy.

Důvod změny

Kdy Microsoft.Extensions.Hosting byla zavedena 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ůsobí, že aplikace budou zahrnovat Microsoft.Extensions.Hosting i Microsoft.AspNetCore.Hosting obory názvů a. Jakékoli použití těchto duplicitních typů způsobí chybu kompilátoru "dvojznačný odkaz" při odkazování na oba obory názvů.

Nově zavedené typy nahradily všechna použití starého typu, jak je uvedeno níže:

Zastaralé typy (upozornění):

Nové typy:

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.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Hostování: ObjectPoolProvider se odebral ze závislostí WebHostBuilder.

V rámci zvýšení ASP.NET Core platby za Play se ObjectPoolProvider odebrala z hlavní sady závislostí. Konkrétní komponenty, které se na ni spoléhají, ObjectPoolProvider se teď přidávají sami.

Diskuzi najdete v tématu dotnet/aspnetcore # 5944.

Představená verze

3.0

Staré chování

WebHostBuilder ve ObjectPoolProvider výchozím nastavení poskytuje kontejner di.

Nové chování

WebHostBuilder``ObjectPoolProviderv kontejneru di již není ve výchozím nastavení k dispozici.

Důvod změny

Tato změna se provedla, aby se zajistilo ASP.NET Core více platíte za Play.

Pokud vaše komponenta vyžaduje ObjectPoolProvider , je nutné ji přidat k vašim závislostem prostřednictvím IServiceCollection .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

HTTP: rozšíření DefaultHttpContext bylo odebráno.

V rámci vylepšení výkonu ASP.NET Core 3,0 se rozšíření DefaultHttpContext odebralo. Třída je nyní sealed . Další informace naleznete 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.

Představená verze

3.0

Staré chování

Třídy mohou odvozovat z DefaultHttpContext .

Nové chování

Třídy nemůžou odvozovat z DefaultHttpContext .

Důvod změny

Tato rozšiřitelná služba byla zpočátku k dispozici, aby umožňovala sdružování HttpContext , ale zavedla zbytečné složitosti a bránila jiným optimalizacím.

Pokud používáte Mock<DefaultHttpContext> v testování částí, začněte Mock<HttpContext> místo toho použít.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames konstanty se změnily na static jen pro čtení

Počínaje verzí ASP.NET Core 3,0 Preview 5 se pole Microsoft.Net.Http.Headers.HeaderNames změněná z const na static readonly .

Diskuzi najdete v tématu dotnet/aspnetcore # 9514.

Představená verze

3.0

Staré chování

Tato pole se používají const .

Nové chování

Tato pole jsou nyní static readonly .

Důvod změny

Změna:

  • Zabraňuje vložení hodnoty přes hranice sestavení, což umožňuje opravy hodnot podle potřeby.
  • Umožňuje rychlejší kontroly rovnosti odkazů.

Znovu kompilovat proti 3,0. Zdrojový kód pomocí těchto polí již neumožňuje následující akce:

  • Jako argument atributu
  • Jako case v switch příkazu
  • Při definování jiného const

Chcete-li obejít zásadní změnu, přepněte na použití vlastní konstanty názvů hlaviček nebo řetězcových literálů.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.Net.Http.Headers.HeaderNames

HTTP: změny infrastruktury textu odpovědi

Infrastruktura, která přestala text odpovědi HTTP, se změnila. Pokud používáte HttpResponse přímo, nemusíte dělat žádné změny kódu. Pokud zabalíte nebo nahrazujete HttpResponse.Body nebo přistupujete, přečtěte si další informace HttpContext.Features .

Představená verze

3.0

Staré chování

K tělo odpovědi HTTP bylo přidruženo tři rozhraní API:

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

Nové chování

Pokud nahradíte HttpResponse.Body , nahradí se celým IHttpResponseBodyFeature daným datovým proudem obálkou s použitím StreamResponseBodyFeature k poskytnutí výchozích implementací pro všechna očekávaná rozhraní API. Nastavení vrátit původní datový proud vrátí tuto změnu.

Důvod změny

Motivací je kombinování rozhraní API těla odpovědi do jednoho nového rozhraní funkce.

Použijte IHttpResponseBodyFeature místo, kde jste předtím používali IHttpResponseFeature.Body , IHttpSendFileFeature nebo IHttpBufferingFeature .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SameSite je možnost pro soubory cookie, které mohou napomoci zmírnit některé útoky CSRF (mezi lokalitami). Při počátečním zavedení této možnosti se v různých ASP.NET Core rozhraní API používaly nekonzistentní výchozí hodnoty. Nekonzistence vedla k matoucímu výsledku. Od ASP.NET Core 3,0 jsou tyto výchozí hodnoty lépe zarovnané. K této funkci se musíte vyjádřit na základě jednotlivých komponent.

Představená verze

3.0

Staré chování

Podobná ASP.NET Core rozhraní API používala jiné výchozí SameSiteMode hodnoty. Příklad nekonzistence se zobrazuje v HttpResponse.Cookies.Append(String, String) a, ve HttpResponse.Cookies.Append(String, String, CookieOptions) výchozím nastavení do a v SameSiteMode.None SameSiteMode.Lax uvedeném pořadí.

Nové chování

Všechna ovlivněná rozhraní API jsou ve výchozím nastavení SameSiteMode.None .

Důvod změny

Výchozí hodnota byla změněna tak, aby byla SameSite funkce výslovného souhlasu.

Každá komponenta, která generuje soubory cookie, musí rozhodnout, jestli SameSite je vhodná pro své scénáře. Zkontrolujte využití ovlivněných rozhraní API a znovu proveďte konfiguraci SameSite podle potřeby.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HTTP: synchronní v/v – zakázáno na všech serverech

Počínaje ASP.NET Core 3,0 jsou synchronní operace serveru ve výchozím nastavení zakázané.

Popis změny

AllowSynchronousIO je možnost na každém serveru, která povoluje nebo zakazuje synchronní rozhraní API pro vstupně-výstupní operace HttpRequest.Body.Read , jako jsou, HttpResponse.Body.Write a Stream.Flush . Tato rozhraní API jsou dlouhodobě zdrojem vláken vyčerpání a aplikace přestane reagovat. Počínaje verzí ASP.NET Core 3,0 Preview 3 jsou tyto synchronní operace ve výchozím nastavení zakázány.

Ovlivněné servery:

  • Kestrel
  • HttpSys
  • Vnitroprocesové v rámci služby IIS
  • TestServer

Očekávat chyby podobné:

  • 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á toto chování řídí a výchozí hodnota pro všechny jsou nyní false .

Chování je také možné přepsat na základě jednotlivých požadavků jako dočasné zmírnění. Například:

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

Pokud máte potíže s TextWriter nebo jiným datovým proudem, který volá synchronní rozhraní API v Dispose , zavolejte DisposeAsync místo toho nové rozhraní API.

Diskuzi najdete v tématu dotnet/aspnetcore # 7644.

Představená verze

3.0

Staré chování

HttpRequest.Body.Read``HttpResponse.Body.Write Stream.Flush ve výchozím nastavení byly povoleny.

Nové chování

Ve výchozím nastavení nejsou povolena tato synchronní rozhraní API:

Očekávat chyby podobné:

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

Důvod změny

Tato synchronní rozhraní API byla dlouhodobě zdrojem vláken vyčerpání a aplikace přestane reagovat. Počínaje verzí ASP.NET Core 3,0 Preview 3 jsou synchronní operace ve výchozím nastavení zakázané.

Použijte asynchronní verze metod. Chování je také možné přepsat na základě jednotlivých požadavků jako dočasné zmírnění.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Identita: Odebrání přetížení metody AddDefaultUI

Od ASP.NET Core verze 3.0 už přetížení metody IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) neexistuje.

Zavedená verze

3.0

Důvod změny

Tato změna byla výsledkem přijetí funkce statických webových prostředků.

Místo IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) přetížení, které přebírá dva argumenty, zavolejte metodu . Pokud používáte Bootstrap 3, přidejte do elementu v souboru projektu <PropertyGroup> také následující řádek:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identita: výchozí počáteční verze uživatelského rozhraní se změnila.

Počínaje ASP.NET Core 3,0 se v uživatelském rozhraní identity standardně používá verze 4 Bootstrap.

Představená verze

3.0

Staré chování

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();Volání metody bylo stejné jakoservices.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nové chování

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();Volání metody je stejné jakoservices.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Důvod změny

Služba Bootstrap 4 byla vydána během období ASP.NET Core 3,0.

Tuto změnu ovlivníte, pokud použijete výchozí uživatelské rozhraní identity a přidáte ho do 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í:

  • Migrujte aplikaci tak, aby používala Bootstrap 4 pomocí jejich Průvodce migrací.

  • Aktualizujte Startup.ConfigureServices , aby se vynutilo použití Bootstrap 3. Například:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Identita: SignInAsync vyvolá výjimku pro neověřenou identitu.

Ve výchozím nastavení SignInAsync vyvolá výjimku pro objekty zabezpečení/identity, ve kterých IsAuthenticated je false .

Představená verze

3.0

Staré chování

SignInAsync přijímá všechny objekty zabezpečení a identity, včetně identit IsAuthenticated false .

Nové chování

Ve výchozím nastavení SignInAsync vyvolá výjimku pro objekty zabezpečení/identity, ve kterých IsAuthenticated je false . Pro potlačení tohoto chování je k dispozici nový příznak, ale došlo ke změně výchozího chování.

Důvod změny

Původní chování bylo problematické, protože tyto objekty standardně byly odmítnuty nástrojem [Authorize] / RequireAuthenticatedUser() .

Ve RequireAuthenticatedSignIn AuthenticationOptions výchozím nastavení je ve verzi ASP.NET Core 3,0 Preview 6 příznak true . Nastavením tohoto příznaku false obnovíte původní chování.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Identita: konstruktor SignInManager akceptuje nový parametr.

Počínaje ASP.NET Core 3,0 IUserConfirmation<TUser> byl do konstruktoru přidán nový parametr SignInManager . Další informace naleznete v tématu dotnet/aspnetcore # 8356.

Představená verze

3.0

Důvod změny

Motivací pro změnu byla přidání podpory pro nové toky e-mailu a potvrzení identity.

Pokud vytváříte ručně SignInManager , Poskytněte implementaci IUserConfirmation nebo jeden ze injektáže závislosti, který má poskytnout.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SignInManager<TUser>

Identita: uživatelské rozhraní používá funkci statických webových prostředků.

ASP.NET Core 3,0 zavedlo funkci statického webového prostředku a uživatelské rozhraní identity ho přijalo.

Popis změny

Následkem toho, že uživatelské rozhraní identity přijímá funkci statických webových prostředků:

  • Výběr architektury je možné provést pomocí IdentityUIFrameworkVersion vlastnosti v souboru projektu.
  • Výchozím rozhraním uživatelského rozhraní identity je Bootstrap 4. Spouštěcí rutina 3 dosáhla konce životnosti a měli byste zvážit migraci na podporovanou verzi.

Představená verze

3.0

Staré chování

Výchozí architektura uživatelského rozhraní pro uživatelské rozhraní identity byla bootstrap 3. ROZHRANÍ .NET Framework by mohlo být nakonfigurováno pomocí parametru pro AddDefaultUI volání metody v Startup.ConfigureServices .

Nové chování

Výchozí architektura uživatelského rozhraní pro uživatelské rozhraní identity je bootstrap 4. ROZHRANÍ .NET Framework musí být nakonfigurováno v souboru projektu namísto AddDefaultUI volání metody.

Důvod změny

Při přijetí funkce statických webových prostředků se vyžaduje, aby se konfigurace architektury uživatelského rozhraní přesunula na MSBuild. Rozhodnutí, na které rozhraní vkládat, je rozhodnutí o době sestavení, ne rozhodnutí za běhu.

Zkontrolujte uživatelské rozhraní lokality a ujistěte se, že jsou nové součásti s rutinou Bootstrap 4 kompatibilní. V případě potřeby se pomocí IdentityUIFrameworkVersion vlastnosti MSBuild vraťte k rutině Bootstrap 3. Přidejte vlastnost do <PropertyGroup> prvku v souboru projektu:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: odebrané adaptéry připojení

V rámci přesunutí na přesun rozhraní API "pubternal" na public verzi IConnectionAdapter byl koncept odstraněn z Kestrel. Připojovací adaptéry se nahrazují pomocí middleware připojení (podobně jako middleware HTTP v kanálu ASP.NET Core, ale u připojení nižší úrovně). Protokolování HTTPS a připojení se přesunulo z připojovacích adaptérů na middleware připojení. Tyto metody rozšíření by měly nadále fungovat bez problémů, ale podrobnosti implementace se změnily.

Další informace naleznete v tématu dotnet/aspnetcore # 11412. Diskuzi najdete v tématu dotnet/aspnetcore # 11475.

Představená verze

3.0

Staré chování

Komponenty rozšiřitelnosti Kestrel byly vytvořeny pomocí IConnectionAdapter .

Nové chování

Komponenty rozšiřitelnosti Kestrel se vytvářejí jako middleware.

Důvod změny

Tato změna je určená k zajištění flexibilní rozšiřitelné architektury.

Převeďte všechny implementace IConnectionAdapter pro, aby používaly nový vzor middlewaru, jak je znázorněno zde.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

Kestrel: bylo odebráno prázdné sestavení HTTPS.

Bylo Microsoft.AspNetCore.Server.Kestrel.Https odebráno sestavení.

Představená verze

3.0

Důvod změny

V ASP.NET Core 2,1 byl obsah Microsoft.AspNetCore.Server.Kestrel.Https přesunut do Microsoft.AspNetCore.Server.Kestrel.Core . Tato změna byla provedena nevhodným způsobem, který používá [TypeForwardedTo] atributy.

  • Knihovny odkazující na Microsoft.AspNetCore.Server.Kestrel.Https 2,0 by měly aktualizovat všechny závislosti ASP.NET Core na 2,1 nebo novější. V opačném případě mohou při načtení do aplikace ASP.NET Core 3,0 dojít k přerušení.
  • Aplikace a knihovny cílené na ASP.NET Core 2,1 a novější by měly odebrat všechny přímé odkazy na Microsoft.AspNetCore.Server.Kestrel.Https balíček NuGet.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Kestrel: hlavičky přípojných vozidel žádosti přesunuté do nové kolekce

V předchozích verzích Kestrel přidal do kolekce hlaviček požadavků hlavičky přípojného bodu HTTP/1.1, když byl text požadavku přečtený na konci. Toto chování způsobilo obavy z nejednoznačnosti mezi hlavičkami a přípojnými vozidly. Rozhodnutí o přesunutí přípojných vozidel do nové kolekce bylo provedeno.

V ASP.NET Core 2,2 nejsou dostupné přípojné ovladače HTTP/2, ale teď jsou v této nové kolekci dostupné taky v ASP.NET Core 3,0.

Pro přístup k těmto přípojným vozidlům byly přidány nové metody rozšíření žádosti.

Po načtení celého textu žádosti jsou k dispozici Přípojná místa HTTP/1.1.

Po přijetí od klienta jsou k dispozici Přípojná místa HTTP/2. Klient nepošle přípojná vozidla, dokud celý text žádosti nebude alespoň ukládán do vyrovnávací paměti serverem. Možná budete muset přečíst text žádosti, abyste uvolnili místo ve vyrovnávací paměti. Pokud přečtete text žádosti na konec, jsou k dispozici vždy. Přípojná vozidla označují konec těla.

Představená verze

3.0

Staré chování

Do kolekce se přidají hlavičky žádosti o přípojné vozidlo HttpRequest.Headers .

Nové chování

V kolekci nejsou k dispozici hlavičky přípojných vozidel HttpRequest.Headers . HttpRequestPro přístup k nim použijte následující rozšiřující metody:

  • GetDeclaredTrailers() – Načte hlavičku Request "přívěs", která uvádí, která přípojná vozidla se mají po tělo očekávat.
  • SupportsTrailers() – Určuje, zda požadavek podporuje příjem hlaviček přípojných vozidel.
  • CheckTrailersAvailable() – Určuje, zda požadavek podporuje Přípojná místa, a pokud jsou k dispozici pro čtení.
  • GetTrailer(string trailerName) – Načte požadované koncové záhlaví z odpovědi.

Důvod změny

Přípojná vozidla jsou klíčovou funkcí ve scénářích, jako je gRPC. Sloučení přípojných vozidel v nástroji do hlaviček požadavků bylo matoucí pro uživatele.

HttpRequestPro přístup k přípojným vozidlům použijte metody rozšíření související s přívěsem.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HttpRequest.Headers

Kestrel: abstrakce přenosu se odebrala a provedla jako veřejná.

V rámci přesunu z rozhraní API přenosové vrstvy pubternal se rozhraní API transportní vrstvy Kestrel zveřejňují jako veřejné rozhraní v Microsoft.AspNetCore.Connections.Abstractions knihovně.

Představená verze

3.0

Staré chování

  • V knihovně jsou k dispozici abstrakce související s přenosem Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
  • ListenOptions.NoDelayVlastnost byla k dispozici.

Nové chování

  • IConnectionListenerRozhraní bylo představeno v Microsoft.AspNetCore.Connections.Abstractions knihovně, aby bylo možné vystavit z knihovny nejčastěji používané funkce ...Transport.Abstractions .
  • NoDelayJe nyní k dispozici v možnostech přenosu ( LibuvTransportOptions a SocketTransportOptions ).
  • SchedulingMode již není k dispozici.

Důvod změny

ASP.NET Core 3,0 se přesunuly z rozhraní API "pubternal".

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Lokalizace: ResourceManagerWithCultureStringLocalizer a WithCulture označené jako zastaralé

Člen třídy ResourceManagerWithCultureStringLocalizer a rozhraní WithCulture jsou často zdrojem nejasností pro uživatele lokalizace, zejména při vytváření vlastní IStringLocalizer implementace. Tyto položky přidávají uživateli dojem, že IStringLocalizer je instance "na jazyk, podle prostředků". Ve skutečnosti by měly být instance pouze "za prostředek". Hledaný jazyk je určen v CultureInfo.CurrentUICulture době spuštění. aby se vyloučil zdroj nejasností, rozhraní api byla v ASP.NET Core 3,0 Preview 3 označená jako zastaralá. Rozhraní API se v budoucí verzi odeberou.

Pro kontext viz dotnet/aspnetcore # 3324. Diskuzi najdete v tématu dotnet/aspnetcore # 7756.

Představená verze

3.0

Staré chování

Metody nebyly označeny jako Obsolete .

Nové chování

Metody jsou označeny Obsolete .

Důvod změny

Rozhraní API představovaly případ použití, který se nedoporučuje. Při návrhu lokalizace došlo k nejasnostem.

Doporučujeme ResourceManagerStringLocalizer místo toho použít. Povolit jazykovou verzi nastavením CurrentCulture . Pokud to není možnost, vytvořte a použijte kopii ResourceManagerWithCultureStringLocalizer.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Protokolování: DebugLogger třída provedla interní

Před ASP.NET Core 3,0 DebugLogger byl modifikátor přístupu public . V ASP.NET Core 3,0 se modifikátor přístupu změnil na internal .

Představená verze

3.0

Důvod změny

Změna je provedena na:

  • Vyvynuťte konzistenci s jinými implementacemi protokolovacího nástroje, jako je ConsoleLogger .
  • Snižte plochu rozhraní API.

AddDebug ILoggingBuilder K povolení protokolování ladění použijte metodu rozšíření. DebugLoggerProvider je také stále public v případě, že je nutné zaregistrovat službu ručně.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: asynchronní přípona se ořízne z názvů akcí řadiče.

Jako součást adresování dotnet/aspnetcore # 4849ASP.NET Core MVC Async ve výchozím nastavení ořízne příponu z názvů akcí. Od ASP.NET Core 3,0 Tato změna ovlivní vytváření směrování i propojení.

Představená verze

3.0

Staré chování

Vezměte v úvahu následující ASP.NET Core kontroler 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í Async přípony. Například:

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

Nové chování

V ASP.NET Core 3,0 je akce směrovatelný přes Product/List . Kód pro generování odkazů by měl vynechat Async příponu. Například:

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

Tato změna nemá vliv na názvy zadané pomocí [ActionName] atributu. Nové chování je možné zakázat nastavením MvcOptions.SuppressAsyncSuffixInActionNames na false v Startup.ConfigureServices :

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

Důvod změny

Podle konvence jsou asynchronní metody rozhraní .NET s příponou Async . Nicméně když Metoda definuje akci MVC, je nežádoucí použít Async příponu.

Pokud vaše aplikace závisí na akcích MVC, na kterých se zachovává Async Přípona názvu, vyberte jedno z následujících rizik:

  • Použijte [ActionName] atribut k zachování původního názvu.
  • Zakažte úplné přejmenování nastavením MvcOptions.SuppressAsyncSuffixInActionNames na false v Startup.ConfigureServices :
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

MVC: JsonResult se přesunula do Microsoft. AspNetCore. Mvc. Core.

JsonResult byl přesunut do Microsoft.AspNetCore.Mvc.Core sestavení. Tento typ se používá pro definování v Microsoft.AspNetCore.Mvc.Formatters.Js. Byl přidán atribut na úrovni sestavení [TypeForwardedTo] k Microsoft.AspNetCore.Mvc.Formatters.Json tomuto problému pro většinu uživatelů. V aplikacích, které používají knihovny třetích stran, může dojít k problémům.

Představená verze

3,0 Preview 6

Staré chování

Aplikace, která používá sestavení knihovny založené na 2,2, se úspěšně sestavuje.

Nové chování

V aplikaci, která používá knihovnu založenou na 2,2, se kompilace nezdařila. K dispozici je chyba obsahující variaci 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 naleznete v tématu dotnet/aspnetcore # 7220.

Důvod změny

Změny na úrovni platformy pro složení ASP.NET Core, jak je popsáno v tématu ASPNET/oznámení # 325.

Knihovny zkompilované proti verzi 2,2 nástroje Microsoft.AspNetCore.Mvc.Formatters.Json mohou být nutné znovu kompilovat, aby vyřešily problém pro všechny uživatele. Pokud je to ovlivněno, obraťte se na autora knihovny. Požadavek na opětovnou kompilaci knihovny pro cílovou ASP.NET Core 3,0.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Nástroj předkompilace je zastaralý

V ASP.NET Core verzi 1.1 byl představen balíček (nástroj předkompilace MVC), který přidá podporu pro kompilaci souborů Razor v době publikování Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (soubory .cshtml). V ASP.NET Core verze 2.1 byla zavedena sada Razor SDK, která rozšiřuje funkce nástroje předkompilace. Sada Razor SDK přidala podporu kompilace souborů Razor v době sestavení a publikování. Sada SDK ověřuje správnost souborů .cshtml v době sestavení a současně zlepšuje dobu spuštění aplikace. Sada Razor SDK je ve výchozím nastavení povolená a k tomu, aby ji bylo možné začít používat, není potřeba žádné gesto.

V ASP.NET Core verzi 3.0 byl ASP.NET Core předkompilace MVC 1.1. Starší verze balíčků budou nadále dostávat důležité opravy chyb a zabezpečení ve verzi oprav.

Zavedená verze

3.0

Staré chování

Balíček Microsoft.AspNetCore.Mvc.Razor.ViewCompilation se použil k předběžné kompilaci zobrazení MVC Razor.

Nové chování

Sada Razor SDK tuto funkci nativně podporuje. Balíček Microsoft.AspNetCore.Mvc.Razor.ViewCompilation už není aktualizovaný.

Důvod změny

Sada Razor SDK poskytuje více funkcí a ověřuje správnost souborů .cshtml v době sestavení. Sada SDK také vylepšuje dobu spuštění aplikace.

Pro uživatele ASP.NET Core verze 2.1 nebo novější použijte nativní podporu předkompilace v sadě Razor SDK. Pokud migraci na sadu Razor SDK brání chyby nebo chybějící funkce, otevřete problém na adrese dotnet/aspnetcore.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

MVC: typy "Pubternal" se změnily na interní

V ASP.NET Core 3,0 se všechny typy "pubternal" v MVC aktualizovaly buď public v podporovaném oboru názvů, nebo internal podle potřeby.

Popis změny

V ASP.NET Core jsou typy "pubternal" deklarovány jako, ale nacházejí se public v .Internal oboru názvů s příponou. I když jsou tyto typy public , nemají žádné zásady podpory a podléhají změnám. Omlouváme se, ale náhodné použití těchto typů je běžné, což vedlo k zásadním změnám těchto projektů a omezení schopnosti zachovat rozhraní.

Představená verze

3.0

Staré chování

Některé typy v MVC byly, public ale v .Internal oboru názvů. Tyto typy neobsahovaly žádné zásady podpory a měly by podléhat nezměněným změnám.

Nové chování

Všechny tyto typy jsou aktualizovány buď tak, aby byly public v podporovaném oboru názvů nebo označeny jako internal .

Důvod změny

Náhodné použití typů "pubternal" bylo běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti zachovat rozhraní.

Pokud používáte typy, které se stanou skutečně public 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čeny jako, bude internal nutné najít alternativu. Předchozí typy "pubternal" nebyly nikdy podporovány pro veřejné použití. Pokud existují konkrétní typy v těchto oborech názvů, které jsou pro vaše aplikace kritické, zapište problém v dotnet/aspnetcore. Mohou být provedeny důvody pro vytvoření požadovaných typů public .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

MVC: překrytí kompatibility webového rozhraní API se odebralo.

Počínaje ASP.NET Core 3,0 Microsoft.AspNetCore.Mvc.WebApiCompatShim není balíček již k dispozici.

Popis změny

Microsoft.AspNetCore.Mvc.WebApiCompatShimBalíček (WebApiCompatShim) poskytuje částečnou kompatibilitu v ASP.NET Core s webovým rozhraním API 2 ASP.NET 4. x pro zjednodušení migrace stávajících implementací webového rozhraní API do ASP.NET Core. Aplikace, které používají WebApiCompatShim, ale netěží z funkcí souvisejících s rozhraním API, které se dodávají v posledních ASP.NET Core verzích. Mezi tyto funkce patří vylepšené generování specifikace Open API, standardizované zpracování chyb a generování kódu klienta. Aby se zajistilo lepší zaměření na úsilí rozhraní API v 3,0, odebral se WebApiCompatShim. Stávající aplikace, které používají WebApiCompatShim, by se měly migrovat do novějšího [ApiController] modelu.

Představená verze

3.0

Důvod změny

Překrytí kompatibility webového rozhraní API je 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 překrytí a přímo se migrujte na podobné funkce v ASP.NET Core samotné.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: rozhraní API RazorTemplateEngine bylo odebráno

Rozhraní API RazorTemplateEngine se odebralo a nahradilo RazorProjectEngine .

diskuzi najdete v tématu GitHub problém dotnet/aspnetcore # 25215.

Představená verze

3.0

Staré chování

Modul šablon lze vytvořit a použít k analýze a generování kódu pro soubory Razor.

Nové chování

RazorProjectEngine lze vytvořit a poskytnout stejný typ informací pro RazorTemplateEngine analýzu a generování kódu pro soubory Razor. RazorProjectEngine poskytuje také dodatečné úrovně konfigurace.

Důvod změny

RazorTemplateEngine byl příliš pevně spojen s existující implementací. Toto těsné spojení vedlo k dalším otázkám při pokusu o správnou konfiguraci kanálu analýzy/generování Razor.

RazorProjectEngineMísto použijte RazorTemplateEngine . Vezměte v úvahu následující příklady.

Vytvoření a konfigurace RazorProjectEngine
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

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

            // More configuration can go here
        });
Vygenerovat kód pro soubor Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Razor: kompilace za běhu byla přesunuta do balíčku

Podpora pro kompilaci za běhu zobrazení Razor a Razor Pages se přesunula do samostatného balíčku.

Představená verze

3.0

Staré chování

Kompilace za běhu je k dispozici bez nutnosti dalších balíčků.

Nové chování

Funkce se přesunula do balíčku Microsoft. AspNetCore. Mvc. Razor. RuntimeCompilation .

Následující rozhraní API byly dříve k dispozici v Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions pro podporu kompilace modulu runtime. 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 se Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange odebralo. Opětovná kompilace při změnách souborů je ve výchozím nastavení povolená odkazem na Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation balíček.

Důvod změny

Tato změna byla nutná pro odebrání závislostí sdíleného rozhraní ASP.NET Core v Roslyn.

Aplikace, které vyžadují kompilaci za běhu nebo opětovnou kompilaci souborů Razor, by měly provést následující kroky:

  1. Přidejte do Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation balíčku odkaz.

  2. Aktualizujte metodu projektu Startup.ConfigureServices tak, aby zahrnovala volání AddRazorRuntimeCompilation . Například:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Stav relace: odebrané zastaralé rozhraní API

Odebrala se zastaralá rozhraní API pro konfiguraci souborů cookie relací. Další informace najdete v tématu ASPNET/oznámení # 257.

Představená verze

3.0

Důvod změny

Tato změna vynutila konzistenci napříč rozhraními API pro konfiguraci funkcí, které používají soubory cookie.

Migrujte využití odebraných rozhraní API na jejich novější náhrady. Vezměte v úvahu následující příklad 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;
    });
}

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Sdílená rozhraní: Sestavení odebraná z Microsoft.AspNetCore.App

Počínaje ASP.NET Core 3.0 obsahuje sdílená ASP.NET Core () pouze sestavení první strany, která jsou plně vyvinutá, podporovaná a s podporou Microsoft.AspNetCore.App služeb společnosti Microsoft.

Popis změny

Změnu si můžete myslet jako na nové nastavení hranic pro ASP.NET Core platformy. Sdílená rozhraní bude možné vytvářet na zdroji kdokoli prostřednictvím GitHub a bude vašim aplikacím dál nabízet stávající výhody sdílených architektur .NET Core. Mezi výhody patří menší velikost nasazení, centralizované opravy a rychlejší spuštění.

V rámci této změny jsou některé z ovatelných změn představeny v Microsoft.AspNetCore.App .

Zavedená verze

3.0

Staré chování

Projekty Microsoft.AspNetCore.App odkazované <PackageReference> prostřednictvím elementu v souboru projektu.

Kromě toho Microsoft.AspNetCore.App obsahovaly následující dílčí komponenty:

  • Json.NET ( Newtonsoft.Json )
  • Entity Framework Core (sestavení s předponou Microsoft.EntityFrameworkCore. )
  • Roslyn ( Microsoft.CodeAnalysis )

Nové chování

Odkaz na Microsoft.AspNetCore.App už nevyžaduje prvek v souboru <PackageReference> projektu. Třída .NET Core SDK 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 NuGet balíčky. Tato změna zarovnává 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 současně podporovat různé platformy .NET. Přesun Entity Framework Core ze sdílené architektury nemá žádný vliv na její stav jako knihovna vyvinutá Microsoftem, která podporuje a nabízí služby. Zásady podpory .NET Core ji nadále pokrývají.

Json.NET a Entity Framework Core nadále pracovat s ASP.NET Core. Nebudou však zahrnuty do sdílené architektury.

Další informace najdete v tématu Budoucnost formátu JSON v .NET Core 3.0. Podívejte se také na úplný seznam binárních souborů odebraných ze sdílené architektury.

Důvod změny

Tato změna zjednodušuje spotřebu a snižuje Microsoft.AspNetCore.App duplikaci mezi NuGet a sdílenými rozhraními.

Další informace o motivaci pro tuto změnu najdete v tomto blogovém příspěvku.

Počínaje ASP.NET Core 3.0 už není nutné, aby projekty spotřebovává sestavení v jako NuGet Microsoft.AspNetCore.App balíčky. Pro zjednodušení cílení a používání sdílené architektury ASP.NET Core se mnoho balíčků NuGet od verze ASP.NET Core 1.0 už neprodukuje. Rozhraní API, která tyto balíčky poskytují, jsou pro aplikace stále dostupná pomocí <FrameworkReference> rozhraní do 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 ve Microsoft.AspNetCore.App ASP.NET Core 2.x. Mezi tyto výjimky patří:

  • Microsoft.ExtensionsKnihovny, které nadále cílí na .NET Standard, jsou k dispozici jako NuGet balíčky (viz https://github.com/dotnet/extensions ).
  • Rozhraní API vytvořená týmem ASP.NET Core, která nejsou součástí Microsoft.AspNetCore.App . Například následující komponenty jsou k dispozici jako NuGet balíčky:
    • Entity Framework Core
    • Rozhraní API, která poskytují integraci třetích stran
    • Experimentální funkce
    • Rozhraní API se závislostmi, které nesplnily požadavky na to, aby byly ve sdíleném rozhraní
  • Rozšíření MVC, která udržují podporu pro Json.NET. Rozhraní API je k dispozici jako NuGet pro podporu používání Json.NET a MVC. Další podrobnosti najdete ASP.NET Core průvodce migrací dat.
  • Klient SignalR .NET dál podporuje .NET Standard a dodává se jako NuGet balíček. Je určená pro použití v mnoha modulech runtime .NET, jako je Xamarin a UPW.

Další informace naleznete v části Stop producing packages for shared framework assemblies in 3.0. Diskuzi najdete v tématu dotnet/aspnetcore#3757.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Sdílené rozhraní: odebrali jsme Microsoft. AspNetCore. All.

Počínaje ASP.NET Core 3,0 se Microsoft.AspNetCore.All již nevyrábí Metapackage a vyhovující Microsoft.AspNetCore.All sdílené rozhraní. Tento balíček je k dispozici v ASP.NET Core 2,2 a bude nadále získávat aktualizace údržby v ASP.NET Core 2,1.

Představená verze

3.0

Staré chování

Aplikace můžou použít Microsoft.AspNetCore.All Metapackage k cílení na Microsoft.AspNetCore.All sdílené rozhraní .NET Core.

Nové chování

.NET Core 3,0 nezahrnuje Microsoft.AspNetCore.All sdílené rozhraní.

Důvod změny

Microsoft.AspNetCore.AllMetapackage zahrnoval velký počet externích závislostí.

Migrujte projekt pro použití Microsoft.AspNetCore.App rozhraní .NET Framework. Komponenty, které byly dříve k dispozici v nástroji, Microsoft.AspNetCore.All jsou stále k dispozici v NuGet. Tyto komponenty se teď nasazují s vaší aplikací, takže se nezahrne do sdíleného rozhraní.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Signál: HandshakeProtocol. SuccessHandshakeData nahrazeno

Pole HandshakeProtocol. SuccessHandshakeData se odebralo a nahradilo pomocnou metodou, která vygeneruje úspěšnou odpověď handshake určenou konkrétní IHubProtocol .

Představená verze

3.0

Staré chování

HandshakeProtocol.SuccessHandshakeData bylo public static ReadOnlyMemory<byte> pole.

Nové chování

HandshakeProtocol.SuccessHandshakeData byl nahrazen static GetSuccessfulHandshake(IHubProtocol protocol) metodou, která vrací na ReadOnlyMemory<byte> základě zadaného protokolu.

Důvod změny

Do odpovědi handshake byly přidány další pole, která nejsou konstantní a mění se v závislosti na vybraném protokolu.

Žádné Tento typ není určený pro použití z uživatelského kódu. Je to public tak, aby se mohlo sdílet mezi serverem a klientem signalizace. Můžou je používat i klienti návěstí zákazníka napsané v .NET. Tato změna by neměla mít vliv na uživatele signálu.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HandshakeProtocol.SuccessHandshakeData

Signál: odebraly se HubConnection ResetSendPing a metody ResetTimeout.

ResetSendPingMetody a ResetTimeout byly odebrány z rozhraní API pro signalizaci HubConnection . Tyto metody byly původně určeny pouze pro interní použití, ale byly zveřejněny v 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.

Představená verze

3.0

Staré chování

Rozhraní API jsou k dispozici.

Nové chování

Rozhraní API se odeberou.

Důvod změny

Tyto metody byly původně určeny pouze pro interní použití, ale byly zveřejněny v ASP.NET Core 2,2.

Tyto metody nepoužívejte.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Signál: HubConnectionContext konstruktory se změnily.

HubConnectionContextKonstruktory signalizace se změnily tak, aby přijímaly typ možností, nikoli několik parametrů, k budoucímu přidání možností. Tato změna nahrazuje dva konstruktory jedním konstruktorem, který přijímá typ možností.

Představená verze

3.0

Staré chování

HubConnectionContext má dva konstruktory:

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

Nové chování

Dva konstruktory se odebraly a nahradily jedním konstruktorem:

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

Důvod změny

Nový konstruktor používá nový objekt Options. V důsledku toho HubConnectionContext mohou být funkce nástroje rozšířeny v budoucnu bez nutnosti vytvářet další konstruktory a zásadní změny.

Namí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);

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Signal: změnil se název balíčku klienta JavaScript

V ASP.NET Core 3,0 Preview 7 se název klientského balíčku JavaScriptu pro signály změnil z @aspnet/signalr na @microsoft/signalr . Tato změna názvu odráží skutečnost, že signál je užitečný ve více než jenom ASP.NET Corech aplikacích díky službě Azure Signaler.

Chcete-li reagovat na tuto změnu, změňte odkazy v package.jsna soubory, require příkazy a příkazy jazyka ECMAScript import . V rámci tohoto přejmenování se žádné rozhraní API nemění.

Diskuzi najdete v tématu dotnet/aspnetcore # 11637.

Představená verze

3.0

Staré chování

Balíček klienta byl pojmenován @aspnet/signalr .

Nové chování

Balíček klienta má název @microsoft/signalr .

Důvod změny

Změna názvu upřesňuje, že je signál, který je užitečný pro ASP.NET Core aplikace, díky službě Azure Signal Service.

Přepněte do nového balíčku @microsoft/signalr .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Signál: metody UseSignalR a UseConnections označené jako zastaralé

Metody UseConnections a UseSignalR a třídy ConnectionsRouteBuilder a HubRouteBuilder jsou označeny jako zastaralé v ASP.NET Core 3,0.

Představená verze

3.0

Staré chování

Směrování centra signalizace bylo nakonfigurováno pomocí UseSignalR nebo UseConnections .

Nové chování

Starý způsob konfigurace směrování se zastaral a nahradil směrováním koncových bodů.

Důvod změny

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

Nahradit UseSignalR UseEndpoints :

Starý kód:

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

Nový kód:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Jednostránkové: SpaServices a NodeServices označené jako zastaralé

Obsah následujících balíčků NuGet byl od ASP.NET Core 2,1 zbytečný. V důsledku toho jsou následující balíčky označeny jako zastaralé:

Ze stejného důvodu jsou následující moduly npm označeny jako zastaralé:

Předchozí balíčky a moduly npm budou později odebrány v rozhraní .NET 5.

Představená verze

3.0

Staré chování

Zastaralé balíčky a moduly npm byly určeny k integraci ASP.NET Core s různými architekturami aplikace Single-Page (SPA). Mezi takové architektury patří úhlová, reakce a reakce na Redux.

Nové chování

V balíčku NuGet Microsoft. AspNetCore. SpaServices. Extensions existuje nový integrační mechanismus. Balíček zůstává základem úhlů a Reagujecích šablon projektů od ASP.NET Core 2,1.

Důvod změny

ASP.NET Core podporuje integraci s různými architekturami aplikace Single-Page (SPA), včetně úhlů, reakce a reakce na Redux. Zpočátku se integrace s těmito rozhraními provedla s ASP.NET Core specifickými komponentami, které zpracovávají scénáře jako předběžné vykreslování na straně serveru a integraci s nástrojem Webpack. V době, kdy došlo k úpravě, se oborové standardy změnily. Každé rozhraní zabezpečeného ověřování hesla uvolnilo vlastní standardní rozhraní příkazového řádku. Například úhlové CLI a vytvořit reakci-aplikace.

Po vydání ASP.NET Core 2,1 do května 2018 tým odpověděl na změnu v normách. Byl poskytnut novější a jednodušší způsob, jak integrovat s vlastními sady nástrojů architekturou SPA. V balíčku existuje nový integrační mechanismus, který Microsoft.AspNetCore.SpaServices.Extensions zůstává základem úhlů a reagujecích šablon projektů od ASP.NET Core 2,1.

Pro objasnění, že starší součásti specifické pro ASP.NET Core jsou důležité a nedoporučuje se:

  • Mechanismus Integration pre-2,1 je označený jako zastaralý.
  • Podpůrné balíčky npm jsou označeny jako zastaralé.

Pokud tyto balíčky používáte, aktualizujte aplikace tak, aby používaly tyto funkce:

  • V Microsoft.AspNetCore.SpaServices.Extensions balíčku.
  • Poskytované rozhraními zabezpečeného hesla, které používáte

Pokud chcete povolit funkce, jako je například předběžné vykreslení na straně serveru a Hot Module reload, přečtěte si dokumentaci pro odpovídající architekturu SPA. Funkce v Microsoft.AspNetCore.SpaServices.Extensions není zastaralá a bude i nadále podporována. not

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Jednostránkové: SpaServices a NodeServices se už nevrátí do protokolovacího nástroje konzoly.

Microsoft.AspNetCore.SpaServices a Microsoft.AspNetCore.NodeServices nebude zobrazovat protokoly konzoly, pokud není nakonfigurováno protokolování.

Představená verze

3.0

Staré chování

Microsoft.AspNetCore.SpaServices a Microsoft.AspNetCore.NodeServices používá se k automatickému vytvoření protokolovacího nástroje konzoly, když protokolování není nakonfigurované.

Nové chování

Microsoft.AspNetCore.SpaServices a Microsoft.AspNetCore.NodeServices nebude zobrazovat protokoly konzoly, pokud není nakonfigurováno protokolování.

Důvod změny

Je potřeba se zarovnávat s tím, jak jiné balíčky ASP.NET Core implementují protokolování.

Pokud je vyžadováno staré chování, pro konfiguraci protokolování konzoly přidejte services.AddLogging(builder => builder.AddConsole()) do Setup.ConfigureServices metody.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Cílová architektura: Zahozená podpora .NET Framework

Počínaje ASP.NET Core 3,0 .NET Framework je Nepodporovaná Cílová architektura.

Popis změny

.NET Framework 4,8 je poslední hlavní verzí .NET Framework. Nové aplikace ASP.NET Core by měly být postavené na .NET Core. Od verze .NET Core 3,0 můžete si představit ASP.NET Core 3,0 jako součást .NET Core.

Zákazníci, kteří používají ASP.NET Core s .NET Framework, můžou v plně podporovaném způsobem i nadále používat LTS vydání verze 2,1. Podpora a údržba pro 2,1 pokračuje do 21. srpna 2021. Toto datum je tři roky po deklaraci verze LTS podle zásady podpory .NET. Podpora pro balíčky ASP.NET Core 2,1 v .NET Framework se nebude zobrazovat po neomezenou dobu, podobně jako zásady údržby pro jiné ASP.NET architektury založené na balíčku.

Další informace o přenosech z .NET Framework do .NET Core najdete v tématu přenos do .NET Core.

Microsoft.Extensions balíčky (například protokolování, vkládání závislostí a konfigurace) a Entity Framework Core nejsou ovlivněné. Budou dál podporovat .NET Standard.

Další informace o motivaci této změny najdete v původním blogovém příspěvku.

Představená verze

3.0

Staré chování

Aplikace ASP.NET Core mohou běžet buď na rozhraní .NET Core, nebo v .NET Framework.

Nové chování

Aplikace ASP.NET Core lze spustit pouze v .NET Core.

Proveďte jednu z následujících akcí:

  • Udržujte svou aplikaci na ASP.NET Core 2,1.
  • Migrujte svoji aplikaci a závislosti do .NET Core.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Žádné

Knihovny Core .NET

Rozhraní API, která verze sestav nyní hlásí produkt a nikoli verzi souboru

Mnoho rozhraní API, které vrací verze v rozhraní .NET Core, nyní vrátí verzi produktu místo verze souboru.

Popis změny

V .NET Core 2,2 a předchozích verzích metody jako Environment.Version , RuntimeInformation.FrameworkDescription a dialog vlastností souboru pro sestavení .NET Core odrážejí verzi souboru. Počínaje .NET Core 3,0 se odrážejí verze 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 (na pravé straně), jak je zobrazeno v dialogovém okně Vlastnosti souboru v Průzkumníkovi Windows .

Rozdíl v informacích o verzi produktu

Představená verze

3.0

Žádné Tato změna by měla v případě, že by byla detekce verze intuitivní, spíše než obtuse.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Vlastní instance EncoderFallbackBuffer se nemůžou vrátit rekurzivně.

Vlastní EncoderFallbackBuffer instance nemůžou vracet rekurzivně zpátky. Implementace EncoderFallbackBuffer.GetNextChar() musí mít za následek sekvenci znaků, která je převoditelná na cílové kódování. V opačném případě dojde k výjimce.

Popis změny

Během operace překódování znaků modul runtime detekuje nesprávně vytvořené sekvence UTF-16 a poskytuje tyto znaky EncoderFallbackBuffer.Fallback metodě. FallbackMetoda určuje, které znaky by měly být nahrazeny původními nepřevoditelnými daty a tyto znaky jsou vynásobeny voláním EncoderFallbackBuffer.GetNextChar ve smyčce.

Modul runtime se pak pokusí překódovat tyto náhradní znaky do cílového kódování. Pokud tato operace proběhne úspěšně, modul runtime pokračuje v kódování z místa, kde bylo ponecháno v původním vstupním řetězci.

Dříve vlastní implementace nástroje EncoderFallbackBuffer.GetNextChar() mohou vracet sekvence znaků, které nelze převést na cílové kódování. Pokud nahrazené znaky nelze překódovat do cílového kódování, modul runtime EncoderFallbackBuffer.Fallback ihned vyvolá metodu s náhradními znaky a očekává, že EncoderFallbackBuffer.GetNextChar() Metoda vrátí novou sekvenci nahrazení. Tento proces pokračuje, dokud modul runtime nakonec nenalezne dobře vytvořenou, převoditelnou substituci nebo až do dosažení maximálního počtu rekurzí.

Počínaje .NET Core 3,0, vlastní implementace EncoderFallbackBuffer.GetNextChar() musí vracet sekvence znaků, které jsou převoditelné na cílové kódování. Pokud nahrazené znaky nelze překódovat do cílového kódování, ArgumentException je vyvolána výjimka. Modul runtime již nebude do instance volat rekurzivní volání EncoderFallbackBuffer .

Toto chování platí pouze v případě, že jsou splněny všechny tři z následujících podmínek:

  • Modul runtime detekuje nesprávně vytvořenou sekvenci UTF-16 nebo sekvenci UTF-16, kterou nelze převést na cílové kódování.
  • Byla zadána vlastní aplikace EncoderFallback .
  • Vlastní EncoderFallback pokusy o náhradu nové sekvence UTF-16, která se nesprávně vytvořila nebo nepřevoditelná.

Představená verze

3.0

Většina vývojářů nemusí podepisovat nějakou akci.

Pokud aplikace používá vlastní EncoderFallback třídu a, ujistěte se, že EncoderFallbackBuffer implementace EncoderFallbackBuffer.Fallback naplní záložní vyrovnávací paměť se správnými daty UTF-16, která je přímo převoditelná na cílové kódování, když Fallback je metoda poprvé vyvolána modulem runtime.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Změna formátování s plovoucí desetinnou čárkou a parsování chování

Parsování a formátování s plovoucí desetinnou čárkou (podle typů a ) je teď kompatibilní se standardem Double Single IEEE. Tím se zajistí, že chování typů s plovoucí desetinnou čárkou v rozhraní .NET odpovídá chování jiných jazyků kompatibilních se standardem IEEE. Například by měl double.Parse("SomeLiteral") vždy odpovídat tomu, co jazyk C# vytvoří pro double x = SomeLiteral .

Popis změny

V .NET Core 2.2 a starších verzích formátování s a a parsování pomocí , , a není kompatibilní se standardem Double.ToString Single.ToString Double.Parse Double.TryParse Single.Parse Single.TryParse IEEE. V důsledku toho není možné zaručit, že se hodnota zaokrouhlí s libovolným podporovaným řetězcem standardního nebo vlastního formátu. 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í desetinnou čá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
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Další informace najdete v blogovém příspěvku o analýze a formátování s plovoucí desetinnou čárkou v .NET Core 3.0.

Zavedená verze

3.0

Část Potenciální dopad na existující kód v blogovém příspěvku o analýze a formátování s plovoucí desetinnou čárkou v .NET Core 3.0 navrhuje některé změny, které můžete v kódu provést, pokud chcete zachovat předchozí chování.

  • Pro některé rozdíly ve formátování můžete získat chování ekvivalentní předchozímu chování zadáním jiného formátovacího řetězce.
  • V případě rozdílů v parsování neexistuje žádný mechanismus, jak se vrátit k předchozímu chování.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Operace analýzy s plovoucí desetinnou čárkou již nejsou úspěšné nebo vyvolávají výjimku OverflowException

Metody analýzy s plovoucí desetinnou čárkou již nejsou OverflowException false při analýze řetězce, jehož číselná hodnota je mimo rozsah Single nebo typ s plovoucí desetinnou čárkou, vyhozeny nebo vraceny Double .

Popis změny

V .NET Core 2,2 a starších verzích Double.Parse Single.Parse metody a vyvolávají výjimku OverflowException pro hodnoty, které jsou mimo rozsah jejich příslušného typu. Double.TryParseMetody a Single.TryParse vrátí false pro řetězcové reprezentace číselných hodnot mimo rozsah.

Počínaje rozhraním .NET Core 3,0, Double.Parse metody,, a se Double.TryParse Single.Parse Single.TryParse již nedaří při analýze číselných řetězců mimo rozsah. Místo toho Double metody analýzy vrátí Double.PositiveInfinity pro hodnoty, které překračují Double.MaxValue , a vrátí Double.NegativeInfinity hodnotu, která je menší než Double.MinValue . Podobně Single metody analýzy vrátí Single.PositiveInfinity pro hodnoty, které překračují Single.MaxValue , a vrátí Single.NegativeInfinity pro hodnoty, které jsou menší než Single.MinValue .

Tato změna byla provedena pro zlepšení dodržování standardů IEEE 754:2008.

Představená verze

3.0

Tato změna může mít vliv na váš kód některým ze dvou způsobů:

  • Váš kód závisí na obslužné rutině, OverflowException která se má provést, když dojde k přetečení. V takovém případě byste měli příkaz odebrat catch a umístit jakýkoli 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í desetinnou čárkou nejsou Infinity . V takovém případě byste měli přidat potřebný kód pro kontrolu hodnot s plovoucí desetinnou čárkou PositiveInfinity a NegativeInfinity .

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

InvalidAsynchronousStateException – přesunuté do jiného sestavení

InvalidAsynchronousStateExceptionTřída byla přesunuta.

Popis změny

V rozhraní .NET Core 2,2 a starších verzích se InvalidAsynchronousStateException Třída nachází v sestavení System. ComponentModel. TypeConverter .

Počínaje rozhraním .NET Core 3,0 se nachází v sestavení System. ComponentModel. primitivs .

Představená verze

3.0

Tato změna ovlivní pouze aplikace, které používají reflexe k načtení InvalidAsynchronousStateException 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ě aktualizujte sestavení odkazované v volání metody, aby odráželo umístění nového sestavení typu.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Žádné

Výměna chybně formátovaných sekvencí UTF-8 se řídí pokyny pro kódování Unicode

Když UTF8Encoding Třída narazí na nesprávně vytvořenou sekvenci bajtů UTF-8 během operace překódování typu Byte-Character, nahradí tuto sekvenci znakem (U + FFFD náhradní znak) ve výstupním řetězci. .NET Core 3,0 se liší od předchozích verzí rozhraní .NET Core a .NET Framework podle osvědčeného postupu Unicode pro provádění této náhrady během operace překódování.

Toto je část větší snahy o zlepšení zpracování UTF-8 v rámci .NET, včetně nových System.Text.Unicode.Utf8 System.Text.Rune typů a. UTF8EncodingByl tento typ dán lepším způsobem zpracování chyb, aby byl výstup konzistentní s nově zavedený typy.

Popis změny

Počínaje .NET Core 3,0, při překódování bajtů na znaky, UTF8Encoding třída provádí substituci znaků na základě osvědčených postupů Unicode. Použití náhradního mechanismu je popsané standardem Unicode verze 12,0, sec. 3,9 (PDF) v hlavičce s názvem U + FFFD nahrazením maximálního počtu částí.

Toto chování se vztahuje jenom v případě, že vstupní bajtová sekvence obsahuje nesprávně vytvořená data UTF-8. Kromě toho, pokud UTF8Encoding instance byla vytvořena pomocí throwOnInvalidBytes: true , UTF8Encoding instance bude pokračovat v vyvolání neplatného vstupu místo provedení nahrazení u + FFFD. Další informace o UTF8Encoding konstruktoru naleznete v tématu UTF8Encoding(Boolean, Boolean) .

Následující tabulka ilustruje dopad této změny s neplatným 3 bajty vstupu:

Nesprávně vytvořený 3 bajtový vstup Výstup před .NET Core 3,0 Výstup od .NET Core 3,0
[ ED A0 90 ] [ FFFD FFFD ] (2 – výstup znaku) [ FFFD FFFD FFFD ] (výstup 3 znaky)

Výstup 3-Char je preferovaný výstup podle tabulky 3-9 dříve propojeného PDF standardu Unicode.

Představená verze

3.0

V rámci vývojáře není vyžadována žádná akce.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

TypeDescriptionProviderAttribute přesunuté do jiného sestavení

TypeDescriptionProviderAttributeTřída byla přesunuta.

Popis změny

V rozhraní .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 .

Představená verze

3.0

Tato změna ovlivní pouze aplikace, které používají reflexe 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é v volání metody mělo aktualizovat tak, aby odráželo nové umístění sestavení typu.

Kategorie

Windows Forms

Ovlivněná rozhraní API

Žádné

ZipArchiveEntry už nezpracovává archivy s nekonzistentními velikostmi záznamů.

Archivy zip uvádějí komprimovanou velikost i nekomprimovanou velikost v centrálním adresáři a v místní hlavičce. Samotná data samotného záznamu také označují jeho velikost. V .NET Core 2,2 a dřívějších verzích se tyto hodnoty nikdy nekontrolovaly konzistence. Počínaje .NET Core 3,0 jsou teď.

Popis změny

V .NET Core 2,2 a starších verzích se aplikace ZipArchiveEntry.Open() zdaří i v případě, že místní hlavička odsouhlasí s centrálním hlavičkou souboru ZIP. Data se dekomprimuje, dokud se nedosáhne konce zkomprimovaného datového proudu, a to i v případě, že jeho délka přesáhne velikost nekomprimovaného souboru, která je uvedená v centrálním adresáři/místní hlavičce.

Počínaje rozhraním .NET Core 3,0 ZipArchiveEntry.Open() Metoda kontroluje, zda se místní hlavička a centrální hlavička dohodnou na komprimovaných a nekomprimovaných velikostech položky. Pokud ne, metoda vyvolá výjimku, InvalidDataException Pokud místní hlavička nebo seznam popisovačů dat archivu, které nesouhlasí s centrálním adresářem souboru ZIP. Při čtení položky se dekomprimovaná data zkrátí na nekomprimovaný soubor, který je uveden v hlavičce.

Tato změna byla provedena, aby se zajistilo, že ZipArchiveEntry správně představuje velikost svých dat a že je čteno pouze množství dat.

Představená verze

3.0

Znovu zabalit libovolný archiv zip, který tyto problémy vykazuje.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Parametr FieldInfo. SetValue vyvolá výjimku pro statická pole pouze pro init.

Počínaje rozhraním .NET Core 3,0 je vyvolána výjimka při pokusu o nastavení hodnoty ve statickém InitOnly poli pomocí volání System.Reflection.FieldInfo.SetValue .

Popis změny

V .NET Framework a verzích .NET Core před 3,0 jste mohli nastavit hodnotu statického pole, které je konstanta po inicializaci (ReadOnly v jazyce C#) voláním System.Reflection.FieldInfo.SetValue . Nicméně nastavení takového pole tímto způsobem vedlo k nepředvídatelnému chování na základě cílové architektury a nastavení optimalizace.

V .NET Core 3,0 a novějších verzích při volání SetValue ve statickém InitOnly poli System.FieldAccessException je vyvolána výjimka.

Tip

InitOnlyPole je jedno, které lze nastavit pouze v okamžiku deklarace nebo v konstruktoru pro třídu, která ji obsahuje. Jinými slovy je konstanta po inicializaci.

Představená verze

3.0

Proveďte inicializaci statických InitOnly polí ve statickém konstruktoru. To platí pro dynamické i jiné než dynamické typy.

Alternativně můžete odebrat FieldAttributes.InitOnly atribut z pole a pak zavolat FieldInfo.SetValue .

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Předání metody GroupCollection do metod rozšíření přijímajících rozhraní IEnumerable <T> vyžaduje nejednoznačnost.

Při volání metody rozšíření, která přebírá IEnumerable<T> na GroupCollection , je nutné odstranit typ pomocí přetypování.

Popis změny

Počínaje rozhraním .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í metody rozšíření, která přijímá IEnumerable<T> . Při volání takové metody rozšíření v GroupCollection instanci, například Enumerable.Count , se zobrazí následující chyba kompilátoru:

CS1061: GroupCollection neobsahuje definici pro ' count ' a nebyla nalezena žádná přístupná metoda rozšíření ' count ', která přijímá první argument typu ' GroupCollection ' (nechybí Direktiva using nebo odkaz na sestavení?)

V předchozích verzích rozhraní .NET nedocházelo k nejednoznačnosti a nedošlo k chybě kompilátoru.

Představená verze

3.0

Důvod změny

Toto byla neúmyslná změna. Protože to pro nějakou dobu vypadalo, neplánujeme ho vrátit zpět. Tato změna by navíc způsobila přerušení.

V případě GroupCollection instancí nejednoznačná volání metod rozšíření, která přijímají IEnumerable<T> přetypování.

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

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Je ovlivněna jakákoli rozšiřující metoda, která přijímá IEnumerable<T> . Příklad:

Kryptografie

Syntaxe příkazu BEGIN TRUSTED CERTIFICATE již není podporována pro kořenové certifikáty v systému Linux

Kořenové certifikáty pro Linux a další systémy podobné platformě UNIX (ale ne macOS) se dají prezentovat ve dvou formách: standardní BEGIN CERTIFICATE Hlavička PEM a hlavička PEM pro OpenSSL specifickou pro BEGIN TRUSTED CERTIFICATE . Druhá syntaxe umožňuje další konfiguraci, která způsobila problémy s kompatibilitou třídy .NET Core System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATEobsah kořenového certifikátu již není načítán modulem řetězení, který začíná v .NET Core 3,0.

Popis změny

Dříve BEGIN CERTIFICATE BEGIN TRUSTED CERTIFICATE byly použity syntaxe i k naplnění seznamu důvěryhodných kořenových certifikátů. Pokud BEGIN TRUSTED CERTIFICATE byla použita syntaxe a v souboru byly zadány další možnosti, X509Chain mohou být hlášeny, že vztah důvěryhodnosti řetězu byl explicitně zakázán ( X509ChainStatusFlags.ExplicitDistrust ). Pokud byl však certifikát také zadán se BEGIN CERTIFICATE syntaxí v dříve načteném souboru, byl povolen vztah důvěryhodnosti řetězu.

Počínaje platformou .NET Core 3,0 se BEGIN TRUSTED CERTIFICATE už obsah nepřečetl. Pokud se certifikát nezadá taky pomocí standardní BEGIN CERTIFICATE syntaxe, X509Chain hlásí, že kořenový adresář není důvěryhodný ( X509ChainStatusFlags.UntrustedRoot ).

Představená verze

3.0

Tato změna nemá vliv na většinu aplikací, ale aplikace, které neobsahují zdrojový kořenový certifikát, můžou při upgradu dojít k neočekávaným chybám v důsledku problémů s oprávněními UntrustedRoot .

Mnoho distribucí systému Linux (nebo distribuce) zápis kořenových certifikátů do dvou umístění: adresář s jedním souborem certifikátu a zřetězení jednoho souboru. V některých distribuce adresář s jedním certifikátem používá BEGIN TRUSTED CERTIFICATE syntaxi, zatímco zřetězení souboru používá standardní BEGIN CERTIFICATE syntaxi. Zajistěte, aby byly všechny vlastní kořenové certifikáty přidány jako BEGIN CERTIFICATE alespoň v jednom z těchto umístění a aby mohla vaše aplikace číst obě umístění.

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řenový adresář specifický pro platformu, který se může lišit od /etc/SSL/. Například v Ubuntu 18,04 je adresář /usr/lib/SSL/certs/ a soubor je /usr/lib/SSL/CERT.pem. /Usr/lib/SSL/certs/ je ale 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

Kategorie

Kryptografie

Ovlivněná rozhraní API

Ve výchozím nastavení je šifrování AES-256 ve formátu EnvelopedCms.

Výchozí algoritmus symetrického šifrování používaný nástrojem se EnvelopedCms změnil z TripleDES na AES-256.

Popis změny

Pokud se v předchozích verzích používá k šifrování dat bez určení algoritmu symetrického šifrování prostřednictvím přetížení konstruktoru, data se šifrují pomocí EnvelopedCms algoritmu TripleDES/3DES/3DEA/DES3-EDE.

Počínaje .NET Core 3.0 (přes verzi 4.6.0 balíčku System.Security.Cryptography.Pkcs NuGet) se výchozí algoritmus změnil na AES-256 pro modernizaci algoritmů a pro zlepšení zabezpečení výchozích možností. Pokud má certifikát příjemce zprávy veřejný klíč (Diffie-Hellman EC), operace šifrování může selhat kvůli omezením CryptographicException základní platformy.

V následujícím ukázkovém kódu jsou data zašifrovaná 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();

Zavedená verze

3.0

Pokud je změna negativně ovlivněná, můžete obnovit šifrování TripleDES explicitním zadáním identifikátoru šifrovacího algoritmu v konstruktoru, který obsahuje parametr typu EnvelopedCms 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();

Kategorie

Kryptografie

Ovlivněná rozhraní API

Minimální velikost pro generování klíče RSAOpenSsl se zvýšila.

Minimální velikost pro generování nových klíčů RSA v systému Linux se zvýšila z 384-bitů na 512.

Popis změny

Počínaje rozhraním .NET Core 3,0 se minimální velikost klíčového klíče hlášená LegalKeySizes vlastností na instancích RSA od RSA.Create , RSAOpenSsl a RSACryptoServiceProvider v systému Linux zvýšila z 384 na 512.

V důsledku toho se v .NET Core 2,2 a dřívějších verzích volání metody, jako je například RSA.Create(384) úspěch. V rozhraní .NET Core 3,0 a novějších verzích vyvolá volání metody RSA.Create(384) výjimku oznamující, že velikost je příliš malá.

Tato změna byla provedena, protože OpenSSL, která provádí kryptografické operace v systému Linux, vyvolala minimální verzi 1.0.2 a 1.1.0. .NET Core 3,0 preferuje OpenSSL 1.1. x až 1.0. x a minimální nahlášená verze se vyvolala, aby odrážela toto nové omezení vyšší závislosti.

Představená verze

3.0

Pokud voláte kterékoli z ovlivněných rozhraní API, ujistěte se, že velikost vygenerovaných klíčů není menší než minimum poskytovatele.

Poznámka

384 bit RSA se už považuje za nezabezpečený (jako je to 512 bitů RSA). Moderní doporučení, jako je NIST Special publikace 800-57 část 1 revize 4, navrhují 2048-bit jako minimální velikost pro nově vygenerované klíče.

Kategorie

Kryptografie

Ovlivněná rozhraní API

.NET Core 3,0 upřednostňuje OpenSSL 1.1. x až OpenSSL 1.0. x

Rozhraní .NET Core pro Linux, které funguje v různých distribucích systému Linux, může podporovat OpenSSL 1.0. x i OpenSSL 1.1. x. .NET Core 2,1 a .NET Core 2,2 hledejte nejprve 1,0. x a potom se vraťte na verzi 1.1. x; .NET Core 3,0 nejprve vyhledá 1.1. x. Tato změna byla provedena za účelem přidání podpory pro nové kryptografické standardy.

Tato změna může mít vliv na knihovny nebo aplikace, které podporují interoperabilitu platforem s typy spolupráce OpenSSL specifickými pro .NET Core.

Popis změny

V .NET Core 2,2 a starších verzích modul runtime upřednostňuje načítání OpenSSL 1.0. x přes 1.1. x. To znamená, že IntPtr SafeHandle typy a pro interoperabilitu s OpenSSL se používají s libcrypto. so. 1.0.0/libcrypto. so. 1,0/libcrypto. so. 10 Podle preference.

Počínaje rozhraním .NET Core 3,0, modul runtime upřednostňuje načtení OpenSSL 1.1. x nad OpenSSL 1.0. x, takže IntPtr typy a SafeHandle pro spolupráci s OpenSSL se používají s libcrypto. proto. 1.1/libcrypto. so. 11/libcrypto. so. 1.1.0/libcrypto. tak. 1.1.1 podle preference. V důsledku toho můžou knihovny a aplikace, které spolupracují s OpenSSL, mít při upgradu z .NET Core 2,1 nebo .NET Core 2,2 nekompatibilní ukazatele s hodnotami vystavenými .NET Core.

Představená verze

3.0

Knihovny a aplikace, které provádějí přímé operace s OpenSSL, musí být opatrní, aby používaly stejnou verzi OpenSSL jako modul runtime .NET Core.

Všechny knihovny nebo aplikace, které používají IntPtr nebo SafeHandle hodnoty z kryptografických typů .NET Core přímo s OpenSSL, by měly porovnat verzi knihovny, kterou používá, s novou SafeEvpPKeyHandle.OpenSslVersion vlastností, aby bylo zajištěno, že jsou ukazatele kompatibilní.

Kategorie

Kryptografie

Ovlivněná rozhraní API

CryptoStream. Dispose transformuje konečný blok jenom při psaní.

CryptoStream.DisposeMetoda, která se používá k dokončení CryptoStream operací, se již nepokouší transformovat konečný blok při čtení.

Popis změny

V předchozích verzích rozhraní .NET, pokud uživatel provedl nekompletní čtení při použití CryptoStream v Read režimu, Dispose může metoda vyvolat výjimku (například při použití AES s odsazením). Výjimka byla vyvolána, protože došlo k pokusu o transformaci posledního bloku, ale data byla neúplná.

V rozhraní .NET Core 3,0 a novějších verzích se Dispose již nepokouší transformovat konečný blok při čtení, což umožňuje neúplné čtení.

Důvod změny

Tato změna umožňuje neúplné čtení z kryptografického streamu, když se síťová operace zruší, aniž by bylo nutné zachytit výjimku.

Představená verze

3,0

Tato změna by neměla mít vliv na většinu aplikací.

Pokud vaše aplikace dříve zachytil výjimku v případě neúplného čtení, můžete tento catch blok odstranit. Pokud vaše aplikace použila transformaci finálního bloku ve scénářích vytváření algoritmu hash, možná budete muset zajistit, aby byl celý datový proud čten před jeho vyřazením.

Kategorie

Kryptografie

Ovlivněná rozhraní API

Entity Framework Core

Entity Framework Core rozbíjení změn

Globalizace

Národní prostředí jazyka C se mapuje na neutrální národní prostředí.

.NET Core 2,2 a starší verze závisí na výchozím chování 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á distribuce systému Linux nastavila národní prostředí "C" jako výchozí národní prostředí, došlo k neočekávanému chování uživatelů.

Popis změny

Počínaje rozhraním .NET Core 3,0 se mapování národního prostředí "C" změnilo na použití neutrálního národního prostředí namísto en_US_POSIX. Národní prostředí "C" na invariantní mapování je také použito pro systém Windows pro zajištění konzistence.

Mapování "C" na en_US_POSIX jazykové verze způsobilo nejasnost zákazníka, protože en_US_POSIX nepodporuje řazení a vyhledávání operací s řetězci v případě nerozlišování velkých a malých písmen. Vzhledem k tomu, že národní prostředí "C" se používá jako výchozí národní prostředí v některých distribuceích Linux, zákazníci narazili na toto neočekávané chování na tyto operační systémy.

Představená verze

3.0

Nic nespecifické pro víc, než je povědomí o této změně. Tato změna ovlivní pouze aplikace, které používají mapování národního prostředí "C".

Kategorie

Globalizace

Ovlivněná rozhraní API

Tato změna ovlivní všechna rozhraní API pro kolaci a kulturu.

MSBuild

Název souboru manifestu prostředku – změna

Počínaje platformou .NET Core 3,0 ve výchozím případě nástroj MSBuild generuje pro soubory prostředků jiný název souboru manifestu.

Představená verze

3,0

Popis změny

Před rozhraním .NET Core 3,0, pokud LogicalName ManifestResourceName nebyla zadána žádná, nebo DependentUpon metadata pro EmbeddedResource položku v souboru projektu, nástroj MSBuild vygeneroval ve vzoru název souboru manifestu <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources . Pokud RootNamespace není v souboru projektu definován, je výchozím názvem 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 platformou .NET Core 3,0 platí, že pokud se soubor prostředků nachází společně 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 pro vygenerování názvu souboru manifestu ve vzoru <Namespace>.<ClassName>.resources . Obor názvů a název třídy jsou extrahovány z prvního typu v společně umístěném zdrojovém souboru. Například vygenerovaný název manifestu pro soubor prostředků s názvem Form1. resx , který je společně umístěn pomocí zdrojového souboru s názvem Form1.cs , je MyNamespace. Form1. Resources. Klíčovým poznámku 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 metadata, ManifestResourceName nebo DependentUpon zadaná pro EmbeddedResource položku v souboru projektu, pak tato změna nemá vliv na daný soubor prostředků.

Tato Průlomová změna byla představena s 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 pro určení způsobu pojmenování vygenerovaného souboru . Resources . Pokud EmbeddedResourceUseDependentUponConvention je nastaven na true , což je výchozí, MSBuild hledá umístěný zdrojový soubor a z něj extrahuje obor názvů a název třídy. Pokud nastavíte EmbeddedResourceUseDependentUponConvention na 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ů není nutná žádná akce v rámci vývojáře a vaše aplikace by měla fungovat i nadále. Pokud však tato změna poškodí vaši aplikaci, můžete:

  • Změňte kód tak, aby očekával nový název manifestu.

  • Odsouhlasit nové zásady vytváření názvů nastavením EmbeddedResourceUseDependentUponConvention na false v souboru projektu

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

Kategorie

MSBuild

Ovlivněná rozhraní API

–

Sítě

Výchozí hodnota HttpRequestMessage.Version změněna na 1.1

Výchozí hodnota vlastnosti System.Net.Http.HttpRequestMessage.Version se změnila z 2.0 na 1.1.

Zavedená verze

3.0

Popis změny

V rozhraní .NET Core 1.0 až 2.0 je výchozí hodnota vlastnosti System.Net.Http.HttpRequestMessage.Version 1.1. Počínaje rozhraním .NET Core 2.1 byl změněn na 2.1.

Počínaje rozhraním .NET Core 3.0 je System.Net.Http.HttpRequestMessage.Version výchozí číslo verze vrácené vlastností opět 1.1.

Aktualizujte kód, pokud System.Net.Http.HttpRequestMessage.Version závisí na vlastnost vrácení výchozí hodnotu 2.0.

Kategorie

Sítě

Ovlivněná rozhraní API

Visual Basic

Microsoft. VisualBasic. konstanty. vbNewLine je zastaralá.

Microsoft.VisualBasic.Constants.vbNewLineKonstanta je označena jako [ zastaralá ] od .NET Core 3,0.

Představená verze

3.0

Popis změny

Počínaje rozhraním .NET Core 3,0 byl zastaralý atribut použit na Microsoft.VisualBasic.Constants.vbNewLine konstantu. Použití konstanty generuje upozornění kompilátoru. V .NET Framework a předchozích verzích rozhraní .NET Core nebyla označena jako zastaralá.

Tato změna byla provedena za účelem podpory Visual Basic jako jazyka pro vývoj pro více platforem. vbNewLineKonstanta je ekvivalentem \r\n , sekvence znaků nového řádku ve Windows. V systémech UNIX je znak nového řádku \n .

Zastaralá zpráva atributu pro vbNewLine zahrnuje následující doporučení:

Pro návrat na začátek řádku a pro posun řádku použijte vbCrLf . Pro nový řádek aktuální platformy použijte Environment.NewLine .

Kategorie

Visual Basic

Ovlivněná rozhraní API