Zásadní změny v .NET Core 3.0

  • Článek

Pokud migrujete na verzi 3.0 .NET Core, ASP.NET Core nebo EF Core, můžou zásadní změny uvedené v tomto článku ovlivnit vaši aplikaci.

ASP.NET Core

Zastaralé antiforgery, CORS, diagnostika, MVC a rozhraní API směrování byly odebrány.

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

Zavedená verze

3,0

Důvod změny

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

Při cílení na .NET Core 2.2 použijte místo toho nová rozhraní API podle pokynů v zastaralých zprávách sestavení.

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

Odebraná pubternální rozhraní API

Kvůli lepší údržbě veřejného rozhraní API ASP.NET Core se většina typů v *.Internal oborech názvů (označovaných jako "pubternal" rozhraní API) stala skutečně interní. Členové v těchto oborech názvů nikdy neměli být podporováni jako veřejně přístupná rozhraní API. Rozhraní API se můžou porušit v menších verzích a často to udělala. Kód, který závisí na těchto rozhraních API, se při aktualizaci na ASP.NET Core 3.0 přeruší.

Další informace najdete v tématu dotnet/aspnetcore#4932 a dotnet/aspnetcore#11312.

Zavedená verze

3,0

Staré chování

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

Nové chování

Ovlivněná rozhraní API jsou označena modifikátorem interního přístupu a kódem mimo toto sestavení se už nedají používat.

Důvod změny

Pokyny pro tato "pubternal" rozhraní API byly, že:

  • Mohlo by se změnit bez předchozího upozornění.
  • Nepodléhá zásadám .NET, aby se zabránilo zásadním změnám.

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

Přestaňte tato "pubternal" rozhraní API používat. Pokud máte dotazy k alternativním rozhraním API, otevřete problém v úložišti dotnet/aspnetcore .

Představte si například následující kód vyrovnávací paměti požadavku HTTP v projektu ASP.NET Core 2.2. V EnableRewind oboru názvů existuje Microsoft.AspNetCore.Http.Internal metoda rozšíření.

HttpContext.Request.EnableRewind();

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

HttpContext.Request.EnableBuffering();

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Všechna rozhraní API v Microsoft.AspNetCore.* názvech a Microsoft.Extensions.* oborech názvů, která mají Internal segment v názvu oboru názvů. Příklad:

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

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

Google začne od 28. ledna 2019 vypínat přihlášení Google+ pro aplikace.

Změna popisu

ASP.NET 4.x a ASP.NET Core k ověřování uživatelů účtu Google ve webových aplikacích používala rozhraní API pro přihlášení Google+. Ovlivněné balíčky NuGet jsou Microsoft.AspNetCore.Authentication.Google pro ASP.NET Core a Microsoft.Owin.Security.Google pro Microsoft.Owin ASP.NET Webové formuláře a MVC.

Náhradní rozhraní API Googlu používají jiný zdroj a formát dat. Omezení rizik a řešení uvedená níže představují strukturální změny. Aplikace by měly ověřit, že samotná data stále splňují jejich požadavky. Například jména, e-mailové adresy, odkazy na profil a profilové fotky můžou poskytovat méně odlišné hodnoty než dříve.

Zavedená verze

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

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

Pro Microsoft.Owin verzi 3.1.0 a novější je zde uvedeno dočasné zmírnění. Aplikace by měly dokončit testování s zmírněním rizik, aby zkontrolovaly změny ve formátu dat. Existují plány vydání Microsoft.Owin verze 4.0.1 s opravou. Aplikace používající jakoukoli předchozí verzi by se měly aktualizovat na verzi 4.0.1.

ASP.NET Core 1.x

Zmírnění rizik v Owinu s webovými formuláři ASP.NET a MVC je možné přizpůsobit na ASP.NET Core 1.x. Opravy balíčků NuGet se neplánují, protože verze 1.x dosáhla stavu konce životnosti .

ASP.NET Core 2.x

Pro Microsoft.AspNetCore.Authentication.Google verzi 2.x nahraďte stávající volání AddGoogleStartup.ConfigureServices následujícím kódem:

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

Opravy z února 2.1 a 2.2 obsahovaly předchozí rekonfiguraci jako nové výchozí. Pro ASP.NET Core 2.0 se neplánuje žádná oprava, protože dosáhla konce životnosti.

ASP.NET Core 3.0

Omezení rizik pro ASP.NET Core 2.x se dá použít také pro ASP.NET Core 3.0. V budoucích verzích Microsoft.AspNetCore.Authentication.Google Preview verze 3.0 může být balíček odebrán. Uživatelé budou přesměrováni na Microsoft.AspNetCore.Authentication.OpenIdConnect místo toho. Následující kód ukazuje, jak nahradit AddGoogle znakem AddOpenIdConnect .Startup.ConfigureServices Tuto náhradu je možné použít s ASP.NET Core 2.0 a novějším a podle potřeby ji můžete přizpůsobit pro ASP.NET Core 1.x.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Authentication.Google

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

Zastaralá Authentication vlastnost HttpContext byla odebrána.

Změna popisu

V rámci dotnet/aspnetcore#6504 se odebrala zastaralá Authentication vlastnost HttpContext . Vlastnost Authentication je od verze 2.0 zastaralá. Průvodce migrací byl publikován pro migraci kódu pomocí této zastaralé vlastnosti do nových náhradních rozhraní API. Zbývající nepoužívané třídy / rozhraní API související se starým zásobníkem ověřování ASP.NET Core 1.x byly odebrány v potvrzení dotnet/aspnetcore@d7a7c65.

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

Zavedená verze

3,0

Důvod změny

ASP.NET rozhraní API Core 1.0 byly nahrazeny rozšiřujícími metodami v Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Prohlédnou si průvodce migrací.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ověřování: Nahrazené typy Newtonsoft.Json

V ASP.NET Core 3.0 Newtonsoft.Json byly typy používané v rozhraních API pro ověřování nahrazeny System.Text.Json typy. S výjimkou následujících případů zůstává základní použití ověřovacích balíčků nedotčeno:

  • Třídy odvozené od zprostředkovatelů OAuth, například 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 nahradit JObject.Parse přepsání JsonDocument.ParseCreateTicketAsync , jak je znázorněno zde. JsonDocument implementuje IDisposable.

Následující seznam popisuje známé změny:

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ověřování: Změna podpisu OAuthHandler ExchangeCodeAsync

V ASP.NET Core 3.0 se podpis změnil OAuthHandler.ExchangeCodeAsync z:

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

Do:

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

Zavedená verze

3,0

Staré chování

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

Nové chování

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

Důvod změny

Tato změna umožňuje poskytnutí dalších parametrů jiným způsobem než zásadním způsobem. Není nutné vytvářet nová ExchangeCodeAsync přetížení.

Vytvořte s OAuthCodeExchangeContext příslušnými code hodnotami a redirectUri s odpovídajícími hodnotami. Je AuthenticationProperties nutné zadat instanci. Tuto jednu OAuthCodeExchangeContext instanci je možné předat OAuthHandler.ExchangeCodeAsync místo více argumentů.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorizace: Přetížení AddAuthorization přesunuto do jiného sestavení

AddAuthorization Základní metody použité k pobytu Microsoft.AspNetCore.Authorization byly přejmenovány na AddAuthorizationCore. Staré AddAuthorization metody stále existují, ale jsou v Microsoft.AspNetCore.Authorization.Policy sestavení. Aplikace používající obě metody by neměly mít žádný vliv. Všimněte si, že Microsoft.AspNetCore.Authorization.Policy nyní se dodává ve sdíleném rozhraní místo samostatného balíčku, jak je popsáno ve sdíleném rozhraní: Sestavení odebraná z Microsoft.AspNetCore.App.

Zavedená 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 starých metod.

Důvod změny

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

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

Autorizace: IAllowAnonymous odebrané z AuthorizationFilterContext.Filters

Od ASP.NET Core 3.0 MVC nepřidá allowAnonymousFilters pro atributy [AllowAnonymous], které byly zjištěny u kontrolerů a metod akcí. Tato změna se řeší místně pro deriváty z AuthorizeAttribute, ale jedná se o zásadní změnu pro IAsyncAuthorizationFilter a IAuthorizationFilter implementace. Takové implementace zabalené do atributu [TypeFilter] jsou oblíbeným a podporovaným způsobem, jak dosáhnout autorizace založené na atributech, pokud jsou vyžadovány konfigurace i injektáž závislostí.

Zavedená verze

3,0

Staré chování

IAllowAnonymous v kolekci AuthorizationFilterContext.Filters . Testování přítomnosti rozhraní bylo platným přístupem k přepsání nebo zakázání filtru u jednotlivých metod kontroleru.

Nové chování

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

Důvod změny

V ASP.NET Core 3.0 byla zavedena nová strategie směrování koncových bodů.

Vyhledejte metadata IAllowAnonymouskoncového bodu . Příklad:

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

Příkladem této techniky je tato metoda HasAllowAnonymous.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Autorizace: Implementace IAuthorizationPolicyProvider vyžadují novou metodu.

V ASP.NET Core 3.0 byla do souboru přidána IAuthorizationPolicyProvidernová GetFallbackPolicyAsync metoda . Tuto záložní zásadu používá middleware autorizace, pokud není zadána žádná zásada.

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

Zavedená verze

3,0

Staré chování

IAuthorizationPolicyProvider Implementace nepožadovala metoduGetFallbackPolicyAsync.

Nové chování

IAuthorizationPolicyProvider Implementace vyžadují metoduGetFallbackPolicyAsync.

Důvod změny

Byla nutná nová metoda, AuthorizationMiddleware která se má použít v případě, že není zadána žádná zásada.

Přidejte metodu GetFallbackPolicyAsync do implementací .IAuthorizationPolicyProvider

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

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

Verze ASP.NET Core 3.0 odebrala zastaralá rozhraní API MemoryCacheOptions.

Změna popisu

Tato změna je následná úprava aspnet/Ukládání do mezipaměti#221. Diskuzi najdete v tématu dotnet/extensions#1062.

Zavedená verze

3,0

Staré chování

MemoryCacheOptions.CompactOnMemoryPressure nemovitost byla k dispozici.

Nové chování

Vlastnost MemoryCacheOptions.CompactOnMemoryPressure byla odebrána.

Důvod změny

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

Pokud chcete komprimovat mezipaměť, přepošlujte MemoryCache ji a v případě potřeby zavolejte Compact .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

MemoryCacheOptions.CompactOnMemoryPressure

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

Balíček Microsoft.Extensions.Caching.SqlServer bude místo balíčku používat nový Microsoft.Data.SqlClient balíček System.Data.SqlClient . Tato změna může způsobit mírné změny způsobující chybu chování. Další informace naleznete v tématu Představujeme nový Microsoft.Data.SqlClient.

Zavedená verze

3,0

Staré chování

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

Nové chování

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

Důvod změny

Microsoft.Data.SqlClient je nový balíček, který je sestaven z System.Data.SqlClient. Tady budou odteď fungovat všechny nové funkce.

Zákazníci by se neměli starat o tuto změnu způsobující chybu, pokud nepoužívali typy vrácené balíčkem Microsoft.Extensions.Caching.SqlServer a přetypovali je na System.Data.SqlClient typy. Pokud například někdo přetypoval DbConnection na starý typ Sql Připojení ion, bude muset přetypování změnit na nový Microsoft.Data.SqlClient.SqlConnection typ.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

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

V ASP.NET Core 3.0 byly změněny typy ResponseCaching "pubternal" na internal.

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

Změna popisu

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

Zavedená 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

Rozsah internal lépe odráží nepodporované zásady.

Typy kopírování používané vaší aplikací nebo knihovnou

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Ochrana dat: DataProtection.Blobs používá nová rozhraní API služby Azure Storage.

Azure.Extensions.AspNetCore.DataProtection.Blobs závisí na knihovnách Azure Storage. Tyto knihovny přejmenovaly svá sestavení, balíčky a obory názvů. Počínaje ASP.NET Core 3.0 Azure.Extensions.AspNetCore.DataProtection.Blobs používá nová Azure.Storage.rozhraní API a balíčky s předponou.

V případě dotazů k rozhraním API služby Azure Storage použijte https://github.com/Azure/azure-storage-net. Diskuzi o tomto problému najdete v tématu dotnet/aspnetcore#19570.

Zavedená 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í API služby Azure Storage s ASP.NET Core 3.0, přidejte do balíčku WindowsAzure.Storage nebo Microsoft.Azure.Storage přímou závislost. Tento balíček lze nainstalovat společně s novými Azure.Storage rozhraními API.

V mnoha případech upgrade zahrnuje pouze změnu using příkazů tak, aby používaly nové obory názvů:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Hostování: AspNetCoreModule V1 odebraný z hostitelské sady Windows

Počínaje ASP.NET Core 3.0 nebude sada Windows Hosting Bundle obsahovat AspNetCoreModule (ANCM) V1.

ANCM V2 je zpětně kompatibilní s funkcí ANCM OutOfProcess a doporučuje se pro použití s aplikacemi ASP.NET Core 3.0.

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

Zavedená verze

3,0

Staré chování

ANCM V1 je součástí sady windows Hosting Bundle.

Nové chování

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

Důvod změny

ANCM V2 je zpětně kompatibilní s funkcí ANCM OutOfProcess a doporučuje se pro použití s aplikacemi ASP.NET Core 3.0.

Použijte ANCM V2 s aplikacemi ASP.NET Core 3.0.

Pokud se vyžaduje ANCM V1, můžete ho nainstalovat pomocí sady windows hostingu ASP.NET Core 2.1 nebo 2.2.

Tato změna přeruší ASP.NET aplikace Core 3.0, které:

  • Explicitně se přihlásili k použití ANCM V1 s <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Vlastní soubor web.config s <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />příponou .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Hostování: Obecný hostitel omezuje injektáž spouštěcího konstruktoru.

Jedinými typy, které obecný hostitel podporuje pro Startup injektáž konstruktoru třídy, jsou IHostEnvironment, IWebHostEnvironmenta IConfiguration. Aplikace, které používají WebHost , nemají vliv.

Změna popisu

Před ASP.NET Core 3.0 lze injektáž konstruktoru použít pro libovolné typy v konstruktoru Startup třídy. V ASP.NET Core 3.0 se webový zásobník přeformuloval do obecné knihovny hostitelů. Změnu uvidíte v souboru Program.cs šablon:

ASP.NET Core 2.x:

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 injektáže závislostí (DI). WebHost používá dva kontejnery: jeden pro hostitele a druhý pro aplikaci. V důsledku toho Startup konstruktor už nepodporuje injektáž vlastních služeb. Pouze IHostEnvironment, IWebHostEnvironmenta IConfiguration mohou být vloženy. Tato změna zabraňuje problémům s DI, jako je duplicitní vytvoření služby singleton.

Zavedená verze

3,0

Důvod změny

Tato změna je důsledkem opětovného vytvoření webového zásobníku na obecnou knihovnu hostitelů.

Vložte služby do Startup.Configure podpisu metody. Příklad:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Hostování: Přesměrování HTTPS povolené pro aplikace mimo proces služby IIS

Verze 13.0.19218.0 modulu ASP.NET Core (ANCM) pro hostování prostřednictvím služby IIS mimo proces umožňuje existující funkci přesměrování HTTPS pro aplikace ASP.NET Core 3.0 a 2.2.

Diskuzi najdete v tématu dotnet/AspNetCore#15243.

Zavedená verze

3,0

Staré chování

Šablona projektu ASP.NET Core 2.1 poprvé zavedla podporu metod middlewaru HTTPS, jako jsou UseHttpsRedirection a UseHsts. Povolení přesměrování HTTPS vyžadovalo přidání konfigurace, protože aplikace ve vývoji nepoužívají výchozí port 443. Http Strict Transport Security (HSTS) je aktivní pouze v případě, že požadavek již používá HTTPS. Localhost se ve výchozím nastavení přeskočí.

Nové chování

V ASP.NET Core 3.0 byl vylepšen scénář HTTPS služby IIS. Díky vylepšení může aplikace zjistit porty HTTPS serveru a UseHttpsRedirection ve výchozím nastavení fungovat. Komponenta v procesu dosáhla zjišťování portů pomocí IServerAddresses funkce, která má vliv pouze na ASP.NET aplikace Core 3.0, protože knihovna v procesu má verzi s architekturou. Komponenta mimo proces se změnila tak, aby automaticky přidala proměnnou ASPNETCORE_HTTPS_PORT prostředí. Tato změna ovlivnila aplikace ASP.NET Core 2.2 i 3.0, protože komponenta mimo proces se sdílí globálně. aplikace ASP.NET Core 2.1 nejsou ovlivněné, protože ve výchozím nastavení používají předchozí verzi ANCM.

Předchozí chování bylo změněno v ASP.NET Core 3.0.1 a 3.1.0 Preview 3, aby se změny chování v ASP.NET Core 2.x změnily. Tyto změny mají vliv jenom na zastaralé aplikace služby IIS.

Jak je popsáno výše, instalace ASP.NET Core 3.0.0 měla vedlejší vliv také na aktivaci middlewaru UseHttpsRedirection v aplikacích ASP.NET Core 2.x. V systému ASP.NET Core 3.0.1 a 3.1.0 Preview 3 byla provedena změna ancm, takže jejich instalace už nemá tento vliv na aplikace ASP.NET Core 2.x. Proměnná ASPNETCORE_HTTPS_PORT prostředí vyplněná v ASP.NET Core 3.0.0 se změnila na ASPNETCORE_ANCM_HTTPS_PORT v ASP.NET Core 3.0.1 a 3.1.0 Preview 3. UseHttpsRedirection v těchto verzích byla také aktualizována, aby porozuměla novým i starým proměnným. ASP.NET Core 2.x se neaktualizuje. V důsledku toho se ve výchozím nastavení vrátí k předchozímu chování zakázání.

Důvod změny

Vylepšené funkce ASP.NET Core 3.0

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

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

  • V souboru web.config nastavte ASPNETCORE_HTTPS_PORT proměnnou prostředí na prázdný řetězec. K této změně může dojít přímo na serveru bez opětovného nasazení aplikace. Příklad:

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

UseHttpsRedirection může být stále:

  • Aktivované ručně v ASP.NET Core 2.x nastavením ASPNETCORE_HTTPS_PORT proměnné prostředí na odpovídající čí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 prázdnou řetězcovou hodnotou. Tato hodnota je nastavena stejným způsobem jako předchozí ASPNETCORE_HTTPS_PORT příklad.

Počítače se spuštěnými aplikacemi ASP.NET Core 3.0.0 by měly nainstalovat modul runtime ASP.NET Core 3.0.1 před instalací ASP.NET Core 3.1.0 Preview 3 ANCM. Tím zajistíte, že UseHttpsRedirection bude fungovat podle očekávání pro aplikace ASP.NET Core 3.0.

Ve službě Aplikace Azure service se ANCM nasadí podle samostatného plánu od modulu runtime z důvodu své globální povahy. Po nasazení ASP.NET Core 3.0.1 a 3.1.0 byla služba ANCM nasazena do Azure s těmito změnami.

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 pro nahrazení existujících IHostingEnvironment a IApplicationLifetime typů.

Zavedená verze

3,0

Staré chování

Byly dva různé IHostingEnvironment a IApplicationLifetime různé typy od Microsoft.Extensions.Hosting a 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 byl zaveden v ASP.NET Core 2.1, některé typy jako IHostingEnvironment a IApplicationLifetime byly zkopírovány z Microsoft.AspNetCore.Hosting. Některé změny ASP.NET Core 3.0 způsobují, že aplikace budou obsahovat jak obory Microsoft.Extensions.HostingMicrosoft.AspNetCore.Hosting názvů, tak i obory názvů. Jakékoli použití těchto duplicitních typů způsobí chybu kompilátoru "nejednoznačný odkaz" při odkazování na oba obory názvů.

Nahraďte všechna použití starých typů nově zavedenými typy následujícím způsobem:

Zastaralé typy (upozornění):

Nové typy:

Nové IHostEnvironmentIsDevelopment 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 odebraný ze závislostí WebHostBuilder

V rámci vytváření ASP.NET Core za hraní ObjectPoolProvider se odebrala z hlavní sady závislostí. Konkrétní komponenty, které se teď spoléhají na ObjectPoolProvider to, že je teď přidávají samy.

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

Zavedená verze

3,0

Staré chování

WebHostBuilder ve ObjectPoolProvider výchozím nastavení v kontejneru DI.

Nové chování

WebHostBuilder v kontejneru DI už není ve výchozím nastavení k dispozici ObjectPoolProvider .

Důvod změny

Tato změna byla provedena, aby ASP.NET Core více platit za hraní.

Pokud vaše komponenta vyžaduje ObjectPoolProvider, musí být přidána do závislostí prostřednictvím nástroje IServiceCollection.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

HTTP: Odebrání rozšiřitelnosti DefaultHttpContext

V rámci vylepšení výkonu ASP.NET Core 3.0 se rozšiřitelnost DefaultHttpContext odebrala. Třída je nyní sealed. Další informace najdete v tématu dotnet/aspnetcore#6504.

Pokud testy jednotek používají Mock<DefaultHttpContext>, použijte Mock<HttpContext> nebo new DefaultHttpContext() místo toho.

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

Zavedená verze

3,0

Staré chování

Třídy mohou být odvozeny z DefaultHttpContext.

Nové chování

Třídy nemohou odvozovat .DefaultHttpContext

Důvod změny

Rozšiřitelnost byla původně poskytována tak, aby umožňovala sdružování HttpContext, ale zavedla zbytečnou složitost a bránila jiným optimalizacím.

Pokud používáte Mock<DefaultHttpContext> testy jednotek, začněte místo toho používat Mock<HttpContext> .

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: Konstanty HeaderNames se změnily na statickou jen pro čtení.

Počínaje verzí ASP.NET Core 3.0 Preview 5 se pole změnila Microsoft.Net.Http.Headers.HeaderNames z const na static readonly.

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

Zavedená verze

3,0

Staré chování

Tato pole bývala const.

Nové chování

Tato pole jsou nyní static readonly.

Důvod změny

Změna:

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

Rekompilujte proti verzi 3.0. Zdrojový kód používající tato pole již nemůže provést následujícími způsoby:

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

Pokud chcete změnu způsobující chybu obejít, přepněte na konstanty názvu záhlaví definované vlastním jménem nebo řetězcové literály.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Změny infrastruktury těla odpovědi

Infrastruktura, která zálohuje tělo odpovědi HTTP, se změnila. Pokud používáte HttpResponse přímo, neměli byste provádět žádné změny kódu. Přečtěte si další informace, pokud zabalíte nebo nahradíte HttpResponse.Body nebo přistupujete.HttpContext.Features

Zavedená verze

3,0

Staré chování

K textu odpovědi HTTP jsou přidružená tři rozhraní API:

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

Nové chování

Pokud nahradíte HttpResponse.Body, nahradí celý IHttpResponseBodyFeature obálkou kolem daného datového proudu pomocí StreamResponseBodyFeature k poskytnutí výchozích implementací pro všechna očekávaná rozhraní API. Nastavení původního datového proudu vrátí tuto změnu zpět.

Důvod změny

Motivací je zkombinovat rozhraní API těla odpovědi do jednoho nového rozhraní funkcí.

Použijte IHttpResponseBodyFeature místo, kde jste dříve používali IHttpResponseFeature.Body, IHttpSendFileFeaturenebo IHttpBufferingFeature.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SameSite je možnost pro soubory cookie, které můžou pomoct zmírnit některé útoky CSRF (Cross-Site Request Forgery). Při počátečním zavedení této možnosti se v různých rozhraních API ASP.NET Core použily nekonzistentní výchozí hodnoty. Nekonzistence vedla k matoucím výsledkům. Od ASP.NET Core 3.0 jsou tato výchozí nastavení lépe zarovnaná. K této funkci se musíte přihlásit na základě jednotlivých komponent.

Zavedená verze

3,0

Staré chování

Podobná rozhraní API core ASP.NET používala různé výchozí SameSiteMode hodnoty. Příklad nekonzistence je vidět v HttpResponse.Cookies.Append(String, String) a HttpResponse.Cookies.Append(String, String, CookieOptions), který je ve výchozím nastavení SameSiteMode.None a SameSiteMode.Laxv uvedeném pořadí.

Nové chování

Všechna ovlivněná rozhraní API mají výchozí hodnotu SameSiteMode.None.

Důvod změny

Výchozí hodnota byla změněna tak, aby se SameSite funkce opt-in.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HTTP: Synchronní vstupně-výstupní operace zakázány na všech serverech

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

Změna popisu

AllowSynchronousIO je možnost na každém serveru, který povoluje nebo zakazuje synchronní vstupně-výstupní rozhraní API, jako HttpRequest.Body.Readje , HttpResponse.Body.Writea Stream.Flush. Tato rozhraní API jsou již dlouho zdrojem hladovění vláken a aplikace přestane reagovat. Počínaje ASP.NET Core 3.0 Preview 3 jsou tyto synchronní operace ve výchozím nastavení zakázané.

Ovlivněné servery:

  • Kestrel
  • HttpSys
  • In-process služby IIS
  • TestServer

Očekávejte podobné chyby:

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

Každý server má AllowSynchronousIO možnost, která řídí toto chování a výchozí pro všechny z nich je nyní false.

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

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

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

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

Zavedená verze

3,0

Staré chování

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

Nové chování

Tato synchronní rozhraní API jsou ve výchozím nastavení zakázaná:

Očekávejte podobné chyby:

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

Důvod změny

Tato synchronní rozhraní API jsou již dlouho zdrojem hladovění vláken a aplikace přestane reagovat. Počínaje ASP.NET Core 3.0 Preview 3 jsou synchronní operace ve výchozím nastavení zakázané.

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

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

Počínaje ASP.NET Core 3.0 už přetížení metody IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) již neexistuje.

Zavedená verze

3,0

Důvod změny

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

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

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identita: Změna výchozí verze uživatelského rozhraní bootstrap

Počínaje ASP.NET Core 3.0 se ve výchozím nastavení uživatelského rozhraní identity používá verze 4 bootstrap.

Zavedená verze

3,0

Staré chování

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

Nové chování

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

Důvod změny

Bootstrap 4 byl vydán během časového rámce ASP.NET Core 3.0.

Tato změna se vás týká, pokud používáte výchozí uživatelské rozhraní identity a přidali jste ho Startup.ConfigureServices , jak je znázorněno v následujícím příkladu:

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

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

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.

Zavedená verze

3,0

Staré chování

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

Nové chování

Ve výchozím nastavení SignInAsync vyvolá výjimku pro objekty zabezpečení / identity, ve kterých IsAuthenticated je false. K potlačení tohoto chování existuje nový příznak, ale výchozí chování se změnilo.

Důvod změny

Staré chování bylo problematické, protože ve výchozím nastavení byly tyto objekty objekty odmítnuty [Authorize] / RequireAuthenticatedUser().

Ve verzi ASP.NET Core 3.0 Preview 6 je RequireAuthenticatedSignIntrue ve výchozím nastavení příznakAuthenticationOptions. Nastavte tento příznak tak, aby false se obnovilo staré chování.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Identita: Konstruktor SignInManager přijímá nový parametr.

Počínaje ASP.NET Core 3.0 se do konstruktoru SignInManager přidal nový IUserConfirmation<TUser> parametr. Další informace najdete v tématu dotnet/aspnetcore#8356.

Zavedená verze

3,0

Důvod změny

Motivací ke změně bylo přidání podpory pro nové toky e-mailu a potvrzení ve službě Identity.

Pokud ručně vytváříte SignInManager, poskytněte implementaci IUserConfirmation nebo si ji vezměte z injektáže závislostí, která se má poskytnout.

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 zavedl funkci statických webových prostředků a uživatelské rozhraní identit ji přijalo.

Změna popisu

V důsledku toho, že uživatelské rozhraní identit přijímá funkci statických webových prostředků:

  • Výběr architektury se provádí pomocí IdentityUIFrameworkVersion vlastnosti v souboru projektu.
  • Bootstrap 4 je výchozí architektura uživatelského rozhraní pro uživatelské rozhraní identity. Bootstrap 3 dosáhl konce životnosti a měli byste zvážit migraci na podporovanou verzi.

Zavedená verze

3,0

Staré chování

Výchozí rozhraní uživatelského rozhraní pro uživatelské rozhraní identity bylo Bootstrap 3. Rozhraní uživatelského rozhraní lze nakonfigurovat pomocí parametru AddDefaultUI volání metody .Startup.ConfigureServices

Nové chování

Výchozí architektura uživatelského rozhraní pro uživatelské rozhraní identity je Bootstrap 4. Architektura uživatelského rozhraní musí být nakonfigurovaná v souboru projektu místo volání AddDefaultUI metody.

Důvod změny

Přijetí funkce statických webových prostředků vyžadovalo, aby se konfigurace architektury uživatelského rozhraní přesunula do nástroje MSBuild. Rozhodnutí o tom, která architektura se má vložit, je rozhodnutí o době sestavení, nikoli rozhodnutí o modulu runtime.

Zkontrolujte uživatelské rozhraní webu a ujistěte se, že jsou nové komponenty Bootstrap 4 kompatibilní. V případě potřeby použijte IdentityUIFrameworkVersion vlastnost MSBuild k návratu na Bootstrap 3. Přidejte vlastnost do elementu <PropertyGroup> v souboru projektu:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: odebrané adaptéry Připojení ion

V rámci přesunu k přesunu "pubternálních" rozhraní API do public, koncept objektu IConnectionAdapter byl odebrán z Kestrel. Připojení adaptéry se nahrazují middlewarem připojení (podobně jako middleware HTTP v kanálu ASP.NET Core, ale pro připojení nižší úrovně). Protokoly HTTPS a protokolování připojení se přesunuly z adaptérů připojení do middlewaru připojení. Tyto metody rozšíření by měly bez problémů fungovat, ale podrobnosti implementace se změnily.

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

Zavedená 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ější architektury rozšiřitelnosti.

Převeďte všechny implementace IConnectionAdapter pro použití nového vzoru middlewaru, jak je znázorněno zde.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

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

Sestavení Microsoft.AspNetCore.Server.Kestrel.Https bylo odebráno.

Zavedená verze

3,0

Důvod změny

V ASP.NET Core 2.1 se obsah Microsoft.AspNetCore.Server.Kestrel.Https přesunul do Microsoft.AspNetCore.Server.Kestrel.Core. Tato změna se prováděla jiným způsobem než zásadním způsobem pomocí [TypeForwardedTo] atributů.

  • Knihovny odkazující Microsoft.AspNetCore.Server.Kestrel.Https na verzi 2.0 by měly aktualizovat všechny závislosti jádra ASP.NET na verzi 2.1 nebo novější. Jinak se můžou při načtení do aplikace ASP.NET Core 3.0 přerušit.
  • 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

Nic

Kestrel: Žádost o hlavičky přívěsu přesunutá do nové kolekce

V předchozích verzích přidal Kestrel do kolekce hlaviček požadavků hlavičky blokovaných přívěsů HTTP/1.1, když se text požadavku načte na konec. Toto chování způsobilo obavy ohledně nejednoznačnosti mezi hlavičkami a přívěsy. Rozhodli jsme se přesunout přívěsy do nové kolekce.

Přívěsy požadavků HTTP/2 nebyly v ASP.NET Core 2.2 k dispozici, ale nyní jsou k dispozici také v této nové kolekci v ASP.NET Core 3.0.

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

Po přečtení celého textu požadavku jsou k dispozici přívěsy HTTP/1.1.

Po přijetí z klienta jsou k dispozici přívěsy HTTP/2. Klient nebude posílat přívěsy, dokud server alespoň neusměrní celý text požadavku do vyrovnávací paměti. Možná budete muset přečíst text požadavku, aby se uvolnilo místo vyrovnávací paměti. Přívěsy jsou vždy k dispozici, pokud přečtete text požadavku na konec. Přívěsy označují konec těla.

Zavedená verze

3,0

Staré chování

Do kolekce by se přidaly HttpRequest.Headers hlavičky žádosti o přívěs.

Nové chování

Hlavičky žádosti o přívěs nejsou v kolekci HttpRequest.Headers k dispozici. Pro přístup k nim použijte následující metody HttpRequest rozšíření:

  • GetDeclaredTrailers() - Získá žádost "Přívěs" hlavička, která uvádí, které přívěsy mají očekávat po těle.
  • SupportsTrailers() - Označuje, zda žádost podporuje příjem hlaviček přívěsu.
  • CheckTrailersAvailable() - Určuje, zda žádost podporuje přívěsy a zda jsou k dispozici pro čtení.
  • GetTrailer(string trailerName) - Získá požadovanou koncovou hlavičku z odpovědi.

Důvod změny

Přívěsy jsou klíčovou funkcí ve scénářích, jako je gRPC. Sloučení přívěsů s hlavičkami požadavku bylo matoucí pro uživatele.

Pro přístup k přívěsům použijte metody HttpRequest rozšíření související s přívěsem.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HttpRequest.Headers

Kestrel: Transport abstrakce odebrané a zpřístupněné veřejnosti

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

Zavedená verze

3,0

Staré chování

  • Abstrakce související s přenosy byly k dispozici v knihovně Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
  • Ubytování ListenOptions.NoDelay bylo k dispozici.

Nové chování

  • Rozhraní IConnectionListener bylo zavedeno v Microsoft.AspNetCore.Connections.Abstractions knihovně, aby se z knihovny zpřístupnily ...Transport.Abstractions nejpoužívanější funkce.
  • Nyní NoDelay je k dispozici v možnostech přenosu (LibuvTransportOptions a SocketTransportOptions).
  • SchedulingMode už není k dispozici.

Důvod změny

ASP.NET Core 3.0 se přesunula z rozhraní API "pubternal".

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

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

ResourceManagerWithCultureStringLocalizer třídy a WithCulture interface člen jsou často zdrojem nejasnosti pro uživatele lokalizace, zejména při vytváření vlastní IStringLocalizer implementace. Tyto položky dávají uživateli dojem, že IStringLocalizer instance je "podle jazyka, podle prostředku". Ve skutečnosti by instance měly být pouze "pro jednotlivé prostředky". Hledaný jazyk je určen časem CultureInfo.CurrentUICulture spuštění. Aby se zabránilo nejasnostem, rozhraní API byla označena jako zastaralá ve verzi ASP.NET Core 3.0 Preview 3. Rozhraní API budou v budoucí verzi odebrána.

Kontext najdete v tématu dotnet/aspnetcore#3324. Diskuzi najdete v tématu dotnet/aspnetcore#7756.

Zavedená 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ředstavovala případ použití, který se nedoporučuje. Došlo k nejasnostem ohledně návrhu lokalizace.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Protokolování: Třída DebugLogger vytvořená interně

Před ASP.NET Core 3.0 DebugLoggerbyl publicmodifikátor přístupu . V ASP.NET Core 3.0 se modifikátor přístupu změnil na internal.

Zavedená verze

3,0

Důvod změny

Tato změna se provádí v následujících:

  • Vynucujte konzistenci s jinými implementacemi protokolovacího nástroje, například ConsoleLogger.
  • Zmenšete plochu rozhraní API.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Asynchronní přípona oříznutá z názvů akcí kontroleru

V rámci adresování dotnet/aspnetcore#4849 ASP.NET Core MVC ve výchozím nastavení oříznou příponu Async z názvů akcí. Počínaje ASP.NET Core 3.0 má tato změna vliv na generování směrování i propojení.

Zavedená verze

3,0

Staré chování

Zvažte následující ASP.NET kontroleru Core MVC:

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

Akce je směrovatelná přes Product/ListAsync. Generování propojení vyžaduje zadání přípony Async . Příklad:

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

Nové chování

V ASP.NET Core 3.0 je akce směrovatelná přes Product/List. Kód generování propojení by měl vynechat příponu Async . Příklad:

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

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

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

Důvod změny

Podle konvence jsou asynchronní metody .NET příponou Async. Pokud však metoda definuje akci MVC, je nežádoucí použít příponu Async .

Pokud vaše aplikace závisí na akcích MVC, které zachová příponu Async názvu, zvolte jednu z následujících omezení rizik:

  • [ActionName] K zachování původního názvu použijte atribut.
  • Úplné přejmenování zakažte nastavením na false :Startup.ConfigureServicesMvcOptions.SuppressAsyncSuffixInActionNames
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

MVC: JsonResult přesunuto do Microsoft.AspNetCore.Mvc.Core

JsonResult byla přesunuta do Microsoft.AspNetCore.Mvc.Core sestavení. Tento typ se používá k definování v Souboru Microsoft.AspNetCore.Mvc.Formatters.Json. Byl přidán atribut [TypeForwardedTo] na úrovni sestavení, aby Microsoft.AspNetCore.Mvc.Formatters.Json se tento problém vyřešil pro většinu uživatelů. Aplikace, které používají knihovny třetích stran, můžou narazit na problémy.

Zavedená verze

3.0 Preview 6

Staré chování

Aplikace, která úspěšně sestavuje knihovnu založenou na 2.2

Nové chování

Kompilace aplikace využívající knihovnu založenou na verzi 2.2 selže. Zobrazí se chyba obsahující variantu následujícího textu:

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

Příklad takového problému najdete v tématu dotnet/aspnetcore#7220.

Důvod změny

Změny na úrovni platformy ve složení ASP.NET Core, jak je popsáno v aspnet/Announcements#325.

Knihovny kompilované ve verzi Microsoft.AspNetCore.Mvc.Formatters.Json 2.2 může být potřeba znovu zkompilovat, aby se problém vyřešil pro všechny uživatele. Pokud se to týká, obraťte se na autora knihovny. Požádejte o rekompilace knihovny tak, aby cílila na ASP.NET Core 3.0.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Nástroj předkompilace je zastaralý

V ASP.NET Core 1.1 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation byl zaveden balíček (nástroj pro předkompilace MVC) pro přidání podpory pro kompilaci souborů Razor (soubory .cshtml ). V ASP.NET Core 2.1 byla sada Razor SDK zavedena, aby se rozšířila o funkce nástroje pro předkompilace. Sada Razor SDK přidala podporu pro kompilaci souborů Razor a jejich čas publikování. Sada SDK ověřuje správnost souborů .cshtml v době sestavení a současně vylepšuje dobu spuštění aplikace. Sada Razor SDK je ve výchozím nastavení zapnutá a k jejímu spuštění není potřeba žádné gesto.

V ASP.NET Core 3.0 se odebral nástroj prekompilace MVC ASP.NET Core 1.1.1. Starší verze balíčků budou dál dostávat důležité chyby a opravy zabezpečení v vydání opravy.

Zavedená verze

3,0

Staré chování

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

Nové chování

Sada Razor SDK nativně podporuje tuto funkci. Balíček Microsoft.AspNetCore.Mvc.Razor.ViewCompilation se už neaktualizuje.

Důvod změny

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

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

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

V ASP.NET Core 3.0 byly všechny typy "pubternal" v MVC aktualizovány tak, aby byly public buď v podporovaném oboru názvů, nebo internal podle potřeby.

Změna popisu

V ASP.NET Core se typy pubternal deklarují jako public typy s příponou -, ale nacházejí se v oboru názvů s příponou .Internal-. I když se jedná publico tyto typy, nemají žádné zásady podpory a podléhají zásadním změnám. Náhodné použití těchto typů je bohužel běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti udržovat architekturu.

Zavedená verze

3,0

Staré chování

Některé typy v MVC byly public ale v .Internal oboru názvů. Tyto typy neměly žádné zásady podpory a podléhaly zásadním změnám.

Nové chování

Všechny tyto typy se aktualizují tak, aby byly public v podporovaném oboru názvů nebo byly označeny jako internal.

Důvod změny

Náhodné použití "pubternálních" typů bylo běžné, což vede k zásadním změnám těchto projektů a omezení schopnosti udržovat architekturu.

Pokud používáte typy, které se skutečně public staly a byly přesunuty do nového podporovaného oboru názvů, aktualizujte odkazy tak, aby odpovídaly novým oborům názvů.

Pokud používáte typy, které jsou označené jako internal, budete muset najít alternativu. Dříve "pubternální" typy nebyly nikdy podporovány pro veřejné použití. Pokud jsou v těchto oborech názvů určité typy, které jsou pro vaše aplikace důležité, zapište problém na adrese dotnet/aspnetcore. Je možné vzít v úvahu požadavky na typy public.

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: Odebrané shim kompatibility webového rozhraní API

Počínaje verzí ASP.NET Core 3.0 Microsoft.AspNetCore.Mvc.WebApiCompatShim už balíček není k dispozici.

Změna popisu

Balíček Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) poskytuje částečnou kompatibilitu v ASP.NET Core s webovým rozhraním API 2 ASP.NET 4.x, aby se zjednodušila migrace stávajících implementací webového rozhraní API na ASP.NET Core. Aplikace využívající WebApiCompatShim ale nemají prospěch z funkcí souvisejících s rozhraním API v posledních verzích ASP.NET Core. Mezi tyto funkce patří vylepšené generování specifikace Open API, standardizované zpracování chyb a generování kódu klienta. Aby se lépe zaměřilo úsilí rozhraní API ve verzi 3.0, webApiCompatShim byl odebrán. Stávající aplikace používající WebApiCompatShim by se měly migrovat na novější [ApiController] model.

Zavedená verze

3,0

Důvod změny

Shim kompatibility webového rozhraní API byl nástroj pro migraci. Omezuje přístup uživatelů k novým funkcím přidanám v ASP.NET Core.

Odeberte použití tohoto shimu a migrujte přímo na podobné funkce v samotném ASP.NET Core.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: Odebrané rozhraní API RazorTemplateEngine

Rozhraní RazorTemplateEngine API bylo odebráno a nahrazeno znakem Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Diskuzi najdete v tématu o problému GitHubu dotnet/aspnetcore#25215.

Zavedená verze

3,0

Staré chování

Modul šablony 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í, jako RazorTemplateEngine je parsování a generování kódu pro soubory Razor. RazorProjectEngine poskytuje také další úrovně konfigurace.

Důvod změny

RazorTemplateEngine byla příliš úzce svázána s existujícími implementacemi. Tato úzká spojka vedla k dalším otázkám při pokusu o správnou konfiguraci kanálu analýzy a generování Razor.

Používejte RazorProjectEngine místo RazorTemplateEngine. Podívejte se na následující příklady.

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
        });
Generování kódu 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

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Kompilace modulu runtime přesunutá do balíčku

Podpora kompilace běhových zobrazení Razor a Razor Pages se přesunula do samostatného balíčku.

Zavedená verze

3,0

Staré chování

Kompilace modulu runtime je k dispozici bez nutnosti dalších balíčků.

Nové chování

Funkce byla přesunuta do balíčku Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .

Pro podporu kompilace modulu runtime byly dříve k dispozici Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions následující rozhraní API. Rozhraní API jsou nyní k dispozici prostřednictvím Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders je teď MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences je teď MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Kromě toho Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange byla odebrána. Rekompilace změn souboru je ve výchozím nastavení povolena odkazem na Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation balíček.

Důvod změny

Tato změna byla nutná k odebrání závislosti sdílené architektury ASP.NET Core na Roslynu.

Aplikace, které vyžadují kompilaci modulu runtime nebo rekompilace souborů Razor, by měly provést následující kroky:

  1. Přidejte odkaz na Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation balíček.

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

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Stav relace: Odebraná zastaralá rozhraní API

Byla odebrána zastaralá rozhraní API pro konfiguraci souborů cookie relace. Další informace najdete v tématu aspnet/Announcements#257.

Zavedená verze

3,0

Důvod změny

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

Migrace využití odebraných rozhraní API na novější nahrazení Podívejte se na následující příklad v Startup.ConfigureServices:

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

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

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

Počínaje ASP.NET Core 3.0 obsahuje sdílená architektura ASP.NET Core (Microsoft.AspNetCore.App) pouze sestavení první strany, která jsou plně vyvinutá, podporovaná a použitelná microsoftem.

Změna popisu

Změnu si můžete představit jako předdefinování hranic pro platformu ASP.NET Core. Sdílená architektura bude zdrojově sestavitelná kýmkoli prostřednictvím GitHubu a bude i nadále nabízet stávající výhody sdílených architektur .NET Core pro vaše aplikace. Mezi výhody patří menší velikost nasazení, centralizované opravy a rychlejší spuštění.

V rámci této změny jsou zavedeny Microsoft.AspNetCore.Appněkteré zásadní změny .

Zavedená verze

3,0

Staré chování

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

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

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

Nové chování

Odkaz, který Microsoft.AspNetCore.App už nevyžaduje <PackageReference> prvek v souboru projektu. Sada .NET Core SDK podporuje nový prvek s názvem <FrameworkReference>, který nahrazuje použití <PackageReference>.

Další informace najdete v tématu dotnet/aspnetcore#3612.

Entity Framework Core se dodává jako balíčky NuGet. Tato změna zarovná model expedice se všemi ostatními knihovnami pro přístup k datům v .NET. Poskytuje Entity Framework Core nejjednodušší způsob, jak pokračovat v inovování a zároveň podporovat různé platformy .NET. Přesun Entity Framework Core ze sdílené architektury nemá žádný vliv na její stav jako knihovnu vyvinutou, podporovanou a použitelnou microsoftem. Zásady podpory .NET Core se i nadále týkají.

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

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

Důvod změny

Tato změna zjednodušuje spotřebu Microsoft.AspNetCore.App balíčků NuGet a sdílených architektur a snižuje jejich duplicitu.

Další informace o motivaci k této změně najdete v tomto blogovém příspěvku.

Počínaje ASP.NET Core 3.0 už není nutné, aby projekty spotřebovávají sestavení jako Microsoft.AspNetCore.App balíčky NuGet. Kvůli zjednodušení cílení a použití sdílené architektury ASP.NET Core se řada balíčků NuGet dodává, protože ASP.NET Core 1.0 se už nevygenerují. Rozhraní API, která tyto balíčky poskytují, jsou stále k dispozici pro aplikace pomocí <FrameworkReference>Microsoft.AspNetCore.App Mezi běžné příklady rozhraní API patří Kestrel, MVC a Razor.

Tato změna se nevztahuje na všechny binární soubory odkazované prostřednictvím Microsoft.AspNetCore.App ASP.NET Core 2.x. Mezi velmi vhodné výjimky patří:

  • Microsoft.Extensions knihovny, které nadále cílí na .NET Standard, jsou k dispozici jako balíčky NuGet (viz https://github.com/dotnet/extensions).
  • 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 balíčky NuGet:
  • Rozšíření MVC, která udržují podporu pro Json.NET Rozhraní API je poskytováno jako balíček NuGet, který podporuje použití Json.NET a MVC. Další podrobnosti najdete v průvodci migrací ASP.NET Core.
  • Klient SignalR .NET nadále podporuje .NET Standard a dodává se jako balíček NuGet. Je určen pro použití v mnoha modulech runtime .NET, jako je Xamarin a UPW.

Další informace naleznete v tématu Zastavení vytváření balíčků pro sestavení sdílených architektur v 3.0. Diskuzi najdete v tématu dotnet/aspnetcore#3757.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Sdílená architektura: Odebrání Microsoft.AspNetCore.All

Počínaje ASP.NET Core 3.0 Microsoft.AspNetCore.All se metabalík a odpovídající Microsoft.AspNetCore.All sdílená architektura už nevygenerují. Tento balíček je k dispozici v ASP.NET Core 2.2 a bude nadále dostávat servisní aktualizace v ASP.NET Core 2.1.

Zavedená verze

3,0

Staré chování

Aplikace můžou metabalíč použít Microsoft.AspNetCore.All k cílení na sdílenou architekturu Microsoft.AspNetCore.All v .NET Core.

Nové chování

.NET Core 3.0 neobsahuje sdílenou architekturu Microsoft.AspNetCore.All .

Důvod změny

Metabalíčky Microsoft.AspNetCore.All obsahovaly velký počet externích závislostí.

Migrujte projekt tak, aby používal architekturu Microsoft.AspNetCore.App . Komponenty, které byly dříve dostupné, Microsoft.AspNetCore.All jsou stále dostupné na NuGetu. Tyto komponenty se teď nasazují s vaší aplikací místo toho, aby se zahrnuly do sdílené architektury.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

SignalR: HandshakeProtocol.SuccessHandshakeData nahrazeno

Pole HandshakeProtocol.SuccessHandshakeData bylo odebráno a nahrazeno pomocnou metodou, která vygeneruje úspěšnou odpověď handshake vzhledem ke konkrétnímu IHubProtocol.

Zavedená verze

3,0

Staré chování

HandshakeProtocol.SuccessHandshakeDatapublic static ReadOnlyMemory<byte> bylo pole.

Nové chování

HandshakeProtocol.SuccessHandshakeData byla nahrazena metodou staticGetSuccessfulHandshake(IHubProtocol protocol) , která vrací ReadOnlyMemory<byte> na základě zadaného protokolu.

Důvod změny

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

Nezaokrouhlovat. Tento typ není určený pro použití z uživatelského kódu. publicJe to proto, aby bylo možné ho sdílet mezi serverem SignalR a klientem. Mohou ho také používat klienti SignalR pro zákazníky napsané v .NET. Na uživatele služby SignalR by tato změna neměla mít vliv.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

HandshakeProtocol.SuccessHandshakeData

SignalR: Hub Připojení ion ResetSendPing a ResetTimeout metody odebrané

Metody ResetSendPing a ResetTimeout metody byly odebrány z rozhraní API služby SignalR HubConnection . Tyto metody byly původně určeny pouze pro interní použití, ale byly zpřístupněny ve ASP.NET Core 2.2. Tyto metody nebudou dostupné od verze ASP.NET Core 3.0 Preview 4. Diskuzi najdete v tématu dotnet/aspnetcore#8543.

Zavedená verze

3,0

Staré chování

K dispozici byla rozhraní API.

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 zpřístupněny ve ASP.NET Core 2.2.

Tyto metody nepoužívejte.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SignalR: Hub Připojení ionContext konstruktory změněny

Konstruktory služby SignalR HubConnectionContext se změnily tak, aby přijímaly typ možností, nikoli více parametrů, na možnosti pro budoucí kontrolu pravopisu. Tato změna nahrazuje dva konstruktory jedním konstruktorem, který přijímá typ možností.

Zavedená 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 byly odebrány a nahrazeny jedním konstruktorem:

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

Důvod změny

Nový konstruktor používá nový objekt možností. V důsledku toho lze v budoucnu rozšířit funkce HubConnectionContext , aniž by bylo nutné provádět další konstruktory a rozbíjející změny.

Místo použití následujícího konstruktoru:

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

Použijte následující konstruktor:

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SignalR: Změna názvu balíčku klienta JavaScriptu

V ASP.NET Core 3.0 Preview 7 se název balíčku klienta SignalR JavaScript změnil z @aspnet/signalr na @microsoft/signalr. Změna názvu odráží skutečnost, že služba SignalR je užitečná ve více než jen ASP.NET aplikacích Core, a to díky službě Azure SignalR.

Pokud chcete na tuto změnu reagovat, změňte odkazy ve vašich package.json souborech, require příkazech a příkazech ECMAScript import . V rámci tohoto přejmenování se nezmění žádné rozhraní API.

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

Zavedená verze

3,0

Staré chování

Klientský balíček byl pojmenován @aspnet/signalr.

Nové chování

Klientský balíček má název @microsoft/signalr.

Důvod změny

Změna názvu vysvětluje, že služba SignalR je užitečná mimo ASP.NET aplikací Core, a to díky službě Azure SignalR.

Přepněte na nový balíček @microsoft/signalr.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

SignalR: Metody UseSignalR a Use Připojení ions označené zastaralé

Metody UseConnections a UseSignalR třídy ConnectionsRouteBuilder a HubRouteBuilder jsou označené jako zastaralé v ASP.NET Core 3.0.

Zavedená verze

3,0

Staré chování

Směrování rozbočovače SignalR bylo nakonfigurováno pomocí UseSignalR nebo UseConnections.

Nové chování

Starý způsob konfigurace směrování byl zastaralý a nahrazen směrováním koncového bodu.

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

NahraditUseSignalR: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

SpA: SpaServices a NodeServices označené zastaralé

Obsah následujících balíčků NuGet byl od ASP.NET Core 2.1 nepotřebný. V důsledku toho jsou následující balíčky označeny jako zastaralé:

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

Předchozí balíčky a moduly npm se později odeberou v .NET 5.

Zavedená 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 jednostránkové aplikace (SPA). Mezi tyto architektury patří Angular, React a React s Reduxem.

Nové chování

V balíčku NuGet Microsoft.AspNetCore.SpaServices.Extensions existuje nový mechanismus integrace. Balíček zůstává základem šablon projektů Angular a React od ASP.NET Core 2.1.

Důvod změny

ASP.NET Core podporuje integraci s různými architekturami jednostránkové aplikace (SPA), včetně Angular, React a React s Reduxem. Integrace s těmito architekturami byla zpočátku provedena s komponentami specifických pro ASP.NET Core, které zpracovávaly scénáře, jako je předkončování na straně serveru a integrace s Webpackem. Jak to bylo v čase, oborové standardy se změnily. Každá z architektur SPA vydala vlastní standardní rozhraní příkazového řádku. Například Angular CLI a create-react-app.

Když byl ASP.NET Core 2.1 vydán v květnu 2018, tým odpověděl na změnu standardů. Byl poskytnut novější a jednodušší způsob integrace s vlastními sadami nástrojů architektury SPA. Nový integrační mechanismus existuje v balíčku Microsoft.AspNetCore.SpaServices.Extensions a zůstává základem šablon projektů Angular a React od ASP.NET Core 2.1.

Abychom si vysvětlili, že starší komponenty specifické pro jádro ASP.NET nejsou relevantní a nedoporučuje se:

  • Integrační mechanismus před 2.1 je označený jako zastaralý.
  • Podpůrné balíčky npm jsou označené jako zastaralé.

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

  • Microsoft.AspNetCore.SpaServices.Extensions V balíčku.
  • Poskytované architekturami SPA, které používáte

Pokud chcete povolit funkce, jako je předrenderování na straně serveru a opětovné načtení horkého modulu, přečtěte si dokumentaci pro odpovídající architekturu SPA. Funkce není Microsoft.AspNetCore.SpaServices.Extensions zastaralá a bude nadále podporována.

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

SpA: SpaServices a NodeServices se už nevracely do protokolovacího nástroje konzoly.

Microsoft.AspNetCore.SpaServices a Microsoft.AspNetCore.NodeServices nezobrazí protokoly konzoly, pokud není nakonfigurované protokolování.

Zavedená 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, pokud není nakonfigurované protokolování.

Nové chování

Microsoft.AspNetCore.SpaServices a Microsoft.AspNetCore.NodeServices nezobrazí protokoly konzoly, pokud není nakonfigurované protokolování.

Důvod změny

Je potřeba sladit s tím, jak ostatní balíčky ASP.NET Core implementují protokolování.

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

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Cílová architektura: Vyřazená podpora rozhraní .NET Framework

Počínaje ASP.NET Core 3.0 je .NET Framework nepodporovanou cílovou architekturou.

Změna popisu

.NET Framework 4.8 je poslední hlavní verzí rozhraní .NET Framework. Nové aplikace ASP.NET Core by měly být založené na .NET Core. Počínaje verzí .NET Core 3.0 si můžete představit ASP.NET Core 3.0 jako součást .NET Core.

Zákazníci, kteří používají ASP.NET Core s rozhraním .NET Framework, můžou v plně podporované verzi 2.1 LTS pokračovat. Podpora a údržba pro verzi 2.1 pokračuje až do 21. srpna 2021. Toto datum je tři roky po deklaraci verze LTS podle zásad podpory .NET. Podpora balíčků ASP.NET Core 2.1 v rozhraní .NET Framework se bude neomezeně rozšiřovat, podobně jako zásady údržby pro jiné architektury založené na balíčcích ASP.NET.

Další informace o přenosu z rozhraní .NET Framework do .NET Core najdete v tématu Portování do .NET Core.

Microsoft.Extensions na balíčky (například protokolování, injektáž závislostí a konfigurace) a Entity Framework Core to nemá vliv. Budou i nadále podporovat .NET Standard.

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

Zavedená verze

3,0

Staré chování

ASP.NET aplikace Core se můžou spouštět na rozhraní .NET Core nebo .NET Framework.

Nové chování

ASP.NET aplikace Core je možné spouštět pouze v .NET Core.

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

  • Nechte aplikaci na ASP.NET Core 2.1.
  • Migrace aplikace a závislostí do .NET Core

Kategorie

ASP.NET Core

Ovlivněná rozhraní API

Nic

Knihovny Core .NET

Rozhraní API, která ohlašují verzi sestavy, teď hlásí produkt a ne verzi souboru.

Mnoho rozhraní API, která vrací verze v .NET Core, teď vrací verzi produktu, nikoli verzi souboru.

Změna popisu

V .NET Core 2.2 a předchozích verzích, metody, jako Environment.VersionRuntimeInformation.FrameworkDescriptionje , a dialogové okno vlastností souboru pro sestavení .NET Core odráží verzi souboru. Počínaje .NET Core 3.0 odrážejí verzi produktu.

Následující obrázek znázorňuje rozdíl v informacích o verzi pro sestavení System.Runtime.dll pro .NET Core 2.2 (vlevo) a .NET Core 3.0 (vpravo), jak je znázorněno v dialogovém okně vlastností souboru Průzkumníka Windows.

Difference in product version information

Zavedená verze

3,0

Nezaokrouhlovat. Tato změna by měla intuitivně intuitivně rozpoznávat verze, ne obtěžovat.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Instance Custom EncoderFallbackBuffer se nedají rekurzivně vrátit zpět

Vlastní EncoderFallbackBuffer instance se nedají rekurzivně vrátit. Implementace EncoderFallbackBuffer.GetNextChar() musí mít za následek posloupnost znaků, která se konvertibilní na cílové kódování. V opačném případě dojde k výjimce.

Změna popisu

Během operace převodu znaků na bajt modul runtime zjistí špatně vytvořené nebo nekonvertovatelné sekvence UTF-16 a poskytne těmto znakům metodu EncoderFallbackBuffer.Fallback . Metoda Fallback určuje, které znaky mají být nahrazeny původními nekonvertitelnými daty, a tyto znaky jsou vyprázdněné voláním EncoderFallbackBuffer.GetNextChar smyčky.

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

Dříve vlastní implementace EncoderFallbackBuffer.GetNextChar() mohou vracet sekvence znaků, které nejsou konvertibilní na cílové kódování. Pokud nahrazené znaky nelze překódovat do cílového kódování, modul runtime vyvolá EncoderFallbackBuffer.Fallback metodu znovu s náhradními znaky a očekává, že EncoderFallbackBuffer.GetNextChar() metoda vrátí novou náhradní sekvenci. Tento proces pokračuje, dokud modul runtime nakonec neuvidí správně formátovanou, konvertibilní náhradu nebo dokud se nedosáhne maximálního počtu rekurzí.

Od verze .NET Core 3.0 musí vlastní implementace EncoderFallbackBuffer.GetNextChar() vracet sekvence znaků, které jsou konvertibilní na cílové kódování. Pokud náhradní znaky nelze překódovat do cílového kódování, vyvolá se chyba ArgumentException . Modul runtime už nebude provádět rekurzivní volání instance EncoderFallbackBuffer .

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

  • Modul runtime zjistí špatně vytvořenou sekvenci UTF-16 nebo sekvenci UTF-16, která se nedá převést na cílové kódování.
  • Bylo zadáno vlastní EncoderFallback .
  • Vlastní EncoderFallback pokusy o nahrazení nové špatně vytvořené nebo nekonvertovatelné sekvence UTF-16.

Zavedená verze

3,0

Většinavývojářůch

Pokud aplikace používá vlastní EncoderFallback a EncoderFallbackBuffer třídu, ujistěte se, že implementace EncoderFallbackBuffer.Fallback záložní vyrovnávací paměti s dobře vytvořenými daty UTF-16, která jsou přímo konvertibilní na cílové kódování při Fallback prvním vyvolání metody modulem runtime.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Změnilo se chování při formátování s plovoucí desetinou čárkou a parsování

Chování při analýze a formátování s plovoucí desetinou čárkou (podle typů DoubleSingle ) je teď kompatibilní se standardem IEEE. Tím zajistíte, že chování typů s plovoucí desetinou čárkou v rozhraní .NET odpovídá chování jiných jazyků kompatibilních se standardem IEEE. Například by se měl vždy shodovat s tím, double.Parse("SomeLiteral") co jazyk C# vytvoří .double x = SomeLiteral

Změna popisu

V .NET Core 2.2 a starších verzích formátování pomocí a Single.ToStringparsování pomocí , Double.TryParseSingle.Parsea Single.TryParse nejsou kompatibilní se standardem Double.ToStringDouble.ParseIEEE. V důsledku toho není možné zaručit, že se hodnota zaokrouhlí s jakýmkoli podporovaným standardním nebo vlastním formátovacím řetězcem. U některých vstupů může pokus o parsování formátované hodnoty selhat a u jiných se analyzovaná hodnota nerovná původní hodnotě.

Počínaje .NET Core 3.0 jsou operace analýzy a formátování s plovoucí desetinou čárkou kompatibilní se standardem IEEE 754.

Následující tabulka ukazuje dva fragmenty kódu a způsob změny výstupu mezi .NET Core 2.2 a .NET Core 3.1.

Fragment kódu Výstup v .NET Core 2.2 Výstup v .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0 až
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

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

Zavedená verze

3,0

Potenciální dopad na existující část kódu vylepšení parsování a formátování s plovoucí desetinou čárkou v blogovém příspěvku .NET Core 3.0 navrhuje některé změny, které můžete v kódu provést, pokud chcete zachovat předchozí chování.

  • U některých rozdílů ve formátování můžete získat chování ekvivalentní předchozímu chování zadáním jiného řetězce formátu.
  • U rozdílů při analýze neexistuje žádný mechanismus, který by se vrátil k předchozímu chování.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Operace analýzy s plovoucí desetinou čárkou už selžou nebo vyvolá výjimku OverflowException

Metody parsování s plovoucí desetinnou čárkou už při analýze řetězce, jehož číselná hodnota je mimo rozsah typu s Double plovoucí desetinnou čárkou, už nevyvolají OverflowException ani nevrátífalse.Single

Změna popisu

V .NET Core 2.2 a starších verzích Double.Parse můžou OverflowException metody vyvolat Single.Parse hodnoty, které nejsou v rozsahu příslušného typu. Metody Double.TryParse a Single.TryParse návraty false pro řetězcové reprezentace číselných hodnot mimo rozsah.

Počínaje rozhraním .NET Core 3.0 Double.ParseDouble.TryParseSingle.Parseuž selžou metody a Single.TryParse metody při analýze číselných řetězců mimo rozsah. Double Místo toho metody analýzy vrátí Double.PositiveInfinity hodnoty, které překračují Double.MaxValue, a vrátí Double.NegativeInfinity hodnoty, které jsou menší než Double.MinValue. Single Podobně metody analýzy vrací Single.PositiveInfinity hodnoty, které překračují Single.MaxValue, a vrátí Single.NegativeInfinity hodnoty, které jsou menší než Single.MinValue.

Tato změna byla provedena pro lepší dodržování předpisů IEEE 754:2008.

Zavedená verze

3,0

Tato změna může ovlivnit váš kód dvěma způsoby:

  • Váš kód závisí na obslužné rutině OverflowException , která se má provést, když dojde k přetečení. V tomto případě byste měli příkaz odebrat catch a umístit veškerý potřebný kód do If příkazu, který testuje, zda Double.IsInfinity nebo Single.IsInfinity je true.

  • Váš kód předpokládá, že hodnoty s plovoucí desetinou čárkou nejsou Infinity. V tomto případě byste měli přidat potřebný kód pro kontrolu hodnot s plovoucí desetinou čárkou PositiveInfinity a NegativeInfinity.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

InvalidAsynchronousStateException přesunuto do jiného sestavení

Třída InvalidAsynchronousStateException byla přesunuta.

Změna popisu

V .NET Core 2.2 a starších verzích InvalidAsynchronousStateException se třída nachází v sestavení System.ComponentModel.TypeConverter .

Počínaje .NET Core 3.0 se nachází v sestavení System.ComponentModel.Primitives .

Zavedená verze

3,0

Tato změna má vliv pouze na aplikace, které používají reflexi k načtení InvalidAsynchronousStateException volání metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě aktualizujte sestavení odkazované ve volání metody tak, aby odráželo nové umístění sestavení typu.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Nezaokrouhlovat.

Nahrazení špatně vytvořených sekvencí UTF-8 bajtů se řídí pokyny unicode.

Když třída UTF8Encoding během operace převodu bajtů na znak zaznamená špatně vytvořenou sekvenci UTF-8 bajtů, nahradí ji znakem ' (U+FFFD REPLACE CHARACTER) ve výstupním řetězci. .NET Core 3.0 se liší od předchozích verzí .NET Core a rozhraní .NET Framework podle osvědčeného postupu kódování Unicode pro provedení této náhrady během operace překódování.

To je součástí většího úsilí o zlepšení zpracování UTF-8 v rámci .NET, včetně nových System.Text.Unicode.Utf8 a System.Text.Rune typů. Tento UTF8Encoding typ získal vylepšenou mechaniku zpracování chyb, aby vytvořil výstup konzistentní s nově zavedenými typy.

Změna popisu

Počínaje .NET Core 3.0 při překódování bajtů na znaky UTF8Encoding třída provádí nahrazení znaků na základě osvědčených postupů unicode. Použitý mechanismus nahrazení popisuje Standard Unicode verze 12.0, s. 3.9 (PDF) v nadpisu s názvem U+FFFD Subparts.

Toto chování platí pouze v případě, že vstupní bajtová sekvence obsahuje špatně vytvořená data UTF-8. Kromě toho, pokud UTF8Encoding instance byla vytvořena throwOnInvalidBytes: trues , UTF8Encoding instance bude nadále vyvolána na neplatný vstup místo provedení U+FFFD nahrazení. Další informace o konstruktoru UTF8Encoding naleznete v tématu UTF8Encoding(Boolean, Boolean).

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

3 bajtový vstup s neformulovanou dvěma bajty Výstup před .NET Core 3.0 Výstup začínající na .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (Výstup se 2 znaky) [ FFFD FFFD FFFD ] (Výstup se 3 znaky)

3-char výstup je upřednostňovaný výstup podle tabulky 3-9 dříve propojeného Unicode Standard PDF.

Zavedená verze

3,0

Na straně vývojáře není nutná žádná akce.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

TypeDescriptionProviderAttribute přesunuto do jiného sestavení

Třída TypeDescriptionProviderAttribute byla přesunuta.

Změna popisu

V .NET Core 2.2 a starších verzích se TypeDescriptionProviderAttribute třída nachází v sestavení System.ComponentModel.TypeConverter .

Počínaje rozhraním .NET Core 3.0 se nachází v sestavení System.ObjectModel .

Zavedená verze

3,0

Tato změna má vliv pouze na aplikace, které používají reflexi k načtení TypeDescriptionProviderAttribute typu voláním metody, jako Assembly.GetType je nebo přetížení Activator.CreateInstance , které předpokládá, že typ je v konkrétním sestavení. V takovém případě by se sestavení odkazované ve volání metody mělo aktualizovat tak, aby odráželo nové umístění sestavení typu.

Kategorie

Windows Forms

Ovlivněná rozhraní API

Nezaokrouhlovat.

ZipArchiveEntry už nezpracuje archivy s nekonzistentními velikostmi položek.

Seznam archivů zip komprimované i nekomprimované velikosti v centrálním adresáři a místní hlavičce. Samotná vstupní data také označují svou velikost. V .NET Core 2.2 a starších verzích nebyly tyto hodnoty nikdy zkontrolovány na konzistenci. Počínaje .NET Core 3.0 jsou teď.

Změna popisu

V .NET Core 2.2 a starších verzích je úspěšné, ZipArchiveEntry.Open() i když místní hlavička nesouhlasí s centrální hlavičkou souboru ZIP. Data se dekompresí do dosažení konce komprimovaného datového proudu, i když jeho délka překračuje nekomprimovanou velikost souboru uvedenou v centrální hlavičce adresáře nebo místního adresáře.

Počínaje rozhraním .NET Core 3.0 metoda kontroluje, ZipArchiveEntry.Open() jestli místní hlavička a centrální hlavička souhlasí s komprimovanými a nekomprimovanými velikostmi položky. Pokud tomu tak není, metoda vyvolá InvalidDataException , pokud místní záhlaví archivu nebo seznam popisovačů dat, které nesouhlasí s centrálním adresářem souboru ZIP. Při čtení položky se dekomprimovaná data zkrátí na nekomprimovanou velikost souboru uvedenou v záhlaví.

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

Zavedená verze

3,0

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

FieldInfo.SetValue vyvolá výjimku pro statická pole, pouze inicializační pole

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

Změna popisu

V rozhraní .NET Framework a verzích .NET Core před verzí 3.0 můžete nastavit hodnotu statického pole, které je po inicializaci (jen pro čtení v jazyce C#) voláním System.Reflection.FieldInfo.SetValue. Nastavení takového pole tímto způsobem však vedlo k nepředvídatelným chováním na základě cílové architektury a nastavení optimalizace.

V .NET Core 3.0 a novějších verzích se při volání SetValue statického InitOnly pole System.FieldAccessException vyvolá výjimka.

Tip

Pole InitOnly je pole, které lze nastavit pouze v době, kdy je deklarována nebo v konstruktoru pro obsahující třídu. Jinými slovy, po inicializaci je konstantní.

Zavedená verze

3,0

Inicializace statických InitOnly polí ve statickém konstruktoru To platí pro dynamické i ne dynamicky.

Případně můžete atribut z pole odebrat FieldAttributes.InitOnly a potom volat FieldInfo.SetValue.

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

Předání GroupCollection rozšiřujícím metodám, které přebírají IEnumerable<T> , vyžaduje nejednoznačnost

Při volání rozšiřující metody, která přebírá IEnumerable<T> na , GroupCollectionmusíte nejednoznačit typ pomocí přetypování.

Změna popisu

Počínaje .NET Core 3.0 System.Text.RegularExpressions.GroupCollection implementuje IEnumerable<KeyValuePair<String,Group>> kromě dalších typů, které implementuje, včetně IEnumerable<Group>. Výsledkem je nejednoznačnost při volání rozšiřující metody, která přebírá IEnumerable<T>. Pokud takovou metodu GroupCollection rozšíření voláte například Enumerable.Countv instanci, zobrazí se následující chyba kompilátoru:

CS1061: GroupCollection neobsahuje definici pro Count a nelze najít žádnou přístupnou metodu rozšíření Count, která přijímá první argument typu GroupCollection (chybí direktiva using nebo odkaz na sestavení?)

V předchozích verzích rozhraní .NET nebyla žádná nejednoznačnost a chyba kompilátoru.

Zavedená verze

3,0

Důvod změny

To byla neúmyslná změna způsobující chybu. Protože to bylo už nějakou dobu podobné, neplánujeme ho vrátit. Kromě toho by se taková změna sama o sobě rozbila.

Například GroupCollection nejednoznačné volání rozšiřujících metod, které přijímají přetypování IEnumerable<T> .

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

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

Kategorie

Knihovny Core .NET

Ovlivněná rozhraní API

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

Kryptografie

Syntaxe "BEGIN TRUSTED CERTIFICATE" už není podporována pro kořenové certifikáty v Linuxu.

Kořenové certifikáty v systémech Linux a jiných systémů unixových (ale ne macOS) se dají prezentovat ve dvou formách: standardní BEGIN CERTIFICATE hlavička PEM a hlavička PEM specifická pro BEGIN TRUSTED CERTIFICATE OpenSSL. Druhá syntaxe umožňuje další konfiguraci, která způsobila problémy s kompatibilitou třídy .NET Core System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATE Obsah kořenového certifikátu již není načten řetězovým modulem začínajícím v .NET Core 3.0.

Změna popisu

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

Od verze .NET Core 3.0 BEGIN TRUSTED CERTIFICATE se obsah už nepřečte. Pokud certifikát není zadán také prostřednictvím standardní BEGIN CERTIFICATE syntaxe, sestavy, X509Chain které kořen není důvěryhodný (X509ChainStatusFlags.UntrustedRoot).

Zavedená verze

3,0

Na většinu aplikací tato změna nemá vliv, ale aplikace, které nevidí oba kořenové zdroje certifikátů kvůli problémům s oprávněními, můžou po upgradu dojít k neočekávaným UntrustedRoot chybám.

Mnoho distribucí Linuxu (nebo distribucí) zapisuje kořenové certifikáty do dvou umístění: adresář s jedním certifikátem na soubor a zřetězení jednoho souboru. V některých distribucích používá BEGIN TRUSTED CERTIFICATE adresář one-certificate-per-file syntaxi, zatímco zřetězení souboru používá standardní BEGIN CERTIFICATE syntaxi. Ujistěte se, že jsou všechny vlastní kořenové certifikáty přidány jako BEGIN CERTIFICATE v nejméně jednom z těchto umístění a že obě umístění může vaše aplikace číst.

Typický adresář je /etc/ssl/certs/ a typický zřetězený soubor je /etc/ssl/cert.pem. Pomocí příkazu openssl version -d určete kořen specifický pro platformu, který se může lišit od /etc/ssl/. Například na Ubuntu 18.04 je adresář /usr/lib/ssl/certs/ a soubor je /usr/lib/ssl/cert.pem. /usr/lib/ssl/certs/ je symlink na /etc/ssl/certs/ a /usr/lib/ssl/cert.pem neexistuje.

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

Kategorie

Kryptografie

Ovlivněná rozhraní API

ObálkaCms ve výchozím nastavení šifrování AES-256

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

Změna popisu

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

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

V následujícím vzorovém kódu se data šifrují pomocí TripleDES, pokud běží na .NET Core 2.2 nebo starším. Pokud běží na .NET Core 3.0 nebo novějším, je šifrovaný pomocí AES-256.

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

Zavedená verze

3,0

Pokud vás změna negativně ovlivní, můžete šifrování TripleDES obnovit explicitním zadáním identifikátoru šifrovacího algoritmu v EnvelopedCms konstruktoru, který obsahuje parametr typu AlgorithmIdentifier, například:

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

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

Kategorie

Kryptografie

Ovlivněná rozhraní API

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

Minimální velikost pro generování nových klíčů RSA v Linuxu se zvýšila z 384bitové na 512bitovou.

Změna popisu

Od verze .NET Core 3.0 se minimální velikost právního klíče hlášená LegalKeySizes vlastností instancí RSA z RSA.Createa RSAOpenSslRSACryptoServiceProvider v Linuxu zvýšila z 384 na 512.

V důsledku toho v .NET Core 2.2 a starších verzích volání metody, jako RSA.Create(384) je úspěšné. V .NET Core 3.0 a novějších verzích vyvolá volání RSA.Create(384) metody výjimku, která značí, že velikost je příliš malá.

Tato změna byla provedena, protože OpenSSL, která provádí kryptografické operace v Linuxu, zvýšilo své minimum mezi verzemi 1.0.2 a 1.1.0. .NET Core 3.0 upřednostňuje OpenSSL 1.1.x až 1.0.x a minimální hlášená verze byla vyvolána tak, aby odrážela toto nové vyšší omezení závislostí.

Zavedená verze

3,0

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

Poznámka:

384bitové RSA se už považuje za nezabezpečené (stejně jako 512bitové RSA). Moderní doporučení, jako je například speciální publikace NIST 800–57 část 1 revize 4, navrhují 2048bitovou verzi jako minimální velikost pro nově generované klíče.

Kategorie

Kryptografie

Ovlivněná rozhraní API

.NET Core 3.0 preferuje OpenSSL 1.1.x k OpenSSL 1.0.x

.NET Core pro Linux, která funguje v různých distribucích Linuxu, podporuje OpenSSL 1.0.x i OpenSSL 1.1.x. .NET Core 2.1 a .NET Core 2.2 nejprve vyhledejte verzi 1.0.x a pak se vraťte na verzi 1.1.x; .NET Core 3.0 nejprve hledá verzi 1.1.x. Tato změna byla provedena tak, aby se přidala podpora nových kryptografických standardů.

Tato změna může mít vliv na knihovny nebo aplikace, které interop platformy s typy spolupráce specifické pro OpenSSL v .NET Core.

Změna popisu

V .NET Core 2.2 a starších verzích dává modul runtime přednost načítání OpenSSL 1.0.x než 1.1.x. To znamená, že a SafeHandle typy pro interoperabilitu IntPtr s OpenSSL se používají s libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 podle preference.

Počínaje .NET Core 3.0, modul runtime dává přednost načítání OpenSSL 1.1.x přes OpenSSL 1.0.x, takže IntPtr a SafeHandle typy pro interoperabilitu s OpenSSL se používají s libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 podle preferencí. V důsledku toho mohou knihovny a aplikace, které interoperují s OpenSSL přímo, mít nekompatibilní ukazatele s hodnotami vystavenými .NET Core při upgradu z .NET Core 2.1 nebo .NET Core 2.2.

Zavedená verze

3,0

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

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

Kategorie

Kryptografie

Ovlivněná rozhraní API

CryptoStream.Dispose transformuje konečný blok pouze při zápisu

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

Změna popisu

Pokud uživatel v předchozích verzích .NET při použití CryptoStream v Read režimu provedl neúplné čtení, Dispose může metoda vyvolat výjimku (například při použití AES s odsazením). Výjimka byla vyvolána, protože se poslední blok pokusil o transformaci, ale data nebyla dokončena.

V .NET Core 3.0 a novějších verzích Dispose se už při čtení nepokusí transformovat konečný blok, který umožňuje neúplné čtení.

Důvod změny

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

Zavedená verze

3,0

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

Pokud vaše aplikace dříve chytila výjimku v případě neúplného čtení, můžete tento catch blok odstranit. Pokud vaše aplikace ve scénářích hash použila transformaci konečného bloku, možná budete muset před odstraněním celého datového proudu zajistit, aby se celý datový proud četl.

Kategorie

Kryptografie

Ovlivněná rozhraní API

Entity Framework Core

Zásadní změny entity Framework Core

Globalizace

Národní prostředí "C" se mapuje na invariantní národní prostředí

.NET Core 2.2 a starší verze závisí na výchozím chování jednotky ICU, které mapuje národní prostředí "C" na en_US_POSIX národní prostředí. Národní prostředí en_US_POSIX má nežádoucí chování kolace, protože nepodporuje porovnávání řetězců bez rozlišování velkých a malých písmen. Vzhledem k tomu, že některé linuxové distribuce nastavily národní prostředí "C" jako výchozí národní prostředí, došlo k neočekávanému chování uživatelů.

Změna popisu

Od verze .NET Core 3.0 se mapování národního prostředí jazyka C změnilo tak, aby místo en_US_POSIX používalo invariantní národní prostředí. Národní prostředí "C" na invariantní mapování je také použito pro systém Windows kvůli konzistenci.

Mapování "C" na en_US_POSIX jazykové verzi způsobilo nejasnost zákazníků, protože en_US_POSIX nepodporuje operace řazení a vyhledávání řetězců nerozlišující malá a velká písmena. Vzhledem k tomu, že národní prostředí "C" se používá jako výchozí národní prostředí v některých distribucích Linuxu, zaznamenali zákazníci toto nežádoucí chování v těchto operačních systémech.

Zavedená verze

3,0

Nic konkrétního než povědomí o této změně. Tato změna má vliv pouze na aplikace, které používají mapování národního prostředí jazyka C.

Kategorie

Globalizace

Ovlivněná rozhraní API

Tato změna ovlivňuje všechna kolace a rozhraní API jazykové verze.

MSBuild

Změna názvu souboru manifestu prostředku

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

Zavedená verze

3,0

Změna popisu

Před .NET Core 3.0, pokud nebyla zadána žádná LogicalNameManifestResourceName, nebo DependentUpon metadata pro EmbeddedResource položku v souboru projektu, nástroj MSBuild vygeneroval název souboru manifestu ve vzoru <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Pokud RootNamespace není v souboru projektu definováno, je výchozí název projektu. Například vygenerovaný název manifestu pro soubor prostředků s názvem Form1.resx v kořenovém adresáři projektu byl MyProject.Form1.resources.

Počínaje .NET Core 3.0, pokud je soubor prostředků společně přidělený se zdrojovým souborem se stejným názvem (například Form1.resx a Form1.cs), nástroj MSBuild používá informace o typu ze zdrojového souboru k vygenerování názvu souboru manifestu ve vzoru <Namespace>.<ClassName>.resources. Obor názvů a název třídy se extrahují z prvního typu v spolulokovaném zdrojovém souboru. Například vygenerovaný název manifestu pro soubor prostředků s názvem Form1.resx , který je společně přidělený zdrojovým souborem s názvem Form1.cs je MyNamespace.Form1.resources. Klíčovou věcí, kterou je třeba poznamenat, je, že první část názvu souboru se liší od předchozích verzí .NET Core (MyNamespace místo MyProject).

Poznámka:

Pokud máte LogicalName, ManifestResourceNamenebo DependentUpon metadata zadaná pro EmbeddedResource položku v souboru projektu, tato změna nemá vliv na tento soubor zdroje.

Tato změna způsobující chybu byla zavedena přidáním EmbeddedResourceUseDependentUponConvention vlastnosti do projektů .NET Core. Ve výchozím nastavení nejsou soubory prostředků explicitně uvedeny v souboru projektu .NET Core, takže nemají žádná DependentUpon metadata k určení, jak pojmenovat vygenerovaný soubor .resources . Pokud EmbeddedResourceUseDependentUponConvention je nastavena na true, což je výchozí, NÁSTROJ MSBuild vyhledá společnělokovaný zdrojový soubor a extrahuje obor názvů a název třídy z daného souboru. Pokud nastavíte EmbeddedResourceUseDependentUponConvention hodnotu false, nástroj MSBuild vygeneruje název manifestu podle předchozího chování, které kombinuje RootNamespace a relativní cestu k souboru.

Ve většině případů se nevyžaduje žádná akce na straně vývojáře a vaše aplikace by měla dál fungovat. Pokud ale tato změna aplikaci přeruší, můžete:

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

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

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

Kategorie

MSBuild

Ovlivněná rozhraní API

–

Sítě

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

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

Zavedená verze

3,0

Změna popisu

V .NET Core 1.0 až 2.0 je výchozí hodnota System.Net.Http.HttpRequestMessage.Version vlastnosti 1.1. Od verze .NET Core 2.1 se změnila na 2.1.

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

Aktualizujte kód, pokud závisí na System.Net.Http.HttpRequestMessage.Version vlastnosti, která vrací výchozí hodnotu 2.0.

Kategorie

Sítě

Ovlivněná rozhraní API

Viz také