Share via

Kompatibilitástörő változások a .NET Core 3.0-ban

  • Cikk

Ha a .NET Core, ASP.NET Core vagy EF Core 3.0-s verziójára migrál, a cikkben felsorolt kompatibilitástörő változások hatással lehetnek az alkalmazásra.

ASP.NET Core

Elavult antiforgery, CORS, Diagnostics, MVC és Routing API-k el lettek távolítva

A ASP.NET Core 2.2 elavult tagjai és kompatibilitási kapcsolói el lettek távolítva.

Bevezetett verzió

3,0

A változás oka

Az API-felület fejlesztése idővel.

Miközben a .NET Core 2.2-t célozza, kövesse az elavult buildüzenetekben található útmutatást az új API-k bevezetéséhez.

Kategória

ASP.NET Core

Érintett API-k

A következő típusok és tagok elavultként lettek megjelölve ASP.NET Core 2.1 és 2.2 esetében:

Típusok

  • 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

Konstruktorok

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

Tulajdonságok

  • 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

Módszerek

"Pubternal" API-k el lettek távolítva

A ASP.NET Core nyilvános API-felületének jobb fenntartása érdekében a névterek legtöbb típusa *.Internal (más néven "pubternal" API-k) valóban belsővé váltak. Az ilyen névterek tagjai soha nem voltak nyilvános elérésű API-kként támogatva. Az API-k kisebb kiadásokban is megtörhetnek, és gyakran így is tették. Ezektől az API-któl függő kód megszakad, amikor ASP.NET Core 3.0-ra frissít.

További információ: dotnet/aspnetcore#4932 és dotnet/aspnetcore#11312.

Bevezetett verzió

3,0

Régi viselkedés

Az érintett API-k a hozzáférés-módosítóval vannak megjelölve public , és névterekben *.Internal léteznek.

Új viselkedés

Az érintett API-k a belső hozzáférés-módosítóval vannak megjelölve, és a továbbiakban nem használhatók a szerelvényen kívüli kódok.

A változás oka

Ezeknek "pubternal" az API-knak az útmutatása az volt, hogy:

  • Értesítés nélkül változhat.
  • Nem tartoznak a .NET-szabályzatok hatálya alá, hogy megakadályozzák a kompatibilitástörő változásokat.

Az API-k public elhagyása (még a *.Internal névterekben is) zavaró volt az ügyfelek számára.

Hagyja abba ezeknek az API-knak a "pubternal" használatát. Ha kérdése van a másodlagos API-kkal kapcsolatban, nyisson meg egy problémát a dotnet/aspnetcore adattárban.

Vegyük például az alábbi HTTP-kérések pufferelési kódját egy ASP.NET Core 2.2-projektben. A EnableRewind bővítménymetódus a Microsoft.AspNetCore.Http.Internal névtérben létezik.

HttpContext.Request.EnableRewind();

Egy ASP.NET Core 3.0-projektben cserélje le a EnableRewind hívást a EnableBuffering bővítménymetódus hívására. A kérések pufferelése a korábbiakhoz hasonlóan működik. EnableBuffering meghívja a now API-t internal .

HttpContext.Request.EnableBuffering();

Kategória

ASP.NET Core

Érintett API-k

A névtérnévben szegmenst Microsoft.AspNetCore.*Internal tartalmazó összes API és Microsoft.Extensions.* névtér. Példa:

  • 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

Hitelesítés: A Google+ elavult és lecserélt

A Google már 2019. január 28-tól leállítja a Google+ bejelentkezést az alkalmazásokhoz.

Módosítás leírása

ASP.NET 4.x és ASP.NET Core a Google+ bejelentkezési API-kkal hitelesíti a Google-fiók felhasználóit a webalkalmazásokban. Az érintett NuGet-csomagok a Microsoft.AspNetCore.Authentication.Google for ASP.NET Core és a Microsoft.Owin.Security.Google for Microsoft.Owin ASP.NET Web Forms és MVC.

A Google helyettesítő API-k más adatforrást és formátumot használnak. Az alábbiakban ismertetett kockázatcsökkentések és megoldások figyelembe veszik a strukturális változásokat. Az alkalmazásoknak ellenőrizniük kell, hogy az adatok továbbra is megfelelnek-e a követelményeknek. A nevek, e-mail-címek, profilhivatkozások és profilképek például a korábbiaktól eltérő értékeket adhatnak meg.

Bevezetett verzió

Minden verzió. Ez a módosítás kívül esik ASP.NET Core-ra.

Owin ASP.NET Webes űrlapokkal és MVC-vel

A 3.1.0-s és újabb verziók esetében Microsoft.Owin az alábbiakban egy ideiglenes kockázatcsökkentést ismertetünk. Az alkalmazásoknak végre kell hajtaniuk a tesztelést a kockázatcsökkentéssel az adatformátum változásainak ellenőrzéséhez. A 4.0.1-es verziót javítással tervezik kiadni Microsoft.Owin . A korábbi verziót használó alkalmazásoknak a 4.0.1-es verzióra kell frissülnie.

ASP.NET Core 1.x

Az Owin ASP.NET Webes űrlapokkal és MVC-vel kapcsolatos kockázatcsökkentés ASP.NET Core 1.x-hez igazítható. A NuGet-csomag javításai nem tervezettek, mert az 1.x elérte az élettartam végét.

ASP.NET Core 2.x

A 2.x verzió esetén Microsoft.AspNetCore.Authentication.Google cserélje le a meglévő hívását AddGoogleStartup.ConfigureServices a következő kódra:

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

A február 2.1-i és 2.2-i javítások az előző újrakonfigurálást beépítették új alapértelmezettként. Az ASP.NET Core 2.0-hoz nem tervezünk javítást , mivel az az élettartam végéhez ért.

ASP.NET Core 3.0

A ASP.NET Core 2.x-hez megadott kockázatcsökkentés a Core 3.0 ASP.NET is használható. A jövőbeli 3.0-s előzetes verziókban a Microsoft.AspNetCore.Authentication.Google csomag eltávolítható. A felhasználókat ehelyett a rendszer átirányítja Microsoft.AspNetCore.Authentication.OpenIdConnect . Az alábbi kód bemutatja, hogyan lehet lecserélni a AddOpenIdConnect következőre AddGoogleStartup.ConfigureServices: . Ez a csere ASP.NET Core 2.0-s és újabb verziójával használható, és szükség szerint ASP.NET Core 1.x-hez is alkalmazható.

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

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Authentication.Google

Hitelesítés: A HttpContext.Authentication tulajdonság el lett távolítva

Az elavult Authentication tulajdonság HttpContext el lett távolítva.

Módosítás leírása

A dotnet/aspnetcore#6504 részeként az elavult Authentication tulajdonság HttpContext el lett távolítva. A Authentication tulajdonság 2.0 óta elavult. Megjelent egy migrálási útmutató a kód áttelepítéséhez az elavult tulajdonság használatával az új helyettesítő API-kba. A régi ASP.NET Core 1.x hitelesítési veremhez kapcsolódó fennmaradó fel nem használt osztályok/API-k el lettek távolítva a véglegesítési dotnet/aspnetcore@d7a7c65.

További információért lásd: dotnet/aspnetcore#6533.

Bevezetett verzió

3,0

A változás oka

ASP.NET Core 1.0 API-kat bővítménymetelyek váltották fel a Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Tekintse meg a migrálási útmutatót.

Kategória

ASP.NET Core

Érintett API-k

Hitelesítés: A Newtonsoft.Json-típusok lecserélve

A ASP.NET Core 3.0-ban Newtonsoft.Json a hitelesítési API-kban használt típusok típusok lettek lecserélve típusokra System.Text.Json . A következő esetek kivételével a hitelesítési csomagok alapszintű használata nem változik:

  • Az OAuth-szolgáltatókból származó osztályok, például az aspnet-contribtól származó osztályok.
  • Speciális jogcímmanipulációs implementációk.

További információ: dotnet/aspnetcore#7105. További információért lásd: dotnet/aspnetcore#7289.

Bevezetett verzió

3,0

A származtatott OAuth-implementációk esetében a leggyakoribb változás az, hogy a felülbírálást az itt látható módon kell lecserélni JObject.ParseJsonDocument.Parse.CreateTicketAsync JsonDocumentimplementálja.IDisposable

Az alábbi lista az ismert változásokat vázolja fel:

Kategória

ASP.NET Core

Érintett API-k

Hitelesítés: OAuthHandler ExchangeCodeAsync-aláírás módosult

A ASP.NET Core 3.0-ban az aláírás a OAuthHandler.ExchangeCodeAsync következőről módosult:

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

Címzett:

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

Bevezetett verzió

3,0

Régi viselkedés

Az code és redirectUri a sztringek külön argumentumként lettek átadva.

Új viselkedés

Code és RedirectUri olyan tulajdonságok OAuthCodeExchangeContext , amelyek a OAuthCodeExchangeContext konstruktoron keresztül állíthatók be. Az új OAuthCodeExchangeContext típus az egyetlen argumentum, amely a következőnek lett átadva OAuthHandler.ExchangeCodeAsync:

A változás oka

Ez a módosítás lehetővé teszi, hogy a további paramétereket nem feltörhető módon adja meg. Nincs szükség új ExchangeCodeAsync túlterhelések létrehozására.

Hozzon létre egy OAuthCodeExchangeContext megfelelő code és redirectUri értékekkel rendelkezőt. Meg kell adni egy AuthenticationProperties példányt. Ez az egyetlen OAuthCodeExchangeContext példány több argumentum helyett átadható OAuthHandler.ExchangeCodeAsync .

Kategória

ASP.NET Core

Érintett API-k

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Engedélyezés: Az AddAuthorization túlterhelése átkerült egy másik szerelvényre

A korábban Microsoft.AspNetCore.Authorization használt alapvető AddAuthorization metódusokat átnevezték a következőreAddAuthorizationCore: . A régi AddAuthorization metódusok továbbra is léteznek, de inkább a Microsoft.AspNetCore.Authorization.Policy szerelvényben vannak. A mindkét módszert használó alkalmazásoknak nincs hatása. Vegye figyelembe, hogy Microsoft.AspNetCore.Authorization.Policy a megosztott keretrendszerben most már nem önálló csomagként, hanem a megosztott keretrendszerben tárgyaltak szerint: A szerelvényeket eltávolították a Microsoft.AspNetCore.App.

Bevezetett verzió

3,0

Régi viselkedés

AddAuthorization metódusok léteztek a következőben: Microsoft.AspNetCore.Authorization.

Új viselkedés

AddAuthorization metódusok léteznek a következőben Microsoft.AspNetCore.Authorization.Policy: . AddAuthorizationCore a régi metódusok új neve.

A változás oka

AddAuthorization jobb metódusnév az engedélyezéshez szükséges összes általános szolgáltatás hozzáadásához.

Adjon hozzá egy hivatkozást, Microsoft.AspNetCore.Authorization.Policy vagy használja AddAuthorizationCore helyette.

Kategória

ASP.NET Core

Érintett API-k

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

Engedélyezés: Az IAllowAnonymous el lett távolítva az AuthorizationFilterContext.Filters fájlból

A Core 3.0 ASP.NET esetében az MVC nem ad hozzá AllowAnonymousFilters attribútumokata vezérlők és a műveleti metódusok által felderített [AllowAnonymous] attribútumokhoz. Ezt a módosítást helyileg kezelik a származékok AuthorizeAttributeesetében, de ez egy kompatibilitástörő változás az implementációk és IAuthorizationFilter az implementációk esetébenIAsyncAuthorizationFilter. A [TypeFilter] attribútumba burkolt implementációk népszerűek és támogatottak az erősen gépelt, attribútumalapú engedélyezés elérésére, ha konfigurációra és függőséginjektálásra is szükség van.

Bevezetett verzió

3,0

Régi viselkedés

IAllowAnonymous az AuthorizationFilterContext.Filters gyűjteményben jelent meg . A felület jelenlétének tesztelése érvényes módszer volt a szűrő felülbírálásához vagy letiltásához az egyes vezérlő metódusokon.

Új viselkedés

IAllowAnonymous már nem jelenik meg a AuthorizationFilterContext.Filters gyűjteményben. IAsyncAuthorizationFilter a régi viselkedéstől függő implementációk általában időszakos HTTP 401 jogosulatlan vagy HTTP 403 Tiltott válaszokat okoznak.

A változás oka

Új végpont-útválasztási stratégia jelent meg a ASP.NET Core 3.0-ban.

Keresse meg a végpont metaadatait IAllowAnonymous. Példa:

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

Erre a technikára egy példa látható ebben a HasAllowAnonymous metódusban.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Engedélyezés: Az IAuthorizationPolicyProvider-implementációk új módszert igényelnek

A ASP.NET Core 3.0-ban egy új GetFallbackPolicyAsync metódus lett hozzáadva.IAuthorizationPolicyProvider Ezt a tartalék szabályzatot az engedélyezési köztes szoftver használja, ha nincs megadva szabályzat.

További információ: dotnet/aspnetcore#9759.

Bevezetett verzió

3,0

Régi viselkedés

Az implementációkhoz IAuthorizationPolicyProvider nem volt szükség metódusra GetFallbackPolicyAsync .

Új viselkedés

A végrehajtáshoz IAuthorizationPolicyProvider szükség van egy metódusra GetFallbackPolicyAsync .

A változás oka

Új metódusra volt szükség ahhoz, hogy az új AuthorizationMiddleware használhassa, ha nincs megadva szabályzat.

Adja hozzá a GetFallbackPolicyAsync metódust a implementációkhoz IAuthorizationPolicyProvider.

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Gyorsítótárazás: A CompactOnMemoryPressure tulajdonság el lett távolítva

A ASP.NET Core 3.0 kiadás eltávolította az elavult MemoryCacheOptions API-kat.

Módosítás leírása

Ez a változás az aspnet/Caching#221 nyomon követése. További információért lásd: dotnet/extensions#1062.

Bevezetett verzió

3,0

Régi viselkedés

MemoryCacheOptions.CompactOnMemoryPressure tulajdonság elérhető volt.

Új viselkedés

A MemoryCacheOptions.CompactOnMemoryPressure tulajdonság el lett távolítva.

A változás oka

A gyorsítótár automatikus tömörítése problémákat okozott. A váratlan viselkedés elkerülése érdekében a gyorsítótárat csak szükség esetén kell tömöríteni.

A gyorsítótár tömörítéséhez szükség esetén lekérte és MemoryCache meghívhatja Compact a gyorsítótárat.

Kategória

ASP.NET Core

Érintett API-k

MemoryCacheOptions.CompactOnMemoryPressure

Gyorsítótárazás: A Microsoft.Extensions.Caching.SqlServer új SqlClient-csomagot használ

A Microsoft.Extensions.Caching.SqlServer csomag csomag helyett System.Data.SqlClient az új Microsoft.Data.SqlClient csomagot fogja használni. Ez a változás enyhe viselkedésbeli törést okozhat. További információ: Az új Microsoft.Data.SqlClient bemutatása.

Bevezetett verzió

3,0

Régi viselkedés

A Microsoft.Extensions.Caching.SqlServer csomag használta a System.Data.SqlClient csomagot.

Új viselkedés

Microsoft.Extensions.Caching.SqlServer most már használja a Microsoft.Data.SqlClient csomagot.

A változás oka

Microsoft.Data.SqlClient egy új csomag, amely a System.Data.SqlClient. Mostantól minden új funkció itt fog működni.

Az ügyfeleknek nem kell aggódniuk a kompatibilitástörő változás miatt, kivéve, ha a Microsoft.Extensions.Caching.SqlServer csomag által visszaadott és típusokra System.Data.SqlClient öntött típusokat használták. Ha például valaki a régi Sql Csatlakozás ion típust adja DbConnection meg, akkor az új Microsoft.Data.SqlClient.SqlConnection típusra kell módosítania a leadást.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Gyorsítótárazás: A ResponseCaching "pubternal" típusai belsőre változtak

A ASP.NET Core 3.0-ban a ResponseCaching "pubternal" típusok módosultak internal.

Emellett a metódus részeként a szolgáltatások alapértelmezett implementációi IResponseCachingPolicyProviderIResponseCachingKeyProvider és a továbbiakban nem lesznek hozzáadva a AddResponseCaching szolgáltatásokhoz.

Módosítás leírása

A ASP.NET Core-ban a "pubternal" típusúak deklarálva public vannak, de a névtér utótagja .Internal. Bár ezek a típusok nyilvánosak, nem rendelkeznek támogatási szabályzattal, és kompatibilitástörő változásoknak vannak kitéve. Sajnos az ilyen típusok véletlen használata gyakori volt, ami a projektek kompatibilitástörő változásait eredményezte, és korlátozta a keretrendszer fenntartásának képességét.

Bevezetett verzió

3,0

Régi viselkedés

Ezek a típusok nyilvánosan láthatóak voltak, de nem támogatottak.

Új viselkedés

Ezek a típusok most már internal.

A változás oka

A internal hatókör jobban tükrözi a nem támogatott szabályzatot.

Az alkalmazás vagy tár által használt másolási típusok.

Kategória

ASP.NET Core

Érintett API-k

Adatvédelem: A DataProtection.Blobs új Azure Storage API-kat használ

Azure.Extensions.AspNetCore.DataProtection.Blobsaz Azure Storage-kódtáraktól függ. Ezek a kódtárak átnevezték a szerelvényeket, csomagokat és névtereket. A ASP.NET Core 3.0-tól Azure.Extensions.AspNetCore.DataProtection.Blobs kezdve az új Azure.Storage.előtagú API-kat és csomagokat használja.

Az Azure Storage API-kkal kapcsolatos kérdésekért használja a következőt https://github.com/Azure/azure-storage-net: . A probléma megvitatásához lásd: dotnet/aspnetcore#19570.

Bevezetett verzió

3,0

Régi viselkedés

A csomag a WindowsAzure.Storage NuGet-csomagra hivatkozott. A csomag a Microsoft.Azure.Storage.Blob NuGet-csomagra hivatkozik.

Új viselkedés

A csomag a Azure.Storage.Blob NuGet-csomagra hivatkozik.

A változás oka

Ez a módosítás lehetővé teszi Azure.Extensions.AspNetCore.DataProtection.Blobs a javasolt Azure Storage-csomagokra való migrálást.

Ha továbbra is a régebbi Azure Storage API-kat kell használnia a ASP.NET Core 3.0-val, adjon hozzá közvetlen függőséget a WindowsAzure.Storage vagy a Microsoft.Azure.Storage csomaghoz. Ez a csomag az új Azure.Storage API-k mellett telepíthető.

A frissítés sok esetben csak az using új névterek használatára vonatkozó utasítások módosításával jár:

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

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Üzemeltetés: Az AspNetCoreModule V1 el lett távolítva a Windows Hosting Bundle csomagból

A ASP.NET Core 3.0-tól kezdve a Windows Hosting Bundle nem tartalmazza az AspNetCoreModule (ANCM) V1-et.

Az ANCM V2 visszamenőlegesen kompatibilis az ANCM OutOfProcess szolgáltatással, és ASP.NET Core 3.0-alkalmazásokhoz ajánlott.

További információért lásd: dotnet/aspnetcore#7095.

Bevezetett verzió

3,0

Régi viselkedés

Az ANCM V1 a Windows hosting csomag része.

Új viselkedés

Az ANCM V1 nem része a Windows Hosting Bundle csomagnak.

A változás oka

Az ANCM V2 visszamenőlegesen kompatibilis az ANCM OutOfProcess szolgáltatással, és ASP.NET Core 3.0-alkalmazásokhoz ajánlott.

Használja az ANCM V2-t ASP.NET Core 3.0-alkalmazásokkal.

Ha ancm V1 szükséges, akkor a ASP.NET Core 2.1 vagy 2.2 Windows Hosting Bundle használatával telepíthető.

Ez a módosítás megszakítja ASP.NET Core 3.0-alkalmazásokat, amelyek:

  • Kifejezetten az ANCM V1 és a <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Egyéni web.config fájllal rendelkezik.<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Üzemeltetés: Az általános gazdagép korlátozza az indítási konstruktorinjektálást

Az általános gazdagép csak az osztálykonstruktorinjektáláshoz Startup támogatja az IHostEnvironment, IWebHostEnvironmentés IConfiguration. A használt WebHost alkalmazások nem változnak.

Módosítás leírása

A Core 3.0 ASP.NET előtt konstruktorinjektálás használható az Startup osztály konstruktorának tetszőleges típusaihoz. A ASP.NET Core 3.0-ban a webes verem vissza lett írva az általános gazdagéptárra. A módosítás a sablonok Program.cs fájljában látható:

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 Egy függőséginjektáló (DI) tárolót használ az alkalmazás létrehozásához. WebHost Két tárolót használ: egyet a gazdagéphez, egyet az alkalmazáshoz. Ennek eredményeképpen a konstruktor már nem támogatja az Startup egyéni szolgáltatásinjektálást. Csak IHostEnvironment, IWebHostEnvironmentés IConfiguration beadható. Ez a módosítás megakadályozza az olyan DI-problémákat, mint például egy egyszeri szolgáltatás duplikált létrehozása.

Bevezetett verzió

3,0

A változás oka

Ez a változás a webes veremnek az általános gazdagéptárra való replatformálásának következménye.

Szolgáltatások injektálása a Startup.Configure metódus-aláírásba. Példa:

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

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Üzemeltetés: A HTTPS-átirányítás engedélyezve van a folyamaton kívüli IIS-alkalmazásokhoz

A ASP.NET Core Modul (ANCM) 13.0.19218.0-s verziója az IIS folyamaton kívüli üzemeltetéséhez lehetővé teszi a meglévő HTTPS-átirányítási funkciót ASP.NET Core 3.0 és 2.2 alkalmazásokhoz.

További információért lásd: dotnet/AspNetCore#15243.

Bevezetett verzió

3,0

Régi viselkedés

A ASP.NET Core 2.1 projektsablon először a HTTPS köztes szoftveres metódusok ( például UseHttpsRedirection és UseHsts. A HTTPS-átirányítás engedélyezéséhez hozzá kellett adni a konfigurációt, mivel a fejlesztés alatt álló alkalmazások nem használják az alapértelmezett 443-as portot. A HTTP Strict Transport Security (HSTS) csak akkor aktív, ha a kérés már HTTPS-t használ. A Localhost alapértelmezés szerint ki van hagyva.

Új viselkedés

A ASP.NET Core 3.0-ban továbbfejlesztettük az IIS HTTPS-forgatókönyvet. A fejlesztéssel egy alkalmazás felderítheti a kiszolgáló HTTPS-portját, és UseHttpsRedirection alapértelmezés szerint dolgozhat. A folyamaton belüli összetevő a szolgáltatással IServerAddresses végzett portfelderítést, amely csak ASP.NET Core 3.0-alkalmazásokat érinti, mert a folyamatközi kódtár verziószámozott a keretrendszerrel. A folyamaton kívüli összetevő úgy módosult, hogy automatikusan hozzáadja a környezeti változót ASPNETCORE_HTTPS_PORT . Ez a változás ASP.NET Core 2.2- és 3.0-alkalmazásokat is érintett, mivel a folyamaton kívüli összetevő globálisan meg van osztva. ASP.NET Core 2.1-es alkalmazásokra nincs hatással, mert alapértelmezés szerint az ANCM korábbi verzióját használják.

Az előző viselkedés ASP.NET Core 3.0.1 és 3.1.0 Preview 3 verzióban módosult, hogy megfordítsa a ASP.NET Core 2.x viselkedésváltozását. Ezek a módosítások csak a folyamaton kívüli IIS-alkalmazásokat érintik.

A fentiekben leírtaknak megfelelően a ASP.NET Core 3.0.0 telepítésekor a köztes szoftver is aktiválva lett ASP.NET UseHttpsRedirection Core 2.x-alkalmazásokban. A Core 3.0.1 és a 3.1.0 Preview 3 ASP.NET AZ ANCM-ben módosítás történt, így a telepítésük már nem érinti ASP.NET Core 2.x-alkalmazásokat. A ASPNETCORE_HTTPS_PORT ASP.NET Core 3.0.0-s verziójában az ANCM által kitöltött környezeti változót a ASP.NET Core 3.0.1 és 3.1.0 Előzetes verzióban módosítottuk ASPNETCORE_ANCM_HTTPS_PORT . UseHttpsRedirection ezen kiadásokban is frissült, hogy megértse az új és a régi változókat is. ASP.NET Core 2.x nem frissül. Ennek eredményeképpen visszaáll az alapértelmezett letiltás korábbi viselkedésére.

A változás oka

Továbbfejlesztett ASP.NET Core 3.0 funkció.

Nincs szükség műveletre, ha azt szeretné, hogy minden ügyfél HTTPS-t használjon. Ha engedélyezni szeretné, hogy egyes ügyfelek HTTP-t használhassanak, hajtsa végre az alábbi lépések egyikét:

  • Távolítsa el a projekt Startup.Configure metódusára irányuló és UseHsts onnan érkező hívásokatUseHttpsRedirection, és telepítse újra az alkalmazást.

  • A web.config fájlban állítsa a ASPNETCORE_HTTPS_PORT környezeti változót üres sztringre. Ez a változás közvetlenül a kiszolgálón fordulhat elő az alkalmazás ismételt üzembe helyezése nélkül. Példa:

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

UseHttpsRedirection továbbra is a következő lehet:

  • Manuálisan aktiválva a ASP.NET Core 2.x-ben úgy, hogy a környezeti változót a ASPNETCORE_HTTPS_PORT megfelelő portszámra állítja (a legtöbb éles forgatókönyvben 443).
  • ASP.NET Core 3.x-ben inaktiválva üres sztringértékkel definiálva ASPNETCORE_ANCM_HTTPS_PORT . Ez az érték ugyanúgy van beállítva, mint az előző példában ASPNETCORE_HTTPS_PORT .

A ASP.NET Core 3.0.0-s alkalmazásokat futtató gépeknek telepíteniük kell a ASP.NET Core 3.0.1 futtatókörnyezetet a ASP.NET Core 3.1.0 Preview 3 ANCM telepítése előtt. Ez biztosítja, hogy UseHttpsRedirection a ASP.NET Core 3.0-alkalmazások továbbra is a várt módon működjenek.

A Azure-alkalmazás Service-ben az ANCM a futtatókörnyezettől eltérő ütemezésben üzemel globális jellege miatt. Az ANCM üzembe helyezése az Azure-ban történt ezekkel a módosításokkal ASP.NET Core 3.0.1 és 3.1.0 telepítése után.

Kategória

ASP.NET Core

Érintett API-k

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Üzemeltetés: Elavult és lecserélt IHostingEnvironment és IApplicationLifetime típusok

Új típusok lettek bevezetve a meglévők IHostingEnvironment és IApplicationLifetime a típusok helyére.

Bevezetett verzió

3,0

Régi viselkedés

Két különböző IHostingEnvironment és IApplicationLifetime típusú volt az és Microsoft.AspNetCore.Hostinga Microsoft.Extensions.Hosting .

Új viselkedés

A régi típusok elavultként lettek megjelölve, és új típusok lettek lecserélve.

A változás oka

Amikor Microsoft.Extensions.Hosting a ASP.NET Core 2.1-ben bevezették, bizonyos típusokat a rendszer a IHostingEnvironmentIApplicationLifetime következőből Microsoft.AspNetCore.Hostingmásolt ki. Egyes ASP.NET Core 3.0-s módosítások miatt az alkalmazások a névtereket és Microsoft.AspNetCore.Hosting a Microsoft.Extensions.Hosting névtereket is tartalmazzák. Az ismétlődő típusok bármilyen használata "félreérthető hivatkozás" fordítóhibát okoz, ha mindkét névtérre hivatkozik.

A régi típusok minden használatát lecserélte az újonnan bevezetett típusokra az alábbiak szerint:

Elavult típusok (figyelmeztetés):

Új típusok:

Az új IHostEnvironmentIsDevelopment és IsProduction a bővítménymetelyek a Microsoft.Extensions.Hosting névtérben találhatók. Előfordulhat, hogy ezt a névteret hozzá kell adni a projekthez.

Kategória

ASP.NET Core

Érintett API-k

Üzemeltetés: Az ObjectPoolProvider el lett távolítva a WebHostBuilder-függőségekből

Annak részeként, hogy a ASP.NET Core nagyobb fizetést biztosít a játékért, a rendszer eltávolította a ObjectPoolProvider fő függőségi csoportból. A függőben lévő ObjectPoolProvider egyes összetevők most maguk is hozzáadják őket.

További információért lásd: dotnet/aspnetcore#5944.

Bevezetett verzió

3,0

Régi viselkedés

WebHostBuilderalapértelmezés szerint a DI-tárolóban.ObjectPoolProvider

Új viselkedés

WebHostBuilder a DI-tárolóban alapértelmezés szerint nem biztosít ObjectPoolProvider .

A változás oka

Ez a módosítás azért történt, hogy a ASP.NET Core több fizetést biztosítson a játékért.

Ha az összetevő megköveteli ObjectPoolProvider, azt hozzá kell adni a függőségeihez a IServiceCollectionsegítségével.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

HTTP: DefaultHttpContext bővíthetőség eltávolítva

Az ASP.NET Core 3.0 teljesítménybeli fejlesztéseinek részeként a bővíthetőség el DefaultHttpContext lett távolítva. Az osztály most már sealed. További információ: dotnet/aspnetcore#6504.

Ha az egységtesztek használják Mock<DefaultHttpContext>, használja Mock<HttpContext> vagy new DefaultHttpContext() helyette.

További információért lásd: dotnet/aspnetcore#6534.

Bevezetett verzió

3,0

Régi viselkedés

Az osztályok származhatnak a .-ból DefaultHttpContext.

Új viselkedés

Az osztályok nem származhatnak a forrásból DefaultHttpContext.

A változás oka

A bővíthetőség kezdetben lehetővé tette a HttpContextkészletezést, de szükségtelen összetettséget vezetett be, és akadályozta az egyéb optimalizálásokat.

Ha az egységteszteken dolgozik Mock<DefaultHttpContext> , kezdje el használni Mock<HttpContext> .

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: A HeaderNames állandók statikus írásvédettre változtak

A ASP.NET Core 3.0 5 előzetes verziójától Microsoft.Net.Http.Headers.HeaderNames kezdve a mezők a következőre conststatic readonlyváltoztak: .

További információért lásd: dotnet/aspnetcore#9514.

Bevezetett verzió

3,0

Régi viselkedés

Ezek a mezők korábban .const

Új viselkedés

Ezek a mezők most már static readonly.

A változás oka

A változás:

  • Megakadályozza, hogy az értékek beágyazódhassanak a szerelvényhatárokba, és szükség esetén értékkorrekciókat is lehetővé tesz.
  • Gyorsabb referencia-egyenlőségi ellenőrzéseket tesz lehetővé.

Újrafordítás a 3.0-ra. Az alábbi mezőket használó forráskód már nem használható:

  • Attribútumargumentumként
  • Utasításként caseswitch
  • Másik definiálásakor const

A kompatibilitástörő változás megkerüléséhez váltson ön által definiált fejlécnév-állandókra vagy sztringkonstansokra.

Kategória

ASP.NET Core

Érintett API-k

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Válasz törzsinfrastruktúra változásai

Módosult a HTTP-válasz törzsét tartalmazó infrastruktúra. Ha közvetlenül használja HttpResponse , nem kell módosítania a kódokat. Olvassa el a további tudnivalókat, ha sortörést, cserét HttpResponse.Body vagy hozzáférést keres HttpContext.Features.

Bevezetett verzió

3,0

Régi viselkedés

A HTTP-válasz törzséhez három API volt társítva:

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

Új viselkedés

Ha lecseréli a elemet HttpResponse.Body, az a teljes IHttpResponseBodyFeature helyére egy burkolót ad az adott stream körül, és StreamResponseBodyFeature az összes várt API alapértelmezett implementációit biztosítja. Az eredeti stream visszaállítása visszaállítja ezt a módosítást.

A változás oka

A motiváció az, hogy a válasz törzs API-jait egyetlen új funkciófelületbe egyesítse.

Használja IHttpResponseBodyFeature a korábban használt IHttpResponseFeature.Body, IHttpSendFileFeaturevagy IHttpBufferingFeature.

Kategória

ASP.NET Core

Érintett API-k

SameSite a cookie-k egyik lehetősége, amely segíthet enyhíteni a helyek közötti kérelemhamisítási (CSRF-) támadásokat. A beállítás kezdeti bevezetésekor a rendszer inkonzisztens alapértelmezett értékeket használt a különböző ASP.NET Core API-kban. Az inkonzisztencia zavaros eredményeket eredményezett. A Core 3.0 ASP.NET ezek az alapértelmezett értékek jobban igazodnak egymáshoz. Ezt a funkciót összetevőnként kell választania.

Bevezetett verzió

3,0

Régi viselkedés

A hasonló ASP.NET Core API-k eltérő alapértelmezett SameSiteMode értékeket használtak. Példa az inkonzisztencia látható HttpResponse.Cookies.Append(String, String) , és HttpResponse.Cookies.Append(String, String, CookieOptions), amely alapértelmezés szerint SameSiteMode.None és SameSiteMode.Lax, illetve.

Új viselkedés

Az összes érintett API alapértelmezés szerint a következő.SameSiteMode.None

A változás oka

Az alapértelmezett érték úgy módosult, hogy egy bejelentkezési funkciót hozzon SameSite létre.

Minden olyan összetevőnek, amely cookie-kat bocsát ki, el kell döntenie, hogy megfelelő-e SameSite a forgatókönyveihez. Tekintse át az érintett API-k használatát, és szükség szerint konfigurálja SameSite újra.

Kategória

ASP.NET Core

Érintett API-k

HTTP: A szinkron I/O le van tiltva minden kiszolgálón

A ASP.NET Core 3.0-tól kezdve a szinkron kiszolgálóműveletek alapértelmezés szerint le vannak tiltva.

Módosítás leírása

AllowSynchronousIO az egyes kiszolgálókon olyan beállítás, amely engedélyezi vagy letiltja a szinkron IO API-kat, például HttpRequest.Body.Reada , HttpResponse.Body.Writeés Stream.Flush. Ezek az API-k már régóta a szálak éhezésének és az alkalmazások lefagyásának forrása. A ASP.NET Core 3.0 3. előzetes verziójától kezdve ezek a szinkron műveletek alapértelmezés szerint le vannak tiltva.

Érintett kiszolgálók:

  • Kestrel
  • HttpSys
  • Folyamatban lévő IIS
  • TestServer

A következőhöz hasonló hibák várhatók:

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

Minden kiszolgáló rendelkezik egy AllowSynchronousIO olyan beállítással, amely vezérli ezt a viselkedést, és az alapértelmezett érték most az falseösszes kiszolgálón.

A viselkedés kérésenként felülbírált is lehet ideiglenes megoldásként. Példa:

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

Ha problémát tapasztal egy TextWriter vagy egy másik streamben, amely szinkron API-t Disposehív meg, hívja inkább az új DisposeAsync API-t.

További információért lásd: dotnet/aspnetcore#7644.

Bevezetett verzió

3,0

Régi viselkedés

HttpRequest.Body.Read, HttpResponse.Body.Writeés Stream.Flush alapértelmezés szerint engedélyezve voltak.

Új viselkedés

Ezek a szinkron API-k alapértelmezés szerint nem engedélyezettek:

A következőhöz hasonló hibák várhatók:

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

A változás oka

Ezek a szinkron API-k már régóta a szálak éhezésének és az alkalmazások lefagyásának forrása. A ASP.NET Core 3.0 3. előzetes verziójától kezdve a szinkron műveletek alapértelmezés szerint le vannak tiltva.

Használja a metódusok aszinkron verzióit. A viselkedés kérésenként felülbírált is lehet ideiglenes megoldásként.

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

Kategória

ASP.NET Core

Érintett API-k

Identitás: Az AddDefaultUI metódus túlterhelése el lett távolítva

A ASP.NET Core 3.0-tól kezdve az IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) metódus túlterhelése már nem létezik.

Bevezetett verzió

3,0

A változás oka

Ez a változás a statikus webes eszközök funkció bevezetésének eredménye.

Hívás IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) a túlterhelés helyett, amely két argumentumot vesz igénybe. Ha a Bootstrap 3-at használja, adja hozzá a következő sort a projektfájl egyik <PropertyGroup> eleméhez is:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategória

ASP.NET Core

Érintett API-k

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identitás: A felhasználói felület alapértelmezett Bootstrap-verziója módosult

A ASP.NET Core 3.0-tól kezdődően az identitás felhasználói felülete alapértelmezés szerint a Bootstrap 4-es verziójának használatát használja.

Bevezetett verzió

3,0

Régi viselkedés

A services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metódushívás ugyanaz volt, mint a services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Új viselkedés

A services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metódushívás ugyanaz, mint a services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

A változás oka

A Bootstrap 4 ASP.NET Core 3.0-s időkeret alatt jelent meg.

Ez a változás akkor érinti, ha az alapértelmezett identitáskezelő felületet használja, és hozzáadta az alábbi példában Startup.ConfigureServices látható módon:

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

Válasszon a következő lehetőségek közül:

  • Migrálja az alkalmazást a Bootstrap 4 használatára a migrálási útmutatójuk használatával.

  • Frissítés Startup.ConfigureServices a Bootstrap 3 használatának kényszerítéséhez. Példa:

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

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Identitás: A SignInAsync kivételt jelez a hitelesítés nélküli identitás esetében

Alapértelmezés szerint kivételt jelent az olyan tagok/ identitások esetében, SignInAsync amelyekben IsAuthenticated a rendszer szerepel false.

Bevezetett verzió

3,0

Régi viselkedés

SignInAsyncelfogad minden tagot/ identitást, beleértve azokat az identitásokat is, amelyekben IsAuthenticated az .false

Új viselkedés

Alapértelmezés szerint kivételt jelent az olyan tagok/ identitások esetében, SignInAsync amelyekben IsAuthenticated a rendszer szerepel false. Van egy új jelző, amely letiltja ezt a viselkedést, de az alapértelmezett viselkedés megváltozott.

A változás oka

A régi viselkedés azért volt problémás, mert a rendszer alapértelmezés szerint elutasította [Authorize] / RequireAuthenticatedUser()ezeket a tagokat.

A ASP.NET Core 3.0 6 előzetes verziójában alapértelmezés szerint van egy RequireAuthenticatedSignIn jelző AuthenticationOptionstrue . Állítsa be ezt a jelzőt false a régi viselkedés visszaállításához.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Identitás: A SignInManager konstruktor új paramétert fogad el

A ASP.NET Core 3.0-tól kezdve egy új IUserConfirmation<TUser> paraméter lett hozzáadva a SignInManager konstruktorhoz. További információ: dotnet/aspnetcore#8356.

Bevezetett verzió

3,0

A változás oka

A változás motivációja az volt, hogy támogatást adjon az új e-mail/ megerősítő folyamatokhoz az Identitásban.

Ha manuálisan hoz létre egy SignInManager, adjon meg egy implementációt IUserConfirmation , vagy ragadjon meg egyet a függőséginjektálásból.

Kategória

ASP.NET Core

Érintett API-k

SignInManager<TUser>

Identitás: A felhasználói felület statikus webes objektumok funkciót használ

ASP.NET Core 3.0 bevezetett egy statikus webes objektum funkciót, és az Identity felhasználói felülete elfogadta.

Módosítás leírása

Az Identitás felhasználói felülete a statikus webes objektumok funkciójának bevezetése miatt:

  • A keretrendszer kiválasztása a IdentityUIFrameworkVersion projektfájlban lévő tulajdonság használatával történik.
  • A Bootstrap 4 az identitás felhasználói felületének alapértelmezett felhasználói felületi keretrendszere. A Bootstrap 3 elérte az élettartam végét, ezért érdemes megfontolni a támogatott verzióra való migrálást.

Bevezetett verzió

3,0

Régi viselkedés

Az identitás felhasználói felületének alapértelmezett felhasználói felületi keretrendszere a Bootstrap 3 volt. A felhasználói felület keretrendszere paraméterrel konfigurálható a metódushíváshoz.AddDefaultUIStartup.ConfigureServices

Új viselkedés

Az identitás felhasználói felületének alapértelmezett felhasználói felületi keretrendszere a Bootstrap 4. A felhasználói felület keretrendszerét a metódushívás helyett a AddDefaultUI projektfájlban kell konfigurálni.

A változás oka

A statikus webes eszközök funkciójának bevezetéséhez a felhasználói felület keretrendszerének konfigurációja az MSBuildre való áttéréshez szükséges. Az a döntés, hogy melyik keretrendszer beágyazása buildelési döntés, nem futtatókörnyezeti döntés.

Tekintse át a webhely felhasználói felületét, és győződjön meg arról, hogy az új Bootstrap 4-összetevők kompatibilisek. Szükség esetén az IdentityUIFrameworkVersion MSBuild tulajdonság használatával térjen vissza a Bootstrap 3-ra. Adja hozzá a tulajdonságot a projektfájl egyik <PropertyGroup> eleméhez:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategória

ASP.NET Core

Érintett API-k

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Csatlakozás ion adapterek el lettek távolítva

A "pubternal" API-k publicáthelyezésének részeként az egyik IConnectionAdapter fogalom el lett távolítva a Kestrelből. Csatlakozás ion-adapterek cseréje kapcsolati köztes szoftverre történik (hasonló a HTTP köztes szoftverhez a ASP.NET Core-folyamatban, de alacsonyabb szintű kapcsolatok esetén). A HTTPS és a kapcsolatnaplózás átkerült a kapcsolati adapterekről a kapcsolat köztes szoftverére. Ezeknek a bővítménymetenek továbbra is zökkenőmentesen kell működniük, de a megvalósítás részletei megváltoztak.

További információ: dotnet/aspnetcore#11412. További információért lásd: dotnet/aspnetcore#11475.

Bevezetett verzió

3,0

Régi viselkedés

A Kestrel bővíthetőségi IConnectionAdapterösszetevői a .

Új viselkedés

A Kestrel bővíthetőségi összetevői köztes szoftverként jönnek létre.

A változás oka

A módosítás célja, hogy rugalmasabb bővíthetőségi architektúrát biztosítson.

Alakítsa át az összes implementációt IConnectionAdapter az új köztes szoftverminta használatára az itt látható módon.

Kategória

ASP.NET Core

Érintett API-k

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

Kestrel: Üres HTTPS-szerelvény el lett távolítva

A szerelvény Microsoft.AspNetCore.Server.Kestrel.Https el lett távolítva.

Bevezetett verzió

3,0

A változás oka

A ASP.NET Core 2.1-ben a tartalom Microsoft.AspNetCore.Server.Kestrel.Https át lett helyezve a következőre Microsoft.AspNetCore.Server.Kestrel.Core: . Ezt a módosítást attribútumok használatával [TypeForwardedTo] , nem feltörhető módon hajtották végre.

  • A 2.0-ra hivatkozó Microsoft.AspNetCore.Server.Kestrel.Https kódtáraknak az összes ASP.NET Core-függőséget 2.1-s vagy újabb verzióra kell frissítenie. Ellenkező esetben megszakadhatnak, ha betöltenek egy ASP.NET Core 3.0-alkalmazásba.
  • Az ASP.NET Core 2.1-et és újabb verziót célzó alkalmazásoknak és kódtáraknak el kell távolítaniuk a Microsoft.AspNetCore.Server.Kestrel.Https NuGet-csomagra mutató közvetlen hivatkozásokat.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Kestrel: Új gyűjteménybe áthelyezett pótkocsifejlécek kérése

A korábbi verziókban a Kestrel HTTP/1.1-beli, darabolt pótkocsifejléceket adott hozzá a kérelemfejlécek gyűjteményéhez, amikor a kérelem törzsét a végéig felolvasták. Ez a viselkedés aggályokat okozott a fejlécek és a pótkocsik közötti kétértelműség miatt. Úgy döntöttek, hogy áthelyezik a pótkocsikat egy új gyűjteménybe.

A HTTP/2 kérelem-pótkocsik nem voltak elérhetők ASP.NET Core 2.2-ben, de most már az ASP.NET Core 3.0 új gyűjteményében is elérhetők.

Új kérelemkiterjesztési módszerek lettek hozzáadva ezeknek a pótkocsiknak a eléréséhez.

A HTTP/1.1 pótkocsik a teljes kérelemtörzs elolvasása után érhetők el.

A HTTP/2-pótkocsik az ügyféltől való beérkezés után érhetők el. Az ügyfél csak akkor küldi el a pótkocsikat, ha a teljes kérelemtörzset legalább puffereli a kiszolgáló. Előfordulhat, hogy a pufferterület felszabadításához be kell olvasnia a kérés törzsét. A pótkocsik mindig elérhetők, ha a kérelem törzsét a végéig olvassa el. A pótkocsik a test végét jelölik.

Bevezetett verzió

3,0

Régi viselkedés

A kérelem-utánfutó fejlécei hozzá lesznek adva a HttpRequest.Headers gyűjteményhez.

Új viselkedés

A kérelem-pótkocsi fejlécei nem szerepelnek a HttpRequest.Headers gyűjteményben. A következő bővítménymetelyeket HttpRequest használva érheti el őket:

  • GetDeclaredTrailers() - Lekéri a "Trailer" kérés fejlécét, amely felsorolja, hogy mely pótkocsik várhatók a törzs után.
  • SupportsTrailers() – Jelzi, hogy a kérelem támogatja-e a pótkocsi fejléceinek fogadását.
  • CheckTrailersAvailable() - Meghatározza, hogy a kérelem támogatja-e a pótkocsikat, és hogy elérhetők-e olvasásra.
  • GetTrailer(string trailerName) – Lekéri a kért záró fejlécet a válaszból.

A változás oka

A pótkocsik kulcsfontosságú funkciók az olyan helyzetekben, mint a gRPC. A pótkocsik egyesítése a fejlécek kéréséhez zavaró volt a felhasználók számára.

A pótkocsival kapcsolatos bővítménymetszeti módszereket HttpRequest használva érheti el a pótkocsikat.

Kategória

ASP.NET Core

Érintett API-k

HttpRequest.Headers

Kestrel: A közlekedési absztrakciók el lettek távolítva és nyilvánossá lettek

A "pubternal" API-któl való eltávolodás részeként a Kestrel átviteli réteg API-k nyilvános felületként jelennek meg a Microsoft.AspNetCore.Connections.Abstractions könyvtárban.

Bevezetett verzió

3,0

Régi viselkedés

  • A tárban Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions közlekedéssel kapcsolatos absztrakciók érhetők el.
  • A ListenOptions.NoDelay tulajdonság elérhető volt.

Új viselkedés

  • A IConnectionListener kódtárban bevezettük az Microsoft.AspNetCore.Connections.Abstractions interfészt, hogy elérhetővé tegye a leggyakrabban használt funkciókat a ...Transport.Abstractions tárból.
  • Ez NoDelay már elérhető a szállítási lehetőségek (LibuvTransportOptions és SocketTransportOptions).
  • SchedulingMode már nem érhető el.

A változás oka

ASP.NET Core 3.0 elmozdult a "pubternal" API-któl.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Honosítás: ResourceManagerWithCultureStringLocalizer és WithCulture megjelölt elavult

A ResourceManagerWithCultureStringLocalizer osztály és a WithCulture felületi tag gyakran összetéveszthető a honosítás felhasználói számára, különösen a saját IStringLocalizer megvalósítás létrehozásakor. Ezek az elemek azt a benyomást keltik a felhasználóban, hogy egy IStringLocalizer példány "nyelvenkénti, erőforrásonkénti". A valóságban a példányoknak csak "erőforrásonként" kell lenniük. A keresett nyelvet a CultureInfo.CurrentUICulture végrehajtási időpont határozza meg. A félreértések forrása érdekében az API-k elavultként lettek megjelölve ASP.NET Core 3.0 Preview 3-as verziójában. Az API-k egy későbbi kiadásban lesznek eltávolítva.

A környezetről lásd: dotnet/aspnetcore#3324. További információért lásd: dotnet/aspnetcore#7756.

Bevezetett verzió

3,0

Régi viselkedés

A metódusok nincsenek megjelölve .Obsolete

Új viselkedés

A metódusok meg vannak jelölve Obsolete.

A változás oka

Az API-k nem ajánlott használati esetet jelentettek. Zavart okozott a honosítás tervezése.

A javaslat inkább a használat ResourceManagerStringLocalizer . Hagyja, hogy a kultúra legyen beállítva a CurrentCulture. Ha ez nem lehetőség, hozza létre és használja a ResourceManagerWithCultureStringLocalizer egy példányát.

Kategória

ASP.NET Core

Érintett API-k

Naplózás: Belső hibakeresési naplóosztály

A Core 3.0 DebugLoggerASP.NET előtt a hozzáférési módosító a .public A ASP.NET Core 3.0-ban a hozzáférés-módosító a következőre internalváltozott: .

Bevezetett verzió

3,0

A változás oka

A módosítás a következőre történik:

  • Konzisztenciának kényszerítése más naplózási implementációkkal, például ConsoleLogger.
  • Csökkentse az API felületét.

A bővítménymetódus használatával engedélyezheti a AddDebugILoggingBuilder hibakeresési naplózást. DebugLoggerProvider abban az esetben is public , ha a szolgáltatást manuálisan kell regisztrálni.

Kategória

ASP.NET Core

Érintett API-k

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: A vezérlő műveleti neveiből levágott Async utótag

A dotnet/aspnetcore#4849 címzés részeként ASP.NET Core MVC alapértelmezés szerint levágja a műveletnevek utótagjátAsync. A ASP.NET Core 3.0-tól kezdve ez a változás mind az útválasztásra, mind a kapcsolatgenerálásra hatással van.

Bevezetett verzió

3,0

Régi viselkedés

Vegye figyelembe a következő ASP.NET Core MVC-vezérlőt:

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

A művelet a következővel Product/ListAsyncirányítható: . A csatolás létrehozásához meg kell adni az Async utótagot. Példa:

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

Új viselkedés

A ASP.NET Core 3.0-ban a művelet a következővel érhető el Product/List: . A hivatkozásgenerálási kódnak kihagynia kell az Async utótagot. Példa:

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

Ez a módosítás nem érinti az [ActionName] attribútummal megadott neveket. Az új viselkedés letiltható a következő beállítással MvcOptions.SuppressAsyncSuffixInActionNamesfalseStartup.ConfigureServices:

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

A változás oka

Konvenció szerint az aszinkron .NET-metódusok utótaggal Asyncvannak elvégzve. Ha azonban egy metódus MVC-műveletet határoz meg, nem kívánatos az Async utótag használata.

Ha az alkalmazás a név utótagját Async megőrző MVC-műveletektől függ, válasszon az alábbi megoldások közül:

  • Az attribútummal [ActionName] megőrizhető az eredeti név.
  • Tiltsa le az átnevezést teljes egészében a következő beállítással MvcOptions.SuppressAsyncSuffixInActionNamesfalseStartup.ConfigureServices:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

MVC: JsonResult a Microsoft.AspNetCore.Mvc.Core-ba költözött

JsonResult átkerült a Microsoft.AspNetCore.Mvc.Core szerelvénybe. Ez a típus a Microsoft.AspNetCore.Mvc.Formatters.Json fájlban volt definiálva. A rendszer hozzáad egy szerelvényszintű [TypeForwardedTo] attribútumot a probléma megoldásához Microsoft.AspNetCore.Mvc.Formatters.Json a felhasználók többsége számára. A külső kódtárakat használó alkalmazások problémákba ütközhetnek.

Bevezetett verzió

3.0 – 6. előzetes verzió

Régi viselkedés

Egy 2.2-alapú kódtárat használó alkalmazás sikeresen buildel.

Új viselkedés

A 2.2-alapú kódtárat használó alkalmazások fordítása sikertelen. A következő szövegvariációt tartalmazó hiba jelenik meg:

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'

Ilyen problémára példa: dotnet/aspnetcore#7220.

A változás oka

Platformszintű változások a ASP.NET Core összetételében az aspnet/Announcements#325 szakaszban leírtak szerint.

Előfordulhat, hogy a 2.2-es verzióra Microsoft.AspNetCore.Mvc.Formatters.Json lefordított kódtáraknak újra kell fordítaniuk a problémát az összes felhasználó számára. Ha ez jelentkezik, forduljon a tár szerzőéhez. Kérje meg a kódtár újrafordítását ASP.NET Core 3.0-s verziójának megcélzásához.

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Az előre összeállított eszköz elavult

A ASP.NET Core 1.1-ben bevezették az Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (MVC előkompilációs eszköz) csomagot, amely támogatja a Razor-fájlok (.cshtml-fájlok ) közzétételi idő szerinti fordítását. A ASP.NET Core 2.1-ben bevezették a Razor SDK-t , hogy az előre összeállított eszköz funkcióival bővüljön. A Razor SDK támogatja a Razor-fájlok buildelési és közzétételi idejű fordítását. Az SDK ellenőrzi a .cshtml-fájlok helyességét a buildeléskor, miközben az alkalmazás indítási ideje javul. A Razor SDK alapértelmezés szerint be van kapcsolva, és nincs szükség kézmozdulatra a használat megkezdéséhez.

A ASP.NET Core 3.0-ban a ASP.NET Core 1.1-korÚ MVC előkompilációs eszköz el lett távolítva. A korábbi csomagverziók továbbra is fontos hiba- és biztonsági javításokat kapnak a javítás kiadásában.

Bevezetett verzió

3,0

Régi viselkedés

A Microsoft.AspNetCore.Mvc.Razor.ViewCompilation csomag az MVC Razor-nézetek előzetes fordítására szolgál.

Új viselkedés

A Razor SDK natív módon támogatja ezt a funkciót. A Microsoft.AspNetCore.Mvc.Razor.ViewCompilation csomag már nem frissül.

A változás oka

A Razor SDK további funkciókat biztosít, és ellenőrzi a .cshtml-fájlok helyességét a buildeléskor. Az SDK emellett javítja az alkalmazások indítási idejét.

A ASP.NET Core 2.1 vagy újabb verzió felhasználói számára frissítsen a Razor SDK natív támogatásának használatára. Ha a hibák vagy hiányzó funkciók megakadályozzák a Razor SDK-ba való migrálást, nyisson meg egy problémát a dotnet/aspnetcore webhelyen.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

MVC: A "Pubternal" típusúak belsőre változtak

A ASP.NET Core 3.0-ban az MVC összes "pubternal" típusát egy támogatott névtérre frissítettük public , vagy internal szükség szerint.

Módosítás leírása

A ASP.NET Core-ban a "pubternal" típusok deklarálva public vannak, de - .Internalutótaggal rendelkező névtérben találhatók. Bár ezek a típusok publicnem rendelkeznek támogatási szabályzattal, és kompatibilitástörő változásoknak vannak kitéve. Sajnos az ilyen típusok véletlen használata gyakori volt, ami a projektek kompatibilitástörő változásait eredményezte, és korlátozta a keretrendszer fenntartásának képességét.

Bevezetett verzió

3,0

Régi viselkedés

Az MVC egyes típusai csak névtérben .Internal voltakpublic. Ezek a típusok nem voltak támogatási szabályzattal, és kompatibilitástörő változásoknak voltak kitéve.

Új viselkedés

Az összes ilyen típus frissítve van, hogy egy támogatott névtérben legyenpublic, vagy megjelölve legyen.internal

A változás oka

A "pubternal" típusúak véletlen használata gyakori volt, ami a projektek kompatibilitástörő változásait eredményezte, és korlátozta a keretrendszer fenntartásának képességét.

Ha olyan típusokat használ, amelyek valóban valódivá public váltak, és át lettek helyezve egy új, támogatott névtérbe, frissítse a hivatkozásokat az új névtereknek megfelelően.

Ha olyan típusokat használ, amelyek megjelölése internalmeg lett jelölve, alternatívát kell találnia. A korábban "pubternális" típusokat soha nem támogatták nyilvános használatra. Ha bizonyos névterek kritikus fontosságúak az alkalmazások számára, küldjön egy problémát a dotnet/aspnetcore webhelyen. Megfontolhatók a kért típusok public.

Kategória

ASP.NET Core

Érintett API-k

Ez a módosítás a következő névterek típusait tartalmazza:

  • 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: A webes API-kompatibilitási shim el lett távolítva

A ASP.NET Core 3.0-tól kezdve a Microsoft.AspNetCore.Mvc.WebApiCompatShim csomag már nem érhető el.

Módosítás leírása

A Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) csomag részleges kompatibilitást biztosít ASP.NET Core-ban a ASP.NET 4.x Web API 2-vel, hogy egyszerűbb legyen a meglévő Webes API-implementációk áttelepítése ASP.NET Core-ba. A WebApiCompatShim-et használó alkalmazások azonban nem élvezik az API-val kapcsolatos funkciók használatát a legutóbbi ASP.NET Core-kiadásokban. Ilyen funkciók például a továbbfejlesztett Open API-specifikációk létrehozása, a szabványosított hibakezelés és az ügyfélkódok létrehozása. A 3.0-s API-erőfeszítések jobb összpontosítása érdekében a WebApiCompatShim el lett távolítva. A WebApiCompatShim-et használó meglévő alkalmazásoknak az újabb [ApiController] modellbe kell migrálniuk.

Bevezetett verzió

3,0

A változás oka

A Webes API kompatibilitási shim egy migrálási eszköz volt. Korlátozza a felhasználók hozzáférését az ASP.NET Core-ban hozzáadott új funkciókhoz.

Távolítsa el a shim használatát, és migráljon közvetlenül a ASP.NET Core hasonló funkcióira.

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API el lett távolítva

Az RazorTemplateEngine API el lett távolítva, és lecserélődött a következőre Microsoft.AspNetCore.Razor.Language.RazorProjectEngine: .

További információért tekintse meg a GitHub dotnet/aspnetcore#25215-ös problémáját.

Bevezetett verzió

3,0

Régi viselkedés

Sablonmotor hozható létre és használható a Razor-fájlok kódjának elemzéséhez és létrehozásához.

Új viselkedés

RazorProjectEngine létrehozható, és ugyanazokat az információkat adja meg, mint RazorTemplateEngine a Razor-fájlok elemzéséhez és létrehozásához. RazorProjectEngine emellett további konfigurációs szinteket is biztosít.

A változás oka

RazorTemplateEngine túl szorosan kapcsolódik a meglévő implementációkhoz. Ez a szoros összekapcsolás további kérdéseket eredményezett a Razor-elemzési/létrehozási folyamat megfelelő konfigurálásakor.

Használja RazorProjectEngine ahelyett, hogy RazorTemplateEngine. Vegye figyelembe az alábbi példákat.

A RazorProjectEngine létrehozása és konfigurálása
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
        });
Kód létrehozása Razor-fájlhoz
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();

Kategória

ASP.NET Core

Érintett API-k

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Futtatókörnyezet fordítása csomagba helyezve

A Razor-nézetek futásidejű fordításának támogatása és a Razor Pages külön csomagba került.

Bevezetett verzió

3,0

Régi viselkedés

A futtatókörnyezet fordítása további csomagok nélkül érhető el.

Új viselkedés

A funkció át lett helyezve a Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation csomagba.

Az alábbi API-k korábban a futtatókörnyezet fordításának Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions támogatásához voltak elérhetők. Az API-k mostantól elérhetők a következőn keresztül: Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders most MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences most MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Emellett Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange el lett távolítva. A fájlmódosítások újrafordítása alapértelmezés szerint engedélyezve van a Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation csomagra való hivatkozással.

A változás oka

Ez a módosítás szükséges volt a Roslyn ASP.NET Core megosztott keretrendszer-függőségének eltávolításához.

A futtatókörnyezeti fordítást vagy Razor-fájlok újrafordítását igénylő alkalmazásoknak a következő lépéseket kell elvégezniük:

  1. Adjon hozzá egy hivatkozást a Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation csomaghoz.

  2. Frissítse a projekt metódusát Startup.ConfigureServices úgy, hogy az tartalmazza a hívásokat AddRazorRuntimeCompilation. Példa:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategória

ASP.NET Core

Érintett API-k

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Munkamenet állapota: Elavult API-k el lettek távolítva

A munkamenet-cookie-k konfigurálására szolgáló elavult API-k el lettek távolítva. További információ: aspnet/Announcements#257.

Bevezetett verzió

3,0

A változás oka

Ez a módosítás konzisztenciát kényszerít ki az API-k között a cookie-kat használó funkciók konfigurálásához.

Migrálja az eltávolított API-k használatát az újabb csereikre. Tekintse meg a következő példát a következőben 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;
    });
}

Kategória

ASP.NET Core

Érintett API-k

Megosztott keretrendszer: A szerelvények el lettek távolítva Microsoft.AspNetCore.App

A ASP.NET Core 3.0-tól kezdődően a ASP.NET Core megosztott keretrendszere (Microsoft.AspNetCore.App) csak a Microsoft által teljesen kifejlesztett, támogatott és használható belső szerelvényeket tartalmazza.

Módosítás leírása

Gondoljon úgy a változásra, mint a ASP.NET Core "platform" határainak újradefiniálására. A megosztott keretrendszert bárki létrehozhatja a GitHubon keresztül, és továbbra is biztosítja a .NET Core megosztott keretrendszerek meglévő előnyeit az alkalmazásai számára. Bizonyos előnyök közé tartozik a kisebb üzembehelyezési méret, a központosított javítás és a gyorsabb indítási idő.

A módosítás részeként néhány jelentős kompatibilitástörő változás is bevezetésével jár.Microsoft.AspNetCore.App

Bevezetett verzió

3,0

Régi viselkedés

A projektfájl egyik <PackageReference> elemével hivatkozott Microsoft.AspNetCore.App projektek.

Ezenkívül Microsoft.AspNetCore.App a következő alösszetevőket tartalmazta:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (szerelvények előtaggal Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Új viselkedés

A hivatkozás már Microsoft.AspNetCore.App nem igényel egy <PackageReference> elemet a projektfájlban. A .NET Core SDK egy új, úgynevezett <FrameworkReference>elemet támogat, amely felváltja <PackageReference>a .NET Core SDK használatát.

További információ: dotnet/aspnetcore#3612.

Az Entity Framework Core NuGet-csomagokként hajóz. Ez a módosítás igazodik a szállítási modellhez a .NET összes többi adatelérési kódtárához. Az Entity Framework Core a legegyszerűbb út az innováció folytatásához, miközben támogatja a különböző .NET-platformokat. Az Entity Framework Core áthelyezése a megosztott keretrendszerből nincs hatással a Microsoft által kifejlesztett, támogatott és használható kódtárak állapotára. A .NET Core támogatási szabályzata továbbra is kiterjed rá.

Json.NET és az Entity Framework Core továbbra is együttműködik ASP.NET Core-val. Ezek azonban nem lesznek belefoglalva a megosztott keretrendszerbe.

További információ: A JSON jövője a .NET Core 3.0-ban. Tekintse meg a megosztott keretrendszerből eltávolított bináris fájlok teljes listáját is.

A változás oka

Ez a módosítás leegyszerűsíti Microsoft.AspNetCore.App a NuGet-csomagok és a megosztott keretrendszerek közötti duplikációt, és csökkenti a duplikációt.

A változás motivációjára vonatkozó további információkért tekintse meg ezt a blogbejegyzést.

A ASP.NET Core 3.0-tól kezdve már nem szükséges, hogy a projektek NuGet-csomagokban használják fel a Microsoft.AspNetCore.App szerelvényeket. A ASP.NET Core megosztott keretrendszer célzásának és használatának egyszerűsítése érdekében a ASP.NET Core 1.0 óta szállított NuGet-csomagok száma már nem érhető el. A csomagok által biztosított API-k továbbra is elérhetők az alkalmazások számára a <FrameworkReference> to Microsoft.AspNetCore.Apphasználatával. Gyakori API-példák a Kestrel, az MVC és a Razor.

Ez a módosítás nem vonatkozik az ASP.NET Core 2.x-ben hivatkozott Microsoft.AspNetCore.App összes bináris fájlra. Figyelemre méltó kivételek a következők:

  • Microsoft.Extensions A .NET Standardot továbbra is megcélozó kódtárak NuGet-csomagokként érhetők el (lásd https://github.com/dotnet/extensions: ).
  • A ASP.NET Core-csapat által létrehozott API-k, amelyek nem részei a csoportnak Microsoft.AspNetCore.App. Például a következő összetevők érhetők el NuGet-csomagokként:
  • A Json.NET támogatását fenntartó MVC-bővítmények. Az API NuGet-csomagként érhető el, amely támogatja a Json.NET és az MVC használatát. További részletekért tekintse meg a ASP.NET Core migrálási útmutatóját.
  • A SignalR .NET-ügyfél továbbra is támogatja a .NET Standardot, és NuGet-csomagként szállít. Számos .NET-futtatókörnyezethez, például Xamarinhoz és UWP-hez használható.

További információt a 3.0-s megosztott keretrendszer-szerelvények csomagjainak leállítása című témakörben talál. További információért lásd: dotnet/aspnetcore#3757.

Kategória

ASP.NET Core

Érintett API-k

Megosztott keretrendszer: Eltávolítva a Microsoft.AspNetCore.All

A ASP.NET Core 3.0-tól kezdve a Microsoft.AspNetCore.All metacsomag és a megfelelő Microsoft.AspNetCore.All megosztott keretrendszer már nem készül el. Ez a csomag ASP.NET Core 2.2-ben érhető el, és továbbra is megkapja a karbantartási frissítéseket ASP.NET Core 2.1-ben.

Bevezetett verzió

3,0

Régi viselkedés

Az alkalmazások a Microsoft.AspNetCore.All metapackage használatával célozzák meg a megosztott keretrendszert a Microsoft.AspNetCore.All .NET Core-on.

Új viselkedés

A .NET Core 3.0 nem tartalmaz megosztott keretrendszert Microsoft.AspNetCore.All .

A változás oka

A Microsoft.AspNetCore.All metapackage számos külső függőséget tartalmazott.

Migrálja a projektet a Microsoft.AspNetCore.App keretrendszer használatához. A korábban elérhető Microsoft.AspNetCore.All összetevők továbbra is elérhetők a NuGetben. Ezeket az összetevőket a megosztott keretrendszer helyett az alkalmazással együtt telepíti a rendszer.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

SignalR: HandshakeProtocol.SuccessHandshakeData lecserélve

A HandshakeProtocol.SuccessHandshakeData mező el lett távolítva, és egy segédmetódusra cserélődött, amely egy adott IHubProtocoladott kézfogási választ generál.

Bevezetett verzió

3,0

Régi viselkedés

HandshakeProtocol.SuccessHandshakeData mező public static ReadOnlyMemory<byte> volt.

Új viselkedés

HandshakeProtocol.SuccessHandshakeData egy olyan metódus váltotta fel staticGetSuccessfulHandshake(IHubProtocol protocol) , amely a megadott protokollon alapuló értéket ReadOnlyMemory<byte> ad vissza.

A változás oka

További mezők lettek hozzáadva a kézfogási válaszhoz , amelyek nem állandóak, és a kiválasztott protokolltól függően változnak.

Nincs. Ez a típus nem felhasználói kódból való használatra lett tervezve. Így publicmegosztható a SignalR-kiszolgáló és az ügyfél között. A .NET-ben írt ügyfél SignalR-ügyfelek is használhatják. A SignalR felhasználóit nem érintheti ez a változás.

Kategória

ASP.NET Core

Érintett API-k

HandshakeProtocol.SuccessHandshakeData

SignalR: Hub Csatlakozás ion ResetSendPing és ResetTimeout metódusok eltávolítva

A ResetSendPing rendszer eltávolította a metódusokat a ResetTimeout SignalR HubConnection API-ból. Ezeket a módszereket eredetileg csak belső használatra szánták, de ASP.NET Core 2.2-ben nyilvánossá tették őket. Ezek a módszerek nem lesznek elérhetők a ASP.NET Core 3.0 Előzetes verzió 4-es kiadásától kezdve. További információért lásd: dotnet/aspnetcore#8543.

Bevezetett verzió

3,0

Régi viselkedés

Az API-k elérhetők voltak.

Új viselkedés

Az API-k törlődnek.

A változás oka

Ezeket a módszereket eredetileg csak belső használatra szánták, de ASP.NET Core 2.2-ben nyilvánossá tették őket.

Ne használja ezeket a módszereket.

Kategória

ASP.NET Core

Érintett API-k

SignalR: Hub Csatlakozás ionContext konstruktorok módosultak

A SignalR konstruktorai HubConnectionContext úgy változtak, hogy több paraméter helyett egy beállítástípust fogadjanak el a jövőbiztos hozzáadási lehetőségekre. Ez a módosítás két konstruktort egyetlen konstruktorra cserél, amely elfogad egy beállítástípust.

Bevezetett verzió

3,0

Régi viselkedés

HubConnectionContext két konstruktorral rendelkezik:

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

Új viselkedés

A két konstruktort eltávolítottuk, és egy konstruktorra cseréltük:

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

A változás oka

Az új konstruktor egy új beállításobjektumot használ. Következésképpen a funkciók HubConnectionContext a jövőben bővíthetők anélkül, hogy több konstruktort és törést eredményeznek.

A következő konstruktor használata helyett:

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

Használja a következő konstruktort:

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

Kategória

ASP.NET Core

Érintett API-k

SignalR: A JavaScript-ügyfélcsomag neve megváltozott

A ASP.NET Core 3.0 Preview 7-ben a SignalR JavaScript-ügyfélcsomag neve a következőre @aspnet/signalr@microsoft/signalrváltozott: . A névváltoztatás azt a tényt tükrözi, hogy a SignalR az Azure SignalR szolgáltatásnak köszönhetően nem csupán ASP.NET Core-alkalmazásokban hasznos.

A változásra való reagáláshoz módosítsa a package.json fájlok, require utasítások és ECMAScript-utasítások import hivatkozásait. Az átnevezés részeként egyetlen API sem változik.

További információért lásd: dotnet/aspnetcore#11637.

Bevezetett verzió

3,0

Régi viselkedés

Az ügyfélcsomag neve @aspnet/signalr.

Új viselkedés

Az ügyfélcsomag neve @microsoft/signalr.

A változás oka

A névváltoztatás egyértelművé teszi, hogy a SignalR az Azure SignalR szolgáltatásnak köszönhetően ASP.NET Core-alkalmazásokon túl is hasznos.

Váltás az új csomagra @microsoft/signalr.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

SignalR: UseSignalR és Use Csatlakozás ions metódusok megjelölése elavultként

A metódusok UseConnections és UseSignalR az osztályok ConnectionsRouteBuilderHubRouteBuilder elavultként vannak megjelölve ASP.NET Core 3.0-ban.

Bevezetett verzió

3,0

Régi viselkedés

A SignalR hub útválasztása a következő használatával UseSignalR lett konfigurálva: vagy UseConnections.

Új viselkedés

Az útválasztás konfigurálásának régi módja elavult, és a végponti útválasztásra cserélődött.

A változás oka

A köztes szoftver átkerül az új végpont-útválasztási rendszerbe. A köztes szoftver hozzáadásának régi módja elavult.

Cserélje le UseSignalR a következőre UseEndpoints:

Régi kód:

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

Új kód:

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

Kategória

ASP.NET Core

Érintett API-k

SLA-k: Elavultként megjelölt SpaServices és NodeServices

A következő NuGet-csomagok tartalma mind szükségtelen volt a Core 2.1 ASP.NET óta. Ezért a következő csomagok elavultként vannak megjelölve:

Ugyanezen okból a következő npm-modulok elavultként vannak megjelölve:

Az előző csomagok és npm-modulok később törlődnek a .NET 5-ben.

Bevezetett verzió

3,0

Régi viselkedés

Az elavult csomagok és npm-modulok célja az volt, hogy integrálják ASP.NET Core-t különböző egyoldalas alkalmazások (SPA) keretrendszereivel. Ilyen keretrendszerek például az Angular, a React és a React with Redux.

Új viselkedés

Új integrációs mechanizmus létezik a Microsoft.AspNetCore.SpaServices.Extensions NuGet csomagban. A csomag továbbra is az Angular és a React projektsablonok alapja, mivel ASP.NET Core 2.1.

A változás oka

ASP.NET Core támogatja a különböző egyoldalas alkalmazások (SPA) keretrendszerekkel való integrációt, beleértve az Angulart, a Reactet és a Reactet a Redux-tal. Kezdetben ezekkel a keretrendszerekkel való integráció ASP.NET core-specifikus összetevőkkel történt, amelyek olyan forgatókönyveket kezeltek, mint a kiszolgálóoldali előrendelés és a Webpack-integráció. Ahogy telt az idő, az iparági szabványok megváltoztak. Az SPA-keretrendszerek mindegyike saját szabványos parancssori felületeket adott ki. Például az Angular CLI és a create-react-app.

Amikor ASP.NET Core 2.1 2018 májusában megjelent, a csapat reagált a szabványok változására. Az SPA-keretrendszerek saját eszközláncaival való integráció újabb és egyszerűbb módját biztosították. Az új integrációs mechanizmus létezik a csomagban Microsoft.AspNetCore.SpaServices.Extensions , és a Core 2.1 ASP.NET óta az Angular és a React projektsablonok alapja marad.

Annak tisztázása érdekében, hogy a régebbi ASP.NET core-specifikus összetevők irrelevánsak és nem ajánlottak:

  • A 2.1 előtti integrációs mechanizmus elavultként van megjelölve.
  • A támogató npm-csomagok elavultként vannak megjelölve.

Ha ezeket a csomagokat használja, frissítse az alkalmazásokat a funkció használatára:

  • A csomagban Microsoft.AspNetCore.SpaServices.Extensions .
  • A használt SPA-keretrendszerek biztosítják

Az olyan funkciók engedélyezéséhez, mint a kiszolgálóoldali előrendelés és a gyakori elérésű modul újrabetöltése, tekintse meg a megfelelő SPA-keretrendszer dokumentációját. A funkció Microsoft.AspNetCore.SpaServices.Extensionsnem elavult, és továbbra is támogatott lesz.

Kategória

ASP.NET Core

Érintett API-k

SLA-k: A SpaServices és a NodeServices többé nem kerül vissza a konzolnaplózóba

Microsoft.AspNetCore.SpaServices és Microsoft.AspNetCore.NodeServices csak akkor jeleníti meg a konzolnaplókat, ha a naplózás konfigurálva van.

Bevezetett verzió

3,0

Régi viselkedés

Microsoft.AspNetCore.SpaServices és Microsoft.AspNetCore.NodeServices arra szolgál, hogy automatikusan hozzon létre egy konzolnaplózót, ha nincs konfigurálva a naplózás.

Új viselkedés

Microsoft.AspNetCore.SpaServices és Microsoft.AspNetCore.NodeServices csak akkor jeleníti meg a konzolnaplókat, ha a naplózás konfigurálva van.

A változás oka

Össze kell hangolni a többi ASP.NET Core-csomag naplózási implementálását.

Ha a régi viselkedésre van szükség, a konzolnaplózás konfigurálásához adja hozzá services.AddLogging(builder => builder.AddConsole()) a Setup.ConfigureServices metódust.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Cél keretrendszer: .NET-keretrendszer támogatás elvetve

A ASP.NET Core 3.0-tól kezdve a .NET-keretrendszer nem támogatott cél keretrendszer.

Módosítás leírása

.NET-keretrendszer 4.8 a .NET-keretrendszer utolsó főverziója. Az új ASP.NET Core-alkalmazásokat a .NET Core-ra kell építeni. A .NET Core 3.0 kiadásától kezdve a .NET Core részét képező ASP.NET Core 3.0-ra gondolhat.

A .NET-keretrendszer ASP.NET Core-t használó ügyfelek a 2.1 LTS-kiadással továbbra is teljes mértékben támogatott módon folytathatják. A 2.1 támogatása és karbantartása legalább 2021. augusztus 21-ig folytatódik. Ez a dátum a .NET támogatási szabályzatában szereplő LTS-kiadás deklarációját követő három év. A .NET-keretrendszer ASP.NET Core 2.1-csomagok támogatása határozatlan időre ki fog terjedni, hasonlóan a többi csomagalapú ASP.NET-keretrendszer karbantartási szabályzatához.

A .NET-keretrendszer és a .NET Core közötti portolással kapcsolatos további információkért lásd: Portolás a .NET Core-ba.

Microsoft.Extensions nem érintik a csomagokat (például a naplózást, a függőséginjektálást és a konfigurációt) és az Entity Framework Core-t. Továbbra is támogatják a .NET Standardot.

A változás motivációjára vonatkozó további információkért lásd az eredeti blogbejegyzést.

Bevezetett verzió

3,0

Régi viselkedés

ASP.NET Core-alkalmazások .NET Core-on vagy .NET-keretrendszer futtathatók.

Új viselkedés

ASP.NET Core-alkalmazások csak .NET Core-on futtathatók.

Válasszon a következő lehetőségek közül:

  • Tartsa az alkalmazást a ASP.NET Core 2.1-en.
  • Migrálja az alkalmazást és a függőségeket a .NET Core-ba.

Kategória

ASP.NET Core

Érintett API-k

Egyik sem

Alapvető .NET-kódtárak

Azok az API-k, amelyek a jelentésverziót jelentik, és nem a fájlverziót jelentik

A .NET Core-ban verziót vissza adó API-k közül sok most a termékverziót adja vissza a fájlverzió helyett.

Módosítás leírása

A .NET Core 2.2-es és korábbi verzióiban Environment.VersionRuntimeInformation.FrameworkDescriptiona .NET Core-szerelvények fájltulajdonságainak párbeszédpanelje a fájlverziót tükrözi. A .NET Core 3.0-tól kezdve a termékverziót tükrözik.

Az alábbi ábra a .NET Core 2.2 (bal oldalon) és a .NET Core 3.0 (jobb oldalon) System.Runtime.dll szerelvény verzióadatainak különbségét mutatja be a Windows Intéző fájltulajdonságok párbeszédpanelén látható módon.

Difference in product version information

Bevezetett verzió

3,0

Nincs. Ennek a módosításnak intuitívabbá kell tennie a verzióészlelést, és nem kell eltűrnie.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

Az egyéni EncoderFallbackBuffer-példányok nem eshetnek vissza rekurzívan

Az egyéni EncoderFallbackBuffer példányok nem eshetnek vissza rekurzív módon. A megvalósításnak EncoderFallbackBuffer.GetNextChar() olyan karaktersorozatot kell eredményeznie, amely a célkódolásra konvertálható. Ellenkező esetben kivétel történik.

Módosítás leírása

A karakterről bájtra transzkódolási művelet során a futtatókörnyezet észleli a hibásan formázott vagy nem konvertálható UTF-16 sorozatokat, és megadja ezeket a karaktereket a EncoderFallbackBuffer.Fallback metódusnak. A Fallback metódus meghatározza, hogy mely karaktereket kell helyettesíteni az eredeti nem konverbilis adatokkal, és ezeket a karaktereket egy ciklus meghívásával EncoderFallbackBuffer.GetNextChar üríti ki a rendszer.

A futtatókörnyezet ezután megpróbálja átkódolni ezeket a helyettesítő karaktereket a célkódolásra. Ha ez a művelet sikeres, a futtatókörnyezet továbbra is átkódolást hajt végre onnan, ahol az eredeti bemeneti sztringben abbahagyta.

Korábban az egyéni implementációk EncoderFallbackBuffer.GetNextChar() olyan karaktersorozatokat adhatnak vissza, amelyek nem konvertálhatók a célkódolásra. Ha a helyettesítő karakterek nem kódolhatók át a célkódolásra, a futtatókörnyezet ismét meghívja a EncoderFallbackBuffer.Fallback metódust a helyettesítő karakterekkel, és azt várja, hogy a EncoderFallbackBuffer.GetNextChar() metódus egy új helyettesítési sorozatot ad vissza. Ez a folyamat addig folytatódik, amíg a futtatókörnyezet végül egy jól formázott, átalakítható helyettesítést nem lát, vagy amíg el nem éri a maximális rekurziós számot.

A .NET Core 3.0-tól kezdve az egyéni implementációknak EncoderFallbackBuffer.GetNextChar() vissza kell adniuk a célkódolásra konvertálható karaktersorozatokat. Ha a helyettesítő karakterek nem kódolhatók át a célkódolásra, a rendszer egy ArgumentException karaktert ad vissza. A futtatókörnyezet többé nem indít rekurzív hívásokat a EncoderFallbackBuffer példányba.

Ez a viselkedés csak akkor érvényes, ha a következő három feltétel teljesül:

  • A futtatókörnyezet egy rosszul formázott UTF-16 sorozatot vagy egy UTF-16 sorozatot észlel, amely nem konvertálható a célkódolásra.
  • EncoderFallback Egyéni beállítás van megadva.
  • Az egyéni EncoderFallback kísérletek egy új rosszul formázott vagy nem konvertálható UTF-16 sorozat helyettesítésére.

Bevezetett verzió

3,0

A legtöbb fejlesztőnek nem kell semmilyen műveletet elvégeznie.

Ha egy alkalmazás egyéni EncoderFallback és EncoderFallbackBuffer osztályt használ, győződjön meg arról, hogy a tartalék puffert EncoderFallbackBuffer.Fallback jól formázott UTF-16-adatokkal tölti fel, amelyek közvetlenül konvertálhatók a célkódolásra, amikor a futtatókörnyezet először meghívja a Fallback metódust.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

Módosult a lebegőpontos formázás és elemzési viselkedés

A lebegőpontos elemzési és formázási viselkedés (a típusok és Single a Double típusok szerint) most már Enterprise kiadás E-kompatibilis. Ez biztosítja, hogy a lebegőpontos típusok viselkedése a .NET-ben megegyezik a többi I Enterprise kiadás E-kompatibilis nyelv viselkedésével. Például mindig meg kell egyeznie azzal, double.Parse("SomeLiteral") amit a C# állít elő.double x = SomeLiteral

Módosítás leírása

A .NET Core 2.2-ben és a korábbi verziókban a formázás Double.ToString és Single.ToStringaz elemzés a következővelDouble.Parse: , Double.TryParse, Single.Parseés Single.TryParse nem I Enterprise kiadás E-kompatibilis. Ennek eredményeképpen lehetetlen garantálni, hogy egy érték lekerekítve legyen bármilyen támogatott szabványos vagy egyéni formátumsztringgel. Egyes bemenetek esetében a formázott érték elemzésének kísérlete sikertelen lehet, mások esetében pedig az elemzési érték nem egyenlő az eredeti értékkel.

A .NET Core 3.0-tól kezdve a lebegőpontos elemzési és formázási műveletek I Enterprise kiadás E 754-kompatibilisek.

Az alábbi táblázat két kódrészletet és a .NET Core 2.2 és a .NET Core 3.1 közötti kimenet változását mutatja be.

Kódrészletet Kimenet a .NET Core 2.2-n Kimenet a .NET Core 3.1-en
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

További információkért tekintse meg a lebegőpontos elemzési és formázási fejlesztéseket a .NET Core 3.0 blogbejegyzésében.

Bevezetett verzió

3,0

A lebegőpontos elemzési és formázási fejlesztések meglévő kódszakaszáragyakorolt lehetséges hatás a .NET Core 3.0 blogbejegyzésben arra utal, hogy a kódon elvégezhet néhány módosítást, ha meg szeretné tartani az előző viselkedést.

  • A formázás egyes eltérései esetén egy másik formátumsztring megadásával az előző viselkedésnek megfelelő viselkedést kaphat.
  • Az elemzési különbségek esetén nincs olyan mechanizmus, amely visszaeshet az előző viselkedésre.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

A lebegőpontos elemzési műveletek már nem hiúsulnak meg, vagy túlcsordulást jeleznek

A lebegőpontos elemzési metódusok már nem adnak vissza vagy nem adnak OverflowException vissza false értéket, ha olyan sztringet elemeznek, amelynek numerikus értéke kívül esik a lebegőpontos vagy Double a Single lebegőpontos típus tartományán.

Módosítás leírása

A .NET Core 2.2-es és korábbi verzióiban a Double.Parse metódusok olyan Single.Parse értékeket adnak OverflowException meg, amelyek nem tartoznak a megfelelő típus tartományába. A Double.TryParse tartományon kívüli numerikus értékek sztringreprezentációinak és Single.TryParse metódusainak visszaadása false .

A .NET Core 3.0-tól kezdve a Double.Parse, Double.TryParse, Single.Parseés Single.TryParse metódusok már nem hiúsulnak meg a tartományon kívüli numerikus sztringek elemzésekor. Ehelyett az elemzési metódusok a Double túllépett Double.MaxValueértékeknél térnek visszaDouble.PositiveInfinity, és a kisebb Double.MinValueértékeknél térnek visszaDouble.NegativeInfinity. Hasonlóképpen, az elemzési metódusok a Single nagyobb Single.MaxValueértékeket is visszaadjákSingle.PositiveInfinity, és a kisebb Single.MinValueértékeket adnak visszaSingle.NegativeInfinity.

Ez a módosítás a jobb I Enterprise kiadás E 754:2008 megfelelőség érdekében történt.

Bevezetett verzió

3,0

Ez a módosítás kétféleképpen befolyásolhatja a kódot:

  • A kód a túlcsorduláskor végrehajtandó kezelőtől OverflowException függ. Ebben az esetben távolítsa el az utasítást, és helyezze el a catch szükséges kódot egy If utasításban, amely ellenőrzi, hogy van-e Double.IsInfinitytrue.Single.IsInfinity

  • A kód feltételezi, hogy a lebegőpontos értékek nem Infinity. Ebben az esetben hozzá kell adnia a szükséges kódot a lebegőpontos értékek PositiveInfinity és NegativeInfinitya .

Kategória

Alapvető .NET-kódtárak

Érintett API-k

InvalidAsynchronousStateException áthelyezve egy másik szerelvénybe

Az InvalidAsynchronousStateException osztály át lett helyezve.

Módosítás leírása

A .NET Core 2.2-es és korábbi verzióiban az InvalidAsynchronousStateException osztály a System.ComponentModel.TypeConverter szerelvényben található.

A .NET Core 3.0-tól kezdve a System.ComponentModel.Primitives szerelvényben található.

Bevezetett verzió

3,0

Ez a változás csak azokat az alkalmazásokat érinti, amelyek tükrözést használnak a InvalidAsynchronousStateException terheléshez egy olyan metódus meghívásávalActivator.CreateInstance, mint például Assembly.GetType egy olyan túlterhelés, amely feltételezi, hogy a típus egy adott szerelvényben található. Ha ez a helyzet, frissítse a metódushívásban hivatkozott szerelvényt, hogy tükrözze a típus új szerelvényhelyét.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

Nincs.

A rosszul formázott UTF-8 bájtsorozatok cseréje Unicode-irányelveket követ

Ha az UTF8Encoding osztály hibás UTF-8 bájtsorozattal találkozik egy bájtról karakterre történő átkódolási művelet során, akkor ezt a sorozatot a kimeneti sztringben egy ' ' (U+FFFD REPLACE CHARACTER) karakterre cseréli. A .NET Core 3.0 eltér a .NET Core korábbi verzióitól és a .NET-keretrendszer a Unicode ajánlott eljárásának követésével, amely a helyettesítést a transzkódolási művelet során hajtja végre.

Ez egy nagyobb erőfeszítés része az UTF-8 kezelésének javítása a .NET-ben, beleértve az új System.Text.Unicode.Utf8 és System.Text.Rune a típusok által is. A UTF8Encoding típus továbbfejlesztett hibakezelési mechanikát kapott, hogy az az újonnan bevezetett típusokkal összhangban hozza létre a kimenetet.

Módosítás leírása

A .NET Core 3.0-tól kezdve a bájtok karakterekre való átkódolásakor az osztály a UTF8Encoding Unicode ajánlott eljárásai alapján végez karakterhelyettesítést. A használt helyettesítési mechanizmust a Unicode Standard 12.0-s, 3.9-es (PDF) verziója ismerteti a maximális alrészek U+FFFD helyettesítése című címsorban.

Ez a viselkedés csak akkor érvényes, ha a bemeneti bájtsor hibásan formázott UTF-8 adatokat tartalmaz. Továbbá, ha a UTF8Encoding példányt létrehozták throwOnInvalidBytes: true, a UTF8Encoding példány továbbra is érvénytelen bemenetet ad vissza ahelyett, hogy U+FFFD-cserét végez. A konstruktorról további információt a UTF8EncodingUTF8Encoding(Boolean, Boolean).

Az alábbi táblázat egy érvénytelen 3 bájtos bemenettel szemlélteti a változás hatását:

Rosszul formázott 3 bájtos bemenet Kimenet a .NET Core 3.0 előtt Kimenet a .NET Core 3.0-val kezdődően
[ ED A0 90 ] [ FFFD FFFD ] (2 karakteres kimenet) [ FFFD FFFD FFFD ] (3 karakteres kimenet)

A 3 karakteres kimenet az előnyben részesített kimenet a korábban csatolt Unicode Standard PDF 3–9. táblázata szerint.

Bevezetett verzió

3,0

Nincs szükség műveletre a fejlesztő részéről.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

TypeDescriptionProviderAttribute áthelyezve egy másik szerelvénybe

Az TypeDescriptionProviderAttribute osztály át lett helyezve.

Módosítás leírása

A .NET Core 2.2-es és korábbi verzióiban az TypeDescriptionProviderAttribute osztály a System.ComponentModel.TypeConverter szerelvényben található.

A .NET Core 3.0-tól kezdve a System.ObjectModel szerelvényben található.

Bevezetett verzió

3,0

Ez a változás csak azokat az alkalmazásokat érinti, amelyek tükröződéssel töltik be a TypeDescriptionProviderAttribute típust egy olyan metódus meghívásával, mint például Assembly.GetType egy olyan túlterhelés Activator.CreateInstance , amely feltételezi, hogy a típus egy adott szerelvényben található. Ebben az esetben a metódushívásban hivatkozott szerelvényt frissíteni kell, hogy tükrözze a típus új szerelvényhelyét.

Kategória

Windows Forms

Érintett API-k

Nincs.

A ZipArchiveEntry már nem kezeli az inkonzisztens bejegyzésméretű archívumokat

A zip-archívumok a tömörített és a tömörítetlen méretet is felsorolják a központi könyvtárban és a helyi fejlécben. Maga a belépési adatok is jelzik a méretét. A .NET Core 2.2-ben és a korábbi verziókban ezek az értékek soha nem lettek ellenőrizve a konzisztencia szempontjából. A .NET Core 3.0-tól kezdve ezek most már elérhetők.

Módosítás leírása

A .NET Core 2.2-ben és a korábbi verziókban akkor is sikeres, ZipArchiveEntry.Open() ha a helyi fejléc nem ért egyet a zip-fájl központi fejlécével. Az adatok a tömörített stream végéig lesznek tömörítve, még akkor is, ha a fájl hossza meghaladja a központi könyvtárban/helyi fejlécben felsorolt tömörítetlen fájlméretet.

A .NET Core 3.0-tól kezdve a metódus ellenőrzi, hogy a ZipArchiveEntry.Open() helyi fejléc és a központi fejléc megegyezik-e egy bejegyzés tömörített és tömörítetlen méretével. Ha nem, a metódus egy InvalidDataException olyan, ha az archívum helyi fejléc- és/vagy adatleíró listamérete nem egyezik meg a zip-fájl központi könyvtárával. Bejegyzés olvasásakor a rendszer csonkolja a tömörített adatokat a fejlécben felsorolt tömörítetlen fájlméretre.

Ez a módosítás annak biztosítása érdekében történt, hogy a ZipArchiveEntry rendszer helyesen adja meg az adatok méretét, és hogy csak az adatmennyiség legyen olvasható.

Bevezetett verzió

3,0

Csomagolja újra a zip archívumot, amely ezeket a problémákat mutatja.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

A FieldInfo.SetValue kivételt jelez a statikus, csak init-only mezők esetében

A .NET Core 3.0-tól kezdve kivétel történik, ha egy statikus mező InitOnly értékét hívással System.Reflection.FieldInfo.SetValuepróbálja beállítani.

Módosítás leírása

A .NET Core 3.0 előtti .NET-keretrendszer és verzióiban beállíthatja egy állandó statikus mező értékét az inicializálás után (olvashatóan C#-ban) hívássalSystem.Reflection.FieldInfo.SetValue. Az ilyen mezők ilyen módon történő beállítása azonban kiszámíthatatlan viselkedést eredményezett a cél-keretrendszer és az optimalizálási beállítások alapján.

A .NET Core 3.0-s és újabb verzióiban, amikor statikus mezőre InitOnly hív felSetValue, a rendszer kivételt System.FieldAccessException jelez.

Tipp.

A InitOnly mező olyan mező, amelyet csak a deklaráláskor vagy az azt tartalmazó osztály konstruktorában lehet beállítani. Más szóval az inicializálás után állandó.

Bevezetett verzió

3,0

Statikus inicializálás, InitOnly statikus konstruktor mezői. Ez a dinamikus és a nem dinamikus típusokra is vonatkozik.

Másik lehetőségként eltávolíthatja az attribútumot a FieldAttributes.InitOnly mezőből, majd meghívhatja FieldInfo.SetValue.

Kategória

Alapvető .NET-kódtárak

Érintett API-k

A GroupCollection továbbítása az IEnumerable<T> kiterjesztési metódusaihoz egyértelműsítést igényel

Ha olyan bővítménymetódust hív meg, amely egy adott bővítményt GroupCollectionhasználIEnumerable<T>, a típust egy öntöttel kell egyértelműsítenie.

Módosítás leírása

A .NET Core 3.0-tól System.Text.RegularExpressions.GroupCollection kezdve az általa implementálható egyéb típusok mellett implementál IEnumerable<KeyValuePair<String,Group>> is, beleértve a IEnumerable<Group>. Ez kétértelműséget eredményez egy olyan bővítménymetódus meghívásakor, amely egy IEnumerable<T>. Ha például egy példányon GroupCollection meghív egy ilyen bővítménymetódust, Enumerable.Counta következő fordítóhiba jelenik meg:

CS1061: A "GroupCollection" nem tartalmaz definíciót a "Count" kifejezéshez, és nem található akadálymentes "Count" kiterjesztési módszer, amely elfogadja a "GroupCollection" típusú első argumentumot (hiányzik egy használt irányelv vagy egy szerelvényhivatkozás?)

A .NET korábbi verzióiban nem volt kétértelműség és fordítási hiba.

Bevezetett verzió

3,0

A változás oka

Ez nem szándékos törés volt. Mivel már egy ideje így van, nem tervezzük visszaállítani. Emellett egy ilyen változás maga is törés lenne.

Például GroupCollection egyértelműsítse azokat a bővítménymeta-metódusokat, amelyek egy leadott elemet fogadnak IEnumerable<T> el.

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

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

Kategória

Alapvető .NET-kódtárak

Érintett API-k

Minden olyan bővítménymetódus, amely elfogad egy bővítményt IEnumerable<T> , hatással van rá. Példa:

Kriptográfia

A "BEGIN TRUSTED CERTIFICATE" szintaxis a linuxos főtanúsítványok esetében már nem támogatott

A Linux és más Unix-szerű rendszerek főtanúsítványai (de nem macOS) kétféle formában jelenhetnek meg: a standard BEGIN CERTIFICATE PEM fejlécben és az OpenSSL-specifikus BEGIN TRUSTED CERTIFICATE PEM-fejlécben. Ez utóbbi szintaxis lehetővé teszi a .NET Core System.Security.Cryptography.X509Certificates.X509Chain osztályával kompatibilitási problémákat okozó további konfigurációt. BEGIN TRUSTED CERTIFICATE A főtanúsítvány tartalmát a láncmotor már nem tölti be a .NET Core 3.0-tól kezdve.

Módosítás leírása

Korábban a legfelső szintű megbízhatósági lista feltöltéséhez BEGIN TRUSTED CERTIFICATE mind a BEGIN CERTIFICATE szintaxist, mind a szintaxist használták. Ha a BEGIN TRUSTED CERTIFICATE szintaxist használta, és további beállításokat adott meg a fájlban, előfordulhat, X509Chain hogy a lánc megbízhatósági kapcsolatát explicit módon letiltották (X509ChainStatusFlags.ExplicitDistrust). Ha azonban a tanúsítvány egy korábban betöltött fájl szintaxisával BEGIN CERTIFICATE is meg lett adva, a lánc megbízhatósága engedélyezve lett.

A .NET Core 3.0-tól BEGIN TRUSTED CERTIFICATE kezdődően a tartalom már nem olvasható. Ha a tanúsítványt nem szabványos BEGIN CERTIFICATE szintaxissal adhatók meg, akkor a X509Chain gyökér nem megbízható (X509ChainStatusFlags.UntrustedRoot).

Bevezetett verzió

3,0

A legtöbb alkalmazást nem érinti ez a módosítás, de azok az alkalmazások, amelyek nem látják mindkét főtanúsítvány-forrást az engedélyek miatt, a frissítés után váratlan UntrustedRoot hibák léphetnek fel.

Számos Linux-disztribúció (vagy disztribúció) főtanúsítványokat ír két helyre: egy egytanúsítvány-fájlonkénti könyvtárba és egy egyfájlos összefűzésbe. Egyes disztribúciók esetében az egytanúsítványonkénti könyvtár a BEGIN TRUSTED CERTIFICATE szintaxist használja, míg a fájlösszefűzés a standard BEGIN CERTIFICATE szintaxist használja. Győződjön meg arról, hogy az egyéni főtanúsítványok a fenti helyek legalább egyikéhez hasonlóan BEGIN CERTIFICATE vannak hozzáadva, és hogy mindkét hely olvasható legyen az alkalmazás számára.

A tipikus könyvtár a /etc/ssl/certs/ és a tipikus összefűzött fájl a /etc/ssl/cert.pem. Használja a parancsot openssl version -d a platformspecifikus gyökér meghatározásához, amely eltérhet az /etc/ssl/-től. Az Ubuntu 18.04-ben például a könyvtár /usr/lib/ssl/certs/ , a fájl pedig /usr/lib/ssl/cert.pem. A /usr/lib/ssl/certs/ azonban nem létezik az /etc/ssl/certs/ és /usr/lib/ssl/cert.pem szimlink.

$ 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

Kategória

Kriptográfia

Érintett API-k

A EnvelopedCms alapértelmezett értéke az AES-256 titkosítás

Az alapértelmezett szimmetrikus titkosítási algoritmus EnvelopedCms tripleDES-ről AES-256-ra változott.

Módosítás leírása

A korábbi verziókban, amikor EnvelopedCms szimmetrikus titkosítási algoritmus megadása nélkül, konstruktor-túlterhelésen keresztül titkosítják az adatokat, az adatok a TripleDES/3DES/3DEA/DES3-EDE algoritmussal lesznek titkosítva.

A .NET Core 3.0-tól kezdve (a System.Security.Cryptography.Pkcs NuGet csomag 4.6.0-s verzióján keresztül) az alapértelmezett algoritmus AES-256-ra módosult az algoritmusok modernizálása és az alapértelmezett beállítások biztonsága érdekében. Ha egy üzenet címzett tanúsítványa (nem EC) Diffie-Hellman nyilvános kulccsal rendelkezik, a titkosítási művelet meghiúsulhat CryptographicException a mögöttes platform korlátai miatt.

Az alábbi mintakódban az adatok tripleDES-sel titkosítva lesznek, ha a .NET Core 2.2-ben vagy korábbi verzióban futnak. Ha a .NET Core 3.0-s vagy újabb verzióján fut, az AES-256-tal van titkosítva.

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

Bevezetett verzió

3,0

Ha a módosítás negatívan érinti, visszaállíthatja a TripleDES-titkosítást úgy, hogy explicit módon megadja a titkosítási algoritmus azonosítóját egy EnvelopedCms olyan konstruktorban, amely tartalmaz egy típusparamétert AlgorithmIdentifier, például:

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

Kategória

Kriptográfia

Érintett API-k

Nőtt az RSAOpenSsl kulcslétrehozás minimális mérete

Az új RSA-kulcsok linuxos generálásának minimális mérete 384 bitesről 512 bitesre nőtt.

Módosítás leírása

A .NET Core 3.0-tól kezdve a tulajdonság által LegalKeySizes az RSA-példányokon RSA.CreateRSAOpenSslRSACryptoServiceProvider jelentett minimális jogi kulcsméret 384-ről 512-re nőtt.

Ennek eredményeképpen a .NET Core 2.2-ben és a korábbi verziókban egy metódushívás, például RSA.Create(384) sikeres lesz. A .NET Core 3.0-s és újabb verzióiban a metódushívás RSA.Create(384) kivételt jelez, amely azt jelzi, hogy a méret túl kicsi.

Ez a módosítás azért történt, mert a Linuxon a titkosítási műveleteket végző OpenSSL minimálisra emelte az 1.0.2 és az 1.1.0 verzió között. A .NET Core 3.0 az OpenSSL 1.1.x és 1.0.x közötti verziót részesíti előnyben, a minimális jelentett verzió pedig az új, magasabb függőségi korlátozásnak megfelelően lett létrehozva.

Bevezetett verzió

3,0

Ha az érintett API-k bármelyikét meghívja, győződjön meg arról, hogy a létrehozott kulcsok mérete nem kisebb a szolgáltató minimális méreténél.

Feljegyzés

A 384 bites RSA már nem biztonságosnak számít (ahogy az 512 bites RSA is). A modern javaslatok, például a NIST Special Publication 800-57 Part 1 Revision 4, 2048 bitesre javasolják az újonnan létrehozott kulcsok minimális méretét.

Kategória

Kriptográfia

Érintett API-k

A .NET Core 3.0 az OpenSSL 1.1.x-et részesíti előnyben az OpenSSL 1.0.x-hez

A Linuxhoz készült .NET Core, amely több Linux-disztribúcióban is működik, támogatja az OpenSSL 1.0.x és az OpenSSL 1.1.x rendszert is. A .NET Core 2.1 és a .NET Core 2.2 először az 1.0.x-et keresi, majd visszaesik az 1.1.x-esre; a .NET Core 3.0 először az 1.1.x-et keresi. Ez a módosítás új titkosítási szabványok támogatásának céljából történt.

Ez a változás hatással lehet a .NET Core OpenSSL-specifikus interoptípusaival platformfüggetlen kódtárakra vagy alkalmazásokra.

Módosítás leírása

A .NET Core 2.2-ben és a korábbi verziókban a futtatókörnyezet az OpenSSL 1.0.x 1.1.x-et részesíti előnyben. Ez azt jelenti, hogy az IntPtr OpenSSL-vel való interop és SafeHandle típusok a libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 beállítással használhatók.

A .NET Core 3.0-tól kezdve a futtatókörnyezet inkább az OpenSSL 1.1.x-et tölti be az OpenSSL 1.0.x-hez, így az IntPtr OpenSSL-vel való interop-típusok használata SafeHandle a libcrypto.so.1.1/libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 beállítás szerint. Emiatt előfordulhat, hogy az OpenSSL-vel közvetlenül együttműködő kódtárak és alkalmazások nem kompatibilisek a .NET Core által közzétett értékekkel a .NET Core 2.1-ről vagy a .NET Core 2.2-ről való frissítéskor.

Bevezetett verzió

3,0

Az OpenSSL-vel közvetlen műveleteket végező kódtáraknak és alkalmazásoknak körültekintőnek kell lenniük annak biztosítása érdekében, hogy az OpenSSL ugyanazon verzióját használják, mint a .NET Core-futtatókörnyezetet.

A .NET Core titkosítási típusait vagy értékeit közvetlenül az OpenSSL-vel használó IntPtr kódtáraknak vagy SafeHandle alkalmazásoknak össze kell hasonlítaniuk az új SafeEvpPKeyHandle.OpenSslVersion tulajdonsággal használt kódtár verzióját, hogy a mutatók kompatibilisek legyenek.

Kategória

Kriptográfia

Érintett API-k

A CryptoStream.Dispose csak íráskor alakítja át az utolsó blokkot

A CryptoStream.Dispose műveletek befejezéséhez CryptoStream használt metódus már nem próbálja átalakítani az utolsó blokkot olvasáskor.

Módosítás leírása

A korábbi .NET-verziókban, ha egy felhasználó hiányos olvasást CryptoStreamRead hajtott végre módban, a Dispose metódus kivételt okozhat (például ha az AES-t párnázással használja). A kivétel azért történt, mert az utolsó blokkot megpróbálták átalakítani, de az adatok hiányosak voltak.

A .NET Core 3.0-s és újabb verzióiban Dispose már nem próbálja átalakítani az utolsó blokkot olvasáskor, ami lehetővé teszi a hiányos olvasást.

A változás oka

Ez a módosítás lehetővé teszi a titkosítási stream hiányos olvasását egy hálózati művelet megszakítása esetén, kivétel nélkül.

Bevezetett verzió

3,0

A legtöbb alkalmazást nem érinti ez a változás.

Ha az alkalmazás korábban kivételt észlelt hiányos olvasás esetén, törölheti a catch blokkot. Ha az alkalmazás a kivonatolási forgatókönyvek utolsó blokkjának átalakítását használta, előfordulhat, hogy a teljes streamet be kell olvasnia, mielőtt az el lett volna osztva.

Kategória

Kriptográfia

Érintett API-k

Entity Framework Core

Az Entity Framework Core kompatibilitástörő változásai

Globalizáció

A "C" területi térképek az invariáns területi beállításhoz

A .NET Core 2.2 és korábbi verziói az alapértelmezett ICU-viselkedéstől függenek, amely a "C" területi beállításokat a en_US_POSIX területi beállításhoz rendeli. A en_US_POSIX területi beállítás nem megfelelő rendezési viselkedéssel rendelkezik, mivel nem támogatja a kis- és nagybetűk megkülönböztetéses sztringek összehasonlítását. Mivel egyes Linux-disztribúciók alapértelmezett területi beállításként a "C" területi beállítást adták meg, a felhasználók váratlan viselkedést tapasztaltak.

Módosítás leírása

A .NET Core 3.0-tól kezdve a "C" területi leképezés az Invariant területi beállítás használatára változott en_US_POSIX helyett. A "C" területi beállítás az Invariant-leképezésre a Windowsra is alkalmazva van a konzisztencia érdekében.

A "C" en_US_POSIX kultúrára való leképezése zavart okozott az ügyfelek számára, mivel en_US_POSIX nem támogatja a kis- és nagybetűk érzéketlen rendezési/keresési sztringműveleteit. Mivel a "C" területi beállítás alapértelmezett területi beállításként használatos néhány Linux-disztribúcióban, az ügyfelek ezt a nem kívánt viselkedést tapasztalták ezeken az operációs rendszereken.

Bevezetett verzió

3,0

Semmi konkrétabb, mint a tudatosság a változás. Ez a módosítás csak a "C" területi leképezést használó alkalmazásokat érinti.

Kategória

Globalizáció

Érintett API-k

Ez a változás minden rendezési és kulturális API-t érint.

Msbuild

Erőforrás-jegyzékfájl nevének módosítása

A .NET Core 3.0-tól kezdve az alapértelmezett esetben az MSBuild egy másik jegyzékfájlnevet hoz létre az erőforrásfájlokhoz.

Bevezetett verzió

3,0

Módosítás leírása

A .NET Core 3.0 előtt, ha nem LogicalName, ManifestResourceNamevagy DependentUpon metaadatokat adott meg a projektfájl egyik EmbeddedResource eleméhez, az MSBuild létrehozott egy jegyzékfájlnevet a mintában <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Ha RootNamespace nincs definiálva a projektfájlban, akkor alapértelmezés szerint a projekt neve lesz. Például egy Űrlap1.resx nevű erőforrásfájl létrehozott jegyzékneve a gyökérprojekt könyvtárában a MyProject.Form1.resources volt.

A .NET Core 3.0-tól kezdődően, ha egy erőforrásfájl azonos nevű forrásfájllal van együtt helyezve (például Form1.resx és Form1.cs), az MSBuild a forrásfájl típusadatait használja a jegyzékfájl nevének a mintában <Namespace>.<ClassName>.resourcesvaló létrehozásához. A rendszer kinyeri a névteret és az osztálynevet a megosztott forrásfájl első típusából. Például egy Form1.resx nevű erőforrásfájl létrehozott jegyzékneve, amely egy Form1.cs nevű forrásfájllal van együtt helyezve, a MyNamespace.Form1.resources. Fontos megjegyezni, hogy a fájlnév első része eltér a .NET Core korábbi verzióitól (MyProject helyett MyNamespace).

Feljegyzés

Ha a projektfájl egyik EmbeddedResource elemén meg van LogicalNameadva , ManifestResourceNamevagy DependentUpon metaadatok vannak megadva, akkor ez a módosítás nem érinti ezt az erőforrásfájlt.

Ez a kompatibilitástörő változás a tulajdonság .NET Core-projektekhez való EmbeddedResourceUseDependentUponConvention hozzáadásával lett bevezetve. Alapértelmezés szerint az erőforrásfájlok nincsenek explicit módon felsorolva egy .NET Core-projektfájlban, így nem DependentUpon rendelkeznek metaadatokkal a létrehozott .resources fájl elnevezéséhez. Ha EmbeddedResourceUseDependentUponConvention az alapértelmezett értékre truevan állítva, az MSBuild egy megosztott forrásfájlt keres, és kinyer egy névteret és egy osztálynevet a fájlból. Ha be falsevan állítvaEmbeddedResourceUseDependentUponConvention, az MSBuild az előző viselkedésnek megfelelően hozza létre a jegyzéknevet, amely egyesíti RootNamespace és a relatív fájl elérési útját.

A legtöbb esetben nincs szükség műveletre a fejlesztő részéről, és az alkalmazásnak továbbra is működnie kell. Ha azonban ez a módosítás megszakítja az alkalmazást, a következőkre van lehetőség:

  • Módosítsa a kódot az új jegyzéknévre való várakozáshoz.

  • A projektfájlban való beállítással EmbeddedResourceUseDependentUponConventionfalse tiltsa le az új elnevezési konvenciót.

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

Kategória

Msbuild

Érintett API-k

n/a

Hálózatkezelés

A HttpRequestMessage.Version alapértelmezett értéke 1.1-re módosult

A tulajdonság alapértelmezett értéke System.Net.Http.HttpRequestMessage.Version 2,0-ról 1,1-re módosult.

Bevezetett verzió

3,0

Módosítás leírása

A .NET Core 1.0-2.0-s verziójában a System.Net.Http.HttpRequestMessage.Version tulajdonság alapértelmezett értéke 1,1. A .NET Core 2.1-től kezdve 2.1-re módosult.

A .NET Core 3.0-tól kezdődően a System.Net.Http.HttpRequestMessage.Version tulajdonság által visszaadott alapértelmezett verziószám ismét 1.1.

Frissítse a kódot, ha az attól függ, hogy a System.Net.Http.HttpRequestMessage.Version tulajdonság 2.0-s alapértelmezett értéket ad vissza.

Kategória

Hálózatkezelés

Érintett API-k

Lásd még