Belangrijke wijzigingen in .NET Core 3.0
Als u migreert naar versie 3.0 van .NET Core, ASP.NET Core of EF Core, kunnen de belangrijke wijzigingen in dit artikel van invloed zijn op uw app.
- Verouderde antiforgery-, CORS-, diagnostische, MVC- en routerings-API's verwijderd
- "Pubternal" API's verwijderd
- Verificatie: Google+ afschaffing
- Verificatie: de eigenschap HttpContext.Authentication is verwijderd
- Verificatie: Newtonsoft.Json-typen vervangen
- Verificatie: OAuthHandler ExchangeCodeAsync-handtekening is gewijzigd
- Autorisatie: Overbelasting van AddAuthorization verplaatst naar een andere assembly
- Autorisatie: IAllowAnonymous verwijderd uit AuthorizationFilterContext.Filters
- Autorisatie: IAuthorizationPolicyProvider-implementaties vereisen een nieuwe methode
- Caching: Eigenschap CompactOnMemoryPressure verwijderd
- Caching: Microsoft.Extensions.Caching.SqlServer maakt gebruik van een nieuw SqlClient-pakket
- Caching: ResponseCaching -typen 'pubternal' zijn gewijzigd in intern
- Gegevensbescherming: DataProtection.Blobs maakt gebruik van nieuwe Azure Storage-API's
- Hosting: AspNetCoreModule V1 verwijderd uit Windows Hosting Bundle
- Hosting: Algemene host beperkt opstartconstructorinjectie
- Hosting: HTTPS-omleiding ingeschakeld voor out-of-process-apps van IIS
- Hosting: IHostingEnvironment- en IApplicationLifetime-typen vervangen
- Hosting: ObjectPoolProvider verwijderd uit WebHostBuilder-afhankelijkheden
- HTTP: DefaultHttpContext-uitbreidbaarheid verwijderd
- HTTP: HeaderNames-velden zijn gewijzigd in statisch lezen
- HTTP: Wijzigingen in de infrastructuur van antwoordtekst
- HTTP: Sommige standaardwaarden van SameSite voor cookies zijn gewijzigd
- HTTP: Synchrone IO is standaard uitgeschakeld
- Identiteit: Overbelasting van methode AddDefaultUI verwijderd
- Identiteit: wijzigingen in de bootstrapversie van de gebruikersinterface
- Identiteit: SignInAsync genereert uitzondering voor niet-geverifieerde identiteit
- Identiteit: SignInManager-constructor accepteert nieuwe parameter
- Identiteit: UI maakt gebruik van de functie statische webassets
- Kestrel: Verbindingsadapters verwijderd
- Kestrel: Lege HTTPS-assembly verwijderd
- Kestrel: Aanvraag trailer headers verplaatst naar nieuwe verzameling
- Kestrel: Wijzigingen in transportabstractielaag
- Lokalisatie: API's gemarkeerd als verouderd
- Logboekregistratie: DebugLogger-klasse intern gemaakt
- MVC: Controlleractie Async-achtervoegsel verwijderd
- MVC: JsonResult is verplaatst naar Microsoft.AspNetCore.Mvc.Core
- MVC: Hulpprogramma voor precompilatie afgeschaft
- MVC: typen gewijzigd in intern
- MVC: Web-API-compatibiliteitsshim verwijderd
- Razor: RazorTemplateEngine-API verwijderd
- Razor: Runtime-compilatie is verplaatst naar een pakket
- Sessiestatus: Verouderde API's verwijderd
- Gedeeld framework: Assembly verwijderen uit Microsoft.AspNetCore.App
- Gedeeld framework: Microsoft.AspNetCore.All verwijderd
- SignalR: HandshakeProtocol.SuccessHandshakeData vervangen
- SignalR: HubConnection-methoden verwijderd
- SignalR: HubConnectionContext-constructors zijn gewijzigd
- SignalR: Naam van JavaScript-clientpakket wijzigen
- SignalR: Verouderde API's
- SPA's: SpaServices en NodeServices gemarkeerd als verouderd
- SPA's: SpaServices- en NodeServices-consolelogger standaardwijziging
- Doelframework: .NET Framework wordt niet ondersteund
Verouderde leden en compatibiliteitsswitches in ASP.NET Core 2.2 zijn verwijderd.
3,0
Verbetering van het API-oppervlak in de loop van de tijd.
Terwijl u zich richt op .NET Core 2.2, volgt u de richtlijnen in de verouderde build-berichten om in plaats daarvan nieuwe API's te gebruiken.
ASP.NET Core
De volgende typen en leden zijn gemarkeerd als verouderd voor ASP.NET Core 2.1 en 2.2:
Typen
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
Constructeurs
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)
Eigenschappen
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
Methoden
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
- Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor,Object)
Om het openbare API-oppervlak van ASP.NET Core beter te behouden, zijn de meeste typen in *.Internal
naamruimten (ook wel API's genoemd "pubternal" ) echt intern geworden. Leden in deze naamruimten waren nooit bedoeld om te worden ondersteund als openbare API's. De API's kunnen worden onderbroken in secundaire releases en vaak wel. Code die afhankelijk is van deze API's, wordt afgebroken bij het bijwerken naar ASP.NET Core 3.0.
Zie dotnet/aspnetcore#4932 en dotnet/aspnetcore#11312 voor meer informatie.
3,0
De betrokken API's worden gemarkeerd met de public
toegangsaanpassing en bestaan in *.Internal
naamruimten.
De betrokken API's worden gemarkeerd met de interne toegangsaanpassing en kunnen niet meer worden gebruikt door code buiten die assembly.
De richtlijnen voor deze "pubternal" API's waren dat ze:
- Kan zonder kennisgeving veranderen.
- Waren niet onderworpen aan .NET-beleid om wijzigingen die fouten veroorzaken te voorkomen.
Het verlaten van de API's public
(zelfs in de *.Internal
naamruimten) was verwarrend voor klanten.
Stop met het gebruik van deze "pubternal" API's. Als u vragen hebt over alternatieve API's, opent u een probleem in de dotnet-/aspnetcore-opslagplaats .
Denk bijvoorbeeld aan de volgende HTTP-aanvraagbuffercode in een ASP.NET Core 2.2-project. De EnableRewind
extensiemethode bestaat in de Microsoft.AspNetCore.Http.Internal
naamruimte.
HttpContext.Request.EnableRewind();
Vervang in een ASP.NET Core 3.0-project de EnableRewind
aanroep door een aanroep naar de EnableBuffering
extensiemethode. De functie voor het bufferen van aanvragen werkt zoals in het verleden. EnableBuffering
roept nu de internal
API aan.
HttpContext.Request.EnableBuffering();
ASP.NET Core
Alle API's in de Microsoft.AspNetCore.*
en Microsoft.Extensions.*
naamruimten met een Internal
segment in de naamruimtenaam. Voorbeeld:
Microsoft.AspNetCore.Authentication.Internal
Microsoft.AspNetCore.Builder.Internal
Microsoft.AspNetCore.DataProtection.Cng.Internal
Microsoft.AspNetCore.DataProtection.Internal
Microsoft.AspNetCore.Hosting.Internal
Microsoft.AspNetCore.Http.Internal
Microsoft.AspNetCore.Mvc.Core.Infrastructure
Microsoft.AspNetCore.Mvc.Core.Internal
Microsoft.AspNetCore.Mvc.Cors.Internal
Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
Microsoft.AspNetCore.Mvc.Formatters.Internal
Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
Microsoft.AspNetCore.Mvc.Internal
Microsoft.AspNetCore.Mvc.ModelBinding.Internal
Microsoft.AspNetCore.Mvc.Razor.Internal
Microsoft.AspNetCore.Mvc.RazorPages.Internal
Microsoft.AspNetCore.Mvc.TagHelpers.Internal
Microsoft.AspNetCore.Mvc.ViewFeatures.Internal
Microsoft.AspNetCore.Rewrite.Internal
Microsoft.AspNetCore.Routing.Internal
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
Microsoft.AspNetCore.Server.Kestrel.Https.Internal
Google begint met het afsluiten van Google+ Aanmelding voor apps vanaf 28 januari 2019.
ASP.NET 4.x en ASP.NET Core hebben de Google+-aanmeldings-API's gebruikt om Google-accountgebruikers in web-apps te verifiëren. De betrokken NuGet-pakketten zijn Microsoft.AspNetCore.Authentication.Google voor ASP.NET Core en Microsoft.Owin.Security.Google voor Microsoft.Owin
ASP.NET Web Forms en MVC.
De vervangende API's van Google gebruiken een andere gegevensbron en -indeling. De oplossingen en oplossingen die hieronder worden geboden, zijn verantwoordelijk voor de structurele veranderingen. Apps moeten controleren of de gegevens zelf nog steeds aan hun vereisten voldoen. Namen, e-mailadressen, profielkoppelingen en profielfoto's kunnen bijvoorbeeld subtly verschillende waarden bevatten dan voorheen.
Alle versies. Deze wijziging is extern voor ASP.NET Core.
Voor Microsoft.Owin
3.1.0 en hoger wordt hier een tijdelijke beperking beschreven. Apps moeten het testen voltooien met de beperking om te controleren op wijzigingen in de gegevensindeling. Er zijn plannen om 4.0.1 met een oplossing vrij te Microsoft.Owin
geven. Apps die een eerdere versie gebruiken, moeten worden bijgewerkt naar versie 4.0.1.
De beperking in Owin met ASP.NET Web Forms en MVC kan worden aangepast aan ASP.NET Core 1.x. NuGet-pakketpatches zijn niet gepland omdat 1.x de levensduur heeft bereikt.
Vervang Microsoft.AspNetCore.Authentication.Google
voor versie 2.x uw bestaande aanroep door AddGoogle
Startup.ConfigureServices
de volgende code:
.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");
});
De patches van 2.1 en 2.2 februari hebben de voorgaande herconfiguratie als de nieuwe standaardinstelling opgenomen. Er is geen patch gepland voor ASP.NET Core 2.0 sinds het einde van de levensduur is bereikt.
De beperking die wordt gegeven voor ASP.NET Core 2.x kan ook worden gebruikt voor ASP.NET Core 3.0. In toekomstige previews van 3.0 kan het Microsoft.AspNetCore.Authentication.Google
pakket worden verwijderd. Gebruikers worden in plaats daarvan omgeleid Microsoft.AspNetCore.Authentication.OpenIdConnect
. De volgende code laat zien hoe u vervangt AddGoogle
door AddOpenIdConnect
in Startup.ConfigureServices
. Deze vervanging kan worden gebruikt met ASP.NET Core 2.0 en hoger en kan indien nodig worden aangepast voor ASP.NET Core 1.x.
.AddOpenIdConnect("Google", o =>
{
o.ClientId = Configuration["Authentication:Google:ClientId"];
o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
o.Authority = "https://accounts.google.com";
o.ResponseType = OpenIdConnectResponseType.Code;
o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
De afgeschafte Authentication
eigenschap is HttpContext
verwijderd.
Als onderdeel van dotnet/aspnetcore#6504 is de afgeschafte Authentication
eigenschap HttpContext
verwijderd. De Authentication
eigenschap is afgeschaft sinds 2.0. Er is een migratiehandleiding gepubliceerd om code te migreren met behulp van deze afgeschafte eigenschap naar de nieuwe vervangende API's. De resterende ongebruikte klassen/API's met betrekking tot de oude ASP.NET Core 1.x-verificatiestack zijn verwijderd in commit dotnet/aspnetcore@d7a7c65.
Zie dotnet/aspnetcore#6533 voor discussie.
3,0
ASP.NET Core 1.0 API's zijn vervangen door extensiemethoden in Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Zie de migratiehandleiding.
ASP.NET Core
- Microsoft.AspNetCore.Http.Authentication.AuthenticateInfo
- Microsoft.AspNetCore.Http.Authentication.AuthenticationManager
- Microsoft.AspNetCore.Http.Authentication.AuthenticationProperties
- Microsoft.AspNetCore.Http.Features.Authentication.AuthenticateContext
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeBehavior
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeContext
- Microsoft.AspNetCore.Http.Features.Authentication.DescribeSchemesContext
- Microsoft.AspNetCore.Http.Features.Authentication.IAuthenticationHandler
- Microsoft.AspNetCore.Http.Features.Authentication.IHttpAuthenticationFeature.Handler
- Microsoft.AspNetCore.Http.Features.Authentication.SignInContext
- Microsoft.AspNetCore.Http.Features.Authentication.SignOutContext
- Microsoft.AspNetCore.Http.HttpContext.Authentication
In ASP.NET Core 3.0 Newtonsoft.Json
zijn typen die worden gebruikt in verificatie-API's vervangen door System.Text.Json
typen. Met uitzondering van de volgende gevallen blijft het basisgebruik van de verificatiepakketten ongewijzigd:
- Klassen die zijn afgeleid van de OAuth-providers, zoals die van aspnet-contrib.
- Geavanceerde implementaties voor claimmanipulatie.
Zie dotnet/aspnetcore#7105 voor meer informatie. Zie dotnet/aspnetcore#7289 voor discussie.
3,0
Voor afgeleide OAuth-implementaties is de meest voorkomende wijziging het vervangen JObject.Parse
JsonDocument.Parse
door in de CreateTicketAsync
onderdrukking, zoals hier wordt weergegeven. JsonDocument
implementeert IDisposable
.
De volgende lijst bevat een overzicht van bekende wijzigingen:
- ClaimAction.Run(JObject, ClaimsIdentity, String) wordt
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
. Alle afgeleide implementaties vanClaimAction
worden op dezelfde manier beïnvloed. - ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) Wordt
MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
- ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, String, Func<JObject,String>) Wordt
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
- OAuthCreatingTicketContext heeft één oude constructor verwijderd en de andere vervangen
JObject
doorJsonElement
. DeUser
eigenschap enRunClaimActions
methode zijn bijgewerkt zodat deze overeenkomen. - Success(JObject) accepteert nu een parameter van het type
JsonDocument
in plaats vanJObject
. DeResponse
eigenschap is bijgewerkt zodat deze overeenkomt.OAuthTokenResponse
is nu wegwerpbaar en zal worden verwijderd doorOAuthHandler
. Afgeleide OAuth-implementaties die worden overschrevenExchangeCodeAsync
, hoeven deJsonDocument
ofOAuthTokenResponse
niet te verwijderen. - UserInformationReceivedContext.User gewijzigd van
JObject
inJsonDocument
. - TwitterCreatingTicketContext.User gewijzigd van
JObject
inJsonElement
. - De laatste parameter van TwitterHandler.CreateTicketAsync(ClaimsIdentity,AuthenticationProperties,AccessToken,JObject) is gewijzigd van
JObject
inJsonElement
. De vervangingsmethode is TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).
ASP.NET Core
- Microsoft.AspNetCore.Authentication.Facebook
- Microsoft.AspNetCore.Authentication.Google
- Microsoft.AspNetCore.Authentication.MicrosoftAccount
- Microsoft.AspNetCore.Authentication.OAuth
- Microsoft.AspNetCore.Authentication.OpenIdConnect
- Microsoft.AspNetCore.Authentication.Twitter
In ASP.NET Core 3.0 is de handtekening OAuthHandler.ExchangeCodeAsync
gewijzigd van:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }
Aan:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }
3,0
De code
en redirectUri
tekenreeksen zijn doorgegeven als afzonderlijke argumenten.
Code
en RedirectUri
zijn eigenschappen OAuthCodeExchangeContext
die kunnen worden ingesteld via de OAuthCodeExchangeContext
constructor. Het nieuwe OAuthCodeExchangeContext
type is het enige argument dat wordt doorgegeven aan OAuthHandler.ExchangeCodeAsync
.
Met deze wijziging kunnen extra parameters op een niet-brekende manier worden opgegeven. Het is niet nodig om nieuwe ExchangeCodeAsync
overbelastingen te maken.
Maak een OAuthCodeExchangeContext
met de juiste code
waarden en redirectUri
waarden. Er moet een AuthenticationProperties exemplaar worden opgegeven. Dit ene OAuthCodeExchangeContext
exemplaar kan worden doorgegeven aan OAuthHandler.ExchangeCodeAsync
in plaats van meerdere argumenten.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
De belangrijkste AddAuthorization
methoden waarin zich bevonden Microsoft.AspNetCore.Authorization
, zijn hernoemd in AddAuthorizationCore
. De oude AddAuthorization
methoden bestaan nog steeds, maar bevinden zich in de Microsoft.AspNetCore.Authorization.Policy
assembly. Apps die beide methoden gebruiken, hebben geen invloed. Houd er rekening mee dat Microsoft.AspNetCore.Authorization.Policy
nu wordt geleverd in het gedeelde framework in plaats van een zelfstandig pakket, zoals besproken in Gedeeld framework: Assembly's verwijderd uit Microsoft.AspNetCore.App.
3,0
AddAuthorization
methoden bestonden in Microsoft.AspNetCore.Authorization
.
AddAuthorization
methoden bestaan in Microsoft.AspNetCore.Authorization.Policy
. AddAuthorizationCore
is de nieuwe naam voor de oude methoden.
AddAuthorization
is een betere methodenaam voor het toevoegen van alle algemene services die nodig zijn voor autorisatie.
Voeg in plaats daarvan een verwijzing naar Microsoft.AspNetCore.Authorization.Policy
of gebruik AddAuthorizationCore
toe.
ASP.NET Core
Vanaf ASP.NET Core 3.0 voegt MVC geen AllowAnonymousFilters toe voor [AllowAnonymous]-kenmerken die zijn gedetecteerd op controllers en actiemethoden. Deze wijziging wordt lokaal aangepakt voor derivaten van AuthorizeAttribute, maar het is een belangrijke wijziging voor IAsyncAuthorizationFilter en IAuthorizationFilter implementaties. Dergelijke implementaties die zijn verpakt in een kenmerk [TypeFilter] zijn een populaire en ondersteunde manier om sterk getypte autorisatie op basis van kenmerken te bereiken wanneer zowel configuratie- als afhankelijkheidsinjectie vereist zijn.
3,0
IAllowAnonymous weergegeven in de verzameling AuthorizationFilterContext.Filters . Testen op de aanwezigheid van de interface was een geldige methode om het filter op afzonderlijke controllermethoden te overschrijven of uit te schakelen.
IAllowAnonymous
wordt niet meer weergegeven in de AuthorizationFilterContext.Filters
verzameling. IAsyncAuthorizationFilter
implementaties die afhankelijk zijn van het oude gedrag veroorzaken meestal onregelmatige HTTP 401 Niet-geautoriseerde of HTTP 403 Verboden antwoorden.
Er is een nieuwe strategie voor eindpuntroutering geïntroduceerd in ASP.NET Core 3.0.
Zoek in de metagegevens van het eindpunt naar IAllowAnonymous
. Voorbeeld:
var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}
Een voorbeeld van deze techniek is te zien in deze HasAllowAnonymous methode.
ASP.NET Core
Geen
In ASP.NET Core 3.0 is een nieuwe GetFallbackPolicyAsync
methode toegevoegd aan IAuthorizationPolicyProvider
. Dit terugvalbeleid wordt gebruikt door de autorisatie-middleware wanneer er geen beleid is opgegeven.
Zie dotnet/aspnetcore#9759 voor meer informatie.
3,0
Implementaties van IAuthorizationPolicyProvider
hebben geen methode nodig GetFallbackPolicyAsync
.
Implementaties van IAuthorizationPolicyProvider
vereisen een GetFallbackPolicyAsync
methode.
Er is een nieuwe methode nodig voor het nieuwe AuthorizationMiddleware
te gebruiken wanneer er geen beleid is opgegeven.
Voeg de GetFallbackPolicyAsync
methode toe aan uw implementaties van IAuthorizationPolicyProvider
.
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
De ASP.NET Core 3.0-release heeft de verouderde MemoryCacheOptions-API's verwijderd.
Deze wijziging is een vervolg op aspnet/Caching#221. Zie dotnet/extensions#1062 voor discussie.
3,0
MemoryCacheOptions.CompactOnMemoryPressure
eigenschap was beschikbaar.
De MemoryCacheOptions.CompactOnMemoryPressure
eigenschap is verwijderd.
Het automatisch comprimeren van de cache heeft problemen veroorzaakt. Om onverwacht gedrag te voorkomen, moet de cache alleen worden gecomprimeerd wanneer dat nodig is.
Als u de cache wilt comprimeren, kunt u downcasten naar MemoryCache
en aanroepen Compact
wanneer dat nodig is.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
Het Microsoft.Extensions.Caching.SqlServer
pakket gebruikt het nieuwe Microsoft.Data.SqlClient
pakket in plaats van System.Data.SqlClient
het pakket. Deze wijziging kan kleine gedragswijzigingen veroorzaken. Zie Inleiding tot de nieuwe Microsoft.Data.SqlClient voor meer informatie.
3,0
Het Microsoft.Extensions.Caching.SqlServer
pakket heeft het System.Data.SqlClient
pakket gebruikt.
Microsoft.Extensions.Caching.SqlServer
maakt nu gebruik van het Microsoft.Data.SqlClient
pakket.
Microsoft.Data.SqlClient
is een nieuw pakket dat is gebouwd op System.Data.SqlClient
. Hier wordt vanaf nu alle nieuwe functiewerkzaamheden uitgevoerd.
Klanten hoeven zich geen zorgen te maken over deze belangrijke wijziging, tenzij ze typen gebruikten die door het Microsoft.Extensions.Caching.SqlServer
pakket zijn geretourneerd en ze naar typen casten System.Data.SqlClient
. Als iemand bijvoorbeeld een DbConnection
cast-bestand naar het oude SqlConnection-type heeft gecast, moeten ze de cast wijzigen in het nieuwe Microsoft.Data.SqlClient.SqlConnection
type.
ASP.NET Core
Geen
In ASP.NET Core 3.0 zijn 'pubternal'-typen gewijzigd internal
in ResponseCaching
.
Daarnaast worden standaard implementaties van IResponseCachingPolicyProvider
en IResponseCachingKeyProvider
niet meer toegevoegd aan services als onderdeel van de AddResponseCaching
methode.
In ASP.NET Core worden 'pubternale' typen gedeclareerd als public
maar bevinden zich in een naamruimteachtervoegsel met .Internal
. Hoewel deze typen openbaar zijn, hebben ze geen ondersteuningsbeleid en zijn ze onderhevig aan wijzigingen die fouten veroorzaken. Helaas is het onbedoeld gebruik van deze typen gebruikelijk, wat resulteert in belangrijke wijzigingen in deze projecten en het beperken van de mogelijkheid om het framework te onderhouden.
3,0
Deze typen zijn openbaar zichtbaar, maar niet ondersteund.
Deze typen zijn nu internal
.
Het internal
bereik weerspiegelt het niet-ondersteunde beleid beter.
Kopieertypen die worden gebruikt door uw app of bibliotheek.
ASP.NET Core
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
- Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.ResponseCachingMiddleware(RequestDelegate, IOptions<ResponseCachingOptions>, ILoggerFactory, IResponseCachingPolicyProvider, IResponseCache, IResponseCachingKeyProvider)
Azure.Extensions.AspNetCore.DataProtection.Blobs
is afhankelijk van de Azure Storage-bibliotheken. Deze bibliotheken hebben de naam van hun assembly's, pakketten en naamruimten gewijzigd. Vanaf ASP.NET Core 3.0 worden Azure.Extensions.AspNetCore.DataProtection.Blobs
de nieuwe Azure.Storage.
voorvoegsel-API's en pakketten gebruikt.
Gebruik voor vragen over de Azure Storage-API's https://github.com/Azure/azure-storage-net. Zie dotnet/aspnetcore#19570 voor discussie over dit probleem.
3,0
Het pakket verwijst naar het WindowsAzure.Storage
NuGet-pakket.
Het pakket verwijst naar het Microsoft.Azure.Storage.Blob
NuGet-pakket.
Het pakket verwijst naar het Azure.Storage.Blob
NuGet-pakket.
Met deze wijziging kunt Azure.Extensions.AspNetCore.DataProtection.Blobs
u migreren naar de aanbevolen Azure Storage-pakketten.
Als u nog steeds de oudere Azure Storage-API's wilt gebruiken met ASP.NET Core 3.0, voegt u een directe afhankelijkheid toe aan het pakket WindowsAzure.Storage of Microsoft.Azure.Storage. Dit pakket kan naast de nieuwe Azure.Storage
API's worden geïnstalleerd.
In veel gevallen omvat de upgrade alleen het wijzigen van de using
instructies voor het gebruik van de nieuwe naamruimten:
- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;
ASP.NET Core
Geen
Vanaf ASP.NET Core 3.0 bevat de Windows Hosting Bundle geen ASPNetCoreModule (ANCM) V1.
ANCM V2 is achterwaarts compatibel met ANCM OutOfProcess en wordt aanbevolen voor gebruik met ASP.NET Core 3.0-apps.
Zie dotnet/aspnetcore#7095 voor discussie.
3,0
ANCM V1 is opgenomen in de Windows Hosting Bundle.
ANCM V1 is niet opgenomen in de Windows Hosting Bundle.
ANCM V2 is achterwaarts compatibel met ANCM OutOfProcess en wordt aanbevolen voor gebruik met ASP.NET Core 3.0-apps.
ANCM V2 gebruiken met ASP.NET Core 3.0-apps.
Als ANCM V1 is vereist, kan deze worden geïnstalleerd met behulp van de ASP.NET Core 2.1 of 2.2 Windows Hosting Bundle.
Deze wijziging wordt verbroken ASP.NET Core 3.0-apps die:
- Expliciet gekozen voor het gebruik van ANCM V1 met
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
. - Een aangepast web.config-bestand met
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
.
ASP.NET Core
Geen
De enige typen die de algemene host ondersteunt voor Startup
klasseconstructorinjectie zijn IHostEnvironment
, IWebHostEnvironment
en IConfiguration
. Apps die worden gebruikt WebHost
, worden niet beïnvloed.
Vóór ASP.NET Core 3.0 kan de constructorinjectie worden gebruikt voor willekeurige typen in de Startup
klasseconstructor. In ASP.NET Core 3.0 is de webstack opnieuw geplatformeerd op de algemene hostbibliotheek. U ziet de wijziging in het Program.cs bestand van de sjablonen:
ASP.NET Core 2.x:
ASP.NET Core 3.0:
Host
gebruikt één afhankelijkheidsinjectiecontainer (DI) om de app te bouwen. WebHost
maakt gebruik van twee containers: één voor de host en één voor de app. Als gevolg hiervan biedt de Startup
constructor geen ondersteuning meer voor aangepaste service-injectie. Alleen IHostEnvironment
, IWebHostEnvironment
en IConfiguration
kunnen worden geïnjecteerd. Deze wijziging voorkomt DI-problemen, zoals het dupliceren van een singleton-service.
3,0
Deze wijziging is het gevolg van het opnieuw platformeren van de webstack naar de algemene hostbibliotheek.
Injecteer services in de Startup.Configure
methodehandtekening. Voorbeeld:
public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
ASP.NET Core
Geen
Versie 13.0.19218.0 van de ASP.NET Core Module (ANCM) voor het hosten via out-of-process van IIS maakt een bestaande HTTPS-omleidingsfunctie mogelijk voor ASP.NET Core 3.0- en 2.2-apps.
Zie dotnet/AspNetCore#15243 voor discussie.
3,0
De ASP.NET Core 2.1-projectsjabloon introduceerde eerst ondersteuning voor HTTPS-middlewaremethoden zoals UseHttpsRedirection en UseHsts. Voor het inschakelen van HTTPS-omleiding is de toevoeging van de configuratie vereist, omdat apps in ontwikkeling niet de standaardpoort van 443 gebruiken. HTTP Strict Transport Security (HSTS) is alleen actief als de aanvraag al https gebruikt. Localhost wordt standaard overgeslagen.
In ASP.NET Core 3.0 is het IIS HTTPS-scenario uitgebreid. Met de uitbreiding kan een app de HTTPS-poorten van de server detecteren en UseHttpsRedirection
standaard werken. Het in-process-onderdeel heeft poortdetectie bereikt met de IServerAddresses
functie, die alleen van invloed is op ASP.NET Core 3.0-apps, omdat de bibliotheek in de procesbibliotheek versiebeheer heeft met het framework. Het out-of-process-onderdeel is gewijzigd om automatisch de ASPNETCORE_HTTPS_PORT
omgevingsvariabele toe te voegen. Deze wijziging heeft betrekking op zowel ASP.NET Core 2.2- als 3.0-apps omdat het out-of-process-onderdeel wereldwijd wordt gedeeld. ASP.NET Core 2.1-apps worden niet beïnvloed omdat ze standaard een eerdere versie van ANCM gebruiken.
Het voorgaande gedrag is gewijzigd in ASP.NET Core 3.0.1 en 3.1.0 Preview 3 om de gedragswijzigingen in ASP.NET Core 2.x om te keren. Deze wijzigingen zijn alleen van invloed op niet-verwerkte IIS-apps.
Zoals hierboven beschreven, had het installeren van ASP.NET Core 3.0.0 het neveneffect van het activeren van de UseHttpsRedirection
middleware in ASP.NET Core 2.x-apps. Er is een wijziging aangebracht in ANCM in ASP.NET Core 3.0.1 en 3.1.0 Preview 3, zodat het installeren ervan niet langer van invloed is op ASP.NET Core 2.x-apps. De ASPNETCORE_HTTPS_PORT
omgevingsvariabele die ANCM in ASP.NET Core 3.0.0 heeft ingevuld, is gewijzigd ASPNETCORE_ANCM_HTTPS_PORT
in ASP.NET Core 3.0.1 en 3.1.0 Preview 3. UseHttpsRedirection
is ook bijgewerkt in deze releases om inzicht te hebben in zowel de nieuwe als de oude variabelen. ASP.NET Core 2.x wordt niet bijgewerkt. Als gevolg hiervan wordt het vorige gedrag van standaard uitgeschakeld.
Verbeterde ASP.NET Core 3.0-functionaliteit.
Er is geen actie vereist als u wilt dat alle clients HTTPS gebruiken. Voer een van de volgende stappen uit om toe te staan dat sommige clients HTTP gebruiken:
Verwijder de aanroepen van
UseHttpsRedirection
enUseHsts
naar de methode vanStartup.Configure
uw project en implementeer de app opnieuw.Stel in uw web.config-bestand de
ASPNETCORE_HTTPS_PORT
omgevingsvariabele in op een lege tekenreeks. Deze wijziging kan rechtstreeks op de server plaatsvinden zonder de app opnieuw te implementeren. Voorbeeld:<aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" > <environmentVariables> <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" /> </environmentVariables> </aspNetCore>
UseHttpsRedirection
kan nog steeds het volgende zijn:
- Handmatig geactiveerd in ASP.NET Core 2.x door de
ASPNETCORE_HTTPS_PORT
omgevingsvariabele in te stellen op het juiste poortnummer (443 in de meeste productiescenario's). - Gedeactiveerd in ASP.NET Core 3.x door te definiëren
ASPNETCORE_ANCM_HTTPS_PORT
met een lege tekenreekswaarde. Deze waarde wordt op dezelfde manier ingesteld als in het voorgaandeASPNETCORE_HTTPS_PORT
voorbeeld.
Machines waarop ASP.NET Core 3.0.0-apps worden uitgevoerd, moeten de ASP.NET Core 3.0.1-runtime installeren voordat u de ANCM van ASP.NET Core 3.1.0 Preview 3 installeert. Dit zorgt ervoor dat UseHttpsRedirection
de ASP.NET Core 3.0-apps blijven werken zoals verwacht.
In Azure-app Service wordt ANCM geïmplementeerd volgens een afzonderlijk schema van de runtime vanwege de globale aard ervan. ANCM is geïmplementeerd in Azure met deze wijzigingen nadat ASP.NET Core 3.0.1 en 3.1.0 zijn geïmplementeerd.
ASP.NET Core
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Er zijn nieuwe typen geïntroduceerd om bestaande IHostingEnvironment
en IApplicationLifetime
typen te vervangen.
3,0
Er waren twee verschillende IHostingEnvironment
en IApplicationLifetime
typen van Microsoft.Extensions.Hosting
en Microsoft.AspNetCore.Hosting
.
De oude typen zijn gemarkeerd als verouderd en vervangen door nieuwe typen.
Wanneer Microsoft.Extensions.Hosting
is geïntroduceerd in ASP.NET Core 2.1, sommige typen zoals IHostingEnvironment
en IApplicationLifetime
zijn gekopieerd uit Microsoft.AspNetCore.Hosting
. Sommige ASP.NET Core 3.0-wijzigingen zorgen ervoor dat apps zowel de als de Microsoft.Extensions.Hosting
Microsoft.AspNetCore.Hosting
naamruimten bevatten. Elk gebruik van deze dubbele typen veroorzaakt een 'dubbelzinnige verwijzing' compilerfout wanneer naar beide naamruimten wordt verwezen.
Vervang het gebruik van de oude typen door de nieuw geïntroduceerde typen, zoals hieronder:
Verouderde typen (waarschuwing):
- Microsoft.Extensions.Hosting.IHostingEnvironment
- Microsoft.AspNetCore.Hosting.IHostingEnvironment
- Microsoft.Extensions.Hosting.IApplicationLifetime
- Microsoft.AspNetCore.Hosting.IApplicationLifetime
- Microsoft.Extensions.Hosting.EnvironmentName
- Microsoft.AspNetCore.Hosting.EnvironmentName
Nieuwe typen:
- Microsoft.Extensions.Hosting.IHostEnvironment
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
- Microsoft.Extensions.Hosting.IHostApplicationLifetime
- Microsoft.Extensions.Hosting.Environments
De nieuwe IHostEnvironment
IsDevelopment
en IsProduction
extensiemethoden bevinden zich in de Microsoft.Extensions.Hosting
naamruimte. Deze naamruimte moet mogelijk worden toegevoegd aan uw project.
ASP.NET Core
- Microsoft.AspNetCore.Hosting.EnvironmentName
- Microsoft.AspNetCore.Hosting.IApplicationLifetime
- Microsoft.AspNetCore.Hosting.IHostingEnvironment
- Microsoft.Extensions.Hosting.EnvironmentName
- Microsoft.Extensions.Hosting.IApplicationLifetime
- Microsoft.Extensions.Hosting.IHostingEnvironment
Als onderdeel van het maken van ASP.NET Core meer betalen voor play, is de ObjectPoolProvider
functie verwijderd uit de hoofdset van afhankelijkheden. Specifieke onderdelen die erop vertrouwen ObjectPoolProvider
, voegen deze nu zelf toe.
Zie dotnet/aspnetcore#5944 voor discussie.
3,0
WebHostBuilder
biedt ObjectPoolProvider
standaard in de DI-container.
WebHostBuilder
biedt ObjectPoolProvider
niet meer standaard in de DI-container.
Deze wijziging is aangebracht om ASP.NET Core meer te betalen voor play.
Als uw onderdeel dit vereist ObjectPoolProvider
, moet het worden toegevoegd aan uw afhankelijkheden via de IServiceCollection
.
ASP.NET Core
Geen
Als onderdeel van ASP.NET Core 3.0-prestatieverbeteringen is de uitbreidbaarheid verwijderd DefaultHttpContext
. De klas is nu sealed
. Zie dotnet/aspnetcore#6504 voor meer informatie.
Als in uw eenheidstests gebruik wordt gemaakt Mock<DefaultHttpContext>
van, gebruikt Mock<HttpContext>
u of new DefaultHttpContext()
in plaats daarvan.
Zie dotnet/aspnetcore#6534 voor discussie.
3,0
Klassen kunnen worden afgeleid van DefaultHttpContext
.
Klassen kunnen niet worden afgeleid van DefaultHttpContext
.
De uitbreidbaarheid werd aanvankelijk geboden om pooling van de HttpContext
, maar het introduceerde onnodige complexiteit en belemmerde andere optimalisaties.
Als u in uw eenheidstests werkt Mock<DefaultHttpContext>
, gaat u in plaats daarvan aan de slag Mock<HttpContext>
.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
Vanaf ASP.NET Core 3.0 Preview 5 zijn de velden in Microsoft.Net.Http.Headers.HeaderNames gewijzigd van const
.static readonly
Zie dotnet/aspnetcore#9514 voor discussie.
3,0
Deze velden waren const
vroeger .
Deze velden zijn nu static readonly
.
De wijziging:
- Hiermee voorkomt u dat de waarden worden ingesloten over de grenzen van de assembly, waardoor waardecorrecties naar behoefte mogelijk zijn.
- Maakt snellere referentie gelijkheidscontroles mogelijk.
Hercompileren op basis van 3.0. Broncode die deze velden gebruikt, kan dit op de volgende manieren niet meer:
- Als kenmerkargument
- Als een in een
case
switch
instructie - Bij het definiëren van een andere
const
Als u de wijziging die fouten veroorzaken wilt omzeilen, schakelt u over naar het gebruik van zelfgedefinieerde headernaamconstanten of letterlijke tekenreeksen.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
De infrastructuur van een HTTP-antwoordtekst is gewijzigd. Als u rechtstreeks gebruikt HttpResponse
, hoeft u geen codewijzigingen aan te brengen. Lees verder als u inpakt of vervangt HttpResponse.Body
of opent HttpContext.Features
.
3,0
Er zijn drie API's gekoppeld aan de HTTP-antwoordtekst:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
Als u deze vervangt HttpResponse.Body
, wordt het geheel IHttpResponseBodyFeature
vervangen door een wrapper rond uw opgegeven stream met behulp van StreamResponseBodyFeature
standaardimplementaties voor alle verwachte API's. Als u de oorspronkelijke stroom terug instelt, wordt deze wijziging teruggezet.
De motivatie is om de antwoordtekst-API's te combineren tot één nieuwe functie-interface.
Gebruik IHttpResponseBodyFeature
waar u eerder gebruikte IHttpResponseFeature.Body
, IHttpSendFileFeature
of IHttpBufferingFeature
.
ASP.NET Core
- Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
- Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
- Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
SameSite
is een optie voor cookies waarmee sommige CSRF-aanvallen (Cross-Site Request Forgery) kunnen worden beperkt. Toen deze optie in eerste instantie werd geïntroduceerd, werden inconsistente standaardwaarden gebruikt in verschillende ASP.NET Core-API's. De inconsistentie heeft tot verwarrende resultaten geleid. Vanaf ASP.NET Core 3.0 zijn deze standaardwaarden beter uitgelijnd. U moet zich per onderdeel aanmelden voor deze functie.
3,0
Vergelijkbare ASP.NET Core-API's hebben verschillende standaardwaarden SameSiteMode gebruikt. Een voorbeeld van de inconsistentie wordt gezien in HttpResponse.Cookies.Append(String, String)
en HttpResponse.Cookies.Append(String, String, CookieOptions)
, die respectievelijk is ingesteld SameSiteMode.None
op en SameSiteMode.Lax
, respectievelijk.
Alle betrokken API's zijn standaard ingesteld SameSiteMode.None
op .
De standaardwaarde is gewijzigd om een opt-in-functie te maken SameSite
.
Elk onderdeel dat cookies verzendt, moet beslissen of SameSite
dit geschikt is voor de scenario's. Controleer uw gebruik van de betrokken API's en configureer SameSite
indien nodig opnieuw.
ASP.NET Core
Vanaf ASP.NET Core 3.0 worden synchrone serverbewerkingen standaard uitgeschakeld.
AllowSynchronousIO
is een optie op elke server die synchrone IO-API's zoals HttpRequest.Body.Read
, HttpResponse.Body.Write
en Stream.Flush
. Deze API's zijn al lang een bron van thread-starvatie en app loopt vast. Vanaf ASP.NET Core 3.0 Preview 3 zijn deze synchrone bewerkingen standaard uitgeschakeld.
Betrokken servers:
- Kestrel
- HttpSys
- IIS wordt verwerkt
- TestServer
Verwacht fouten die vergelijkbaar zijn met:
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.
Elke server heeft een AllowSynchronousIO
optie waarmee dit gedrag wordt bepaald en de standaardwaarde voor alle servers is nu false
.
Het gedrag kan ook per aanvraag worden overschreven als een tijdelijke beperking. Voorbeeld:
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Als u problemen ondervindt met een TextWriter
of een andere stream waarin een synchrone API Dispose
wordt aangeroepen, roept u in plaats daarvan de nieuwe DisposeAsync
API aan.
Zie dotnet/aspnetcore#7644 voor discussie.
3,0
HttpRequest.Body.Read
, HttpResponse.Body.Write
en Stream.Flush
standaard zijn toegestaan.
Deze synchrone API's zijn standaard niet toegestaan:
Verwacht fouten die vergelijkbaar zijn met:
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.
Deze synchrone API's zijn al lang een bron van thread-starvatie en app loopt vast. Vanaf ASP.NET Core 3.0 Preview 3 zijn de synchrone bewerkingen standaard uitgeschakeld.
Gebruik de asynchrone versies van de methoden. Het gedrag kan ook per aanvraag worden overschreven als een tijdelijke beperking.
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
ASP.NET Core
Vanaf ASP.NET Core 3.0 bestaat de methode IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) niet meer.
3,0
Deze wijziging is het gevolg van de acceptatie van de functie statische webactiva.
Aanroepen IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) in plaats van de overbelasting waarvoor twee argumenten nodig zijn. Als u Bootstrap 3 gebruikt, voegt u ook de volgende regel toe aan een <PropertyGroup>
element in uw projectbestand:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
Vanaf ASP.NET Core 3.0 wordt de identiteitsgebruikersinterface standaard gebruikt met versie 4 van Bootstrap.
3,0
De services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
methode-aanroep was hetzelfde als services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
De services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
methode-aanroep is hetzelfde als services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
Bootstrap 4 is uitgebracht tijdens ASP.NET Core 3.0-tijdsbestek.
Dit heeft gevolgen voor deze wijziging als u de standaardidentiteitsgebruikersinterface gebruikt en deze hebt toegevoegd Startup.ConfigureServices
, zoals wordt weergegeven in het volgende voorbeeld:
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
Ga in dat geval op een van de volgende manieren te werk:
Migreer uw app om Bootstrap 4 te gebruiken met behulp van hun migratiehandleiding.
Update
Startup.ConfigureServices
voor het afdwingen van het gebruik van Bootstrap 3. Voorbeeld:services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
ASP.NET Core
Geen
Genereert standaard SignInAsync
een uitzondering voor principals/identiteiten waarin IsAuthenticated
.false
3,0
SignInAsync
accepteert alle principals/identiteiten, inclusief identiteiten waarin IsAuthenticated
.false
Genereert standaard SignInAsync
een uitzondering voor principals/identiteiten waarin IsAuthenticated
.false
Er is een nieuwe vlag om dit gedrag te onderdrukken, maar het standaardgedrag is gewijzigd.
Het oude gedrag was problematisch omdat deze principals standaard zijn afgewezen door [Authorize]
/ RequireAuthenticatedUser()
.
In ASP.NET Core 3.0 Preview 6 is standaard een RequireAuthenticatedSignIn
vlag AuthenticationOptions
true
ingeschakeld. Stel deze vlag in om false
het oude gedrag te herstellen.
ASP.NET Core
Geen
Vanaf ASP.NET Core 3.0 is er een nieuwe IUserConfirmation<TUser>
parameter toegevoegd aan de SignInManager
constructor. Zie dotnet/aspnetcore#8356 voor meer informatie.
3,0
De motivatie voor de wijziging was het toevoegen van ondersteuning voor nieuwe e-mail-/bevestigingsstromen in Identiteit.
Als u handmatig een SignInManager
afhankelijkheidsinjectie maakt, geeft u een implementatie van IUserConfirmation
of pakt u een van de afhankelijkheidsinjectie die u wilt leveren.
ASP.NET Core
ASP.NET Core 3.0 heeft een functie voor statische webactiva geïntroduceerd en de gebruikersinterface van identiteit heeft deze gebruikt.
Als gevolg van de identiteitsgebruikersinterface die de functie statische webassets aanneemt:
- Frameworkselectie wordt bereikt met behulp van de
IdentityUIFrameworkVersion
eigenschap in uw projectbestand. - Bootstrap 4 is het standaard UI-framework voor identiteitsgebruikersinterface. Bootstrap 3 heeft het einde van de levensduur bereikt en u moet overwegen om te migreren naar een ondersteunde versie.
3,0
Het standaard UI-framework voor identiteitsgebruikersinterface was Bootstrap 3. Het UI-framework kan worden geconfigureerd met behulp van een parameter voor de AddDefaultUI
methode-aanroep in Startup.ConfigureServices
.
Het standaard UI-framework voor identiteitsgebruikersinterface is Bootstrap 4. Het UI-framework moet worden geconfigureerd in uw projectbestand, in plaats van in de AddDefaultUI
methode-aanroep.
Acceptatie van de functie statische webassets vereist dat de configuratie van het UI-framework wordt verplaatst naar MSBuild. De beslissing over het insluiten van een framework is een beslissing op basis van een buildtijd, niet een runtimebeslissing.
Controleer de gebruikersinterface van uw site om ervoor te zorgen dat de nieuwe Bootstrap 4-onderdelen compatibel zijn. Gebruik indien nodig de IdentityUIFrameworkVersion
eigenschap MSBuild om terug te keren naar Bootstrap 3. Voeg de eigenschap toe aan een <PropertyGroup>
element in uw projectbestand:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
Als onderdeel van de verplaatsing om "pubternale" API's te verplaatsen naar public
, is het concept van een IConnectionAdapter
uit Kestrel verwijderd. Verbindingsadapters worden vervangen door middleware voor verbindingen (vergelijkbaar met HTTP-middleware in de ASP.NET Core-pijplijn, maar voor verbindingen met een lager niveau). HTTPS en logboekregistratie van verbindingen zijn verplaatst van verbindingsadapters naar middleware voor verbindingen. Deze uitbreidingsmethoden moeten naadloos blijven werken, maar de implementatiedetails zijn gewijzigd.
Zie dotnet/aspnetcore#11412 voor meer informatie. Zie dotnet/aspnetcore#11475 voor discussie.
3,0
Kestrel-uitbreidbaarheidsonderdelen zijn gemaakt met behulp van IConnectionAdapter
.
Kestrel-uitbreidbaarheidsonderdelen worden gemaakt als middleware.
Deze wijziging is bedoeld om een flexibelere uitbreidbaarheidsarchitectuur te bieden.
Converteer eventuele implementaties van het gebruik van IConnectionAdapter
het nieuwe middlewarepatroon, zoals hier wordt weergegeven.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
De assembly Microsoft.AspNetCore.Server.Kestrel.Https is verwijderd.
3,0
In ASP.NET Core 2.1 is de inhoud Microsoft.AspNetCore.Server.Kestrel.Https
verplaatst naar Microsoft.AspNetCore.Server.Kestrel.Core. Deze wijziging is op een niet-brekende manier uitgevoerd met behulp van [TypeForwardedTo]
kenmerken.
- Bibliotheken die naar 2.0 verwijzen
Microsoft.AspNetCore.Server.Kestrel.Https
, moeten alle ASP.NET kernafhankelijkheden bijwerken naar 2.1 of hoger. Anders kunnen ze breken wanneer ze in een ASP.NET Core 3.0-app worden geladen. - Apps en bibliotheken die zijn gericht op ASP.NET Core 2.1 en hoger, moeten eventuele directe verwijzingen naar het
Microsoft.AspNetCore.Server.Kestrel.Https
NuGet-pakket verwijderen.
ASP.NET Core
Geen
In eerdere versies heeft Kestrel gesegmenteerde http/1.1 gesegmenteerde trailerheaders toegevoegd aan de verzameling aanvraagheaders toen de aanvraagbody tot het einde werd gelezen. Dit gedrag heeft zorgen veroorzaakt over dubbelzinnigheid tussen headers en trailers. De beslissing is genomen om de trailers naar een nieuwe collectie te verplaatsen.
HTTP/2-aanvraagtrailers waren niet beschikbaar in ASP.NET Core 2.2, maar zijn nu ook beschikbaar in deze nieuwe verzameling in ASP.NET Core 3.0.
Er zijn nieuwe aanvraaguitbreidingsmethoden toegevoegd voor toegang tot deze trailers.
HTTP/1.1 trailers zijn beschikbaar zodra de volledige aanvraagbody is gelezen.
HTTP/2-trailers zijn beschikbaar zodra ze van de client zijn ontvangen. De client verzendt de trailers pas nadat de volledige aanvraagbody door de server is gebufferd. Mogelijk moet u de aanvraagbody lezen om bufferruimte vrij te maken. Trailers zijn altijd beschikbaar als u de aanvraagtekst naar het einde leest. De aanhangwagens markeren het einde van het lichaam.
3,0
Aanvraagtrailerheaders worden toegevoegd aan de HttpRequest.Headers
verzameling.
Aanvraagtrailerheaders zijn niet aanwezig in de HttpRequest.Headers
verzameling. Gebruik de volgende uitbreidingsmethoden HttpRequest
om ze te openen:
GetDeclaredTrailers()
- Haalt de aanvraag "Trailer" header die vermeldt welke trailers te verwachten na de body.SupportsTrailers()
- Geeft aan of de aanvraag ondersteuning biedt voor het ontvangen van trailerheaders.CheckTrailersAvailable()
- Bepaalt of de aanvraag aanhangwagens ondersteunt en of deze beschikbaar zijn voor lezen.GetTrailer(string trailerName)
- Haalt de aangevraagde volgheader op uit het antwoord.
Trailers zijn een belangrijke functie in scenario's zoals gRPC. Het samenvoegen van de trailers om headers aan te vragen, was verwarrend voor gebruikers.
Gebruik de aan trailer gerelateerde uitbreidingsmethoden voor HttpRequest
toegang tot trailers.
ASP.NET Core
Als onderdeel van het weggaan van 'pubternale' API's, worden de Kestrel transportlaag-API's weergegeven als een openbare interface in de Microsoft.AspNetCore.Connections.Abstractions
bibliotheek.
3,0
- Transportgerelateerde abstracties waren beschikbaar in de
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
bibliotheek. - De
ListenOptions.NoDelay
accommodatie was beschikbaar.
- De
IConnectionListener
interface is geïntroduceerd in deMicrosoft.AspNetCore.Connections.Abstractions
bibliotheek om de meest gebruikte functionaliteit van de...Transport.Abstractions
bibliotheek beschikbaar te maken. - De
NoDelay
is nu beschikbaar in transportopties (LibuvTransportOptions
enSocketTransportOptions
). SchedulingMode
is niet meer beschikbaar.
ASP.NET Core 3.0 is verwijderd van 'pubternal'-API's.
ASP.NET Core
Geen
De klasse ResourceManagerWithCultureStringLocalizer en het lid van de WithCulture-interface zijn vaak bronnen van verwarring voor gebruikers van lokalisatie, vooral bij het maken van hun eigen IStringLocalizer
implementatie. Deze items geven de gebruiker de indruk dat een IStringLocalizer
exemplaar 'per taal, per resource' is. In werkelijkheid mogen de exemplaren alleen per resource zijn. De gezochte taal wordt bepaald door de CultureInfo.CurrentUICulture
uitvoeringsperiode. Om verwarring te voorkomen, zijn de API's gemarkeerd als verouderd in ASP.NET Core 3.0. De API's worden verwijderd in een toekomstige release.
Zie dotnet/aspnetcore#3324 voor context. Zie dotnet/aspnetcore#7756 voor discussie.
3,0
Methoden zijn niet gemarkeerd als Obsolete
.
Methoden worden gemarkeerd Obsolete
.
De API's vertegenwoordigden een use-case die niet wordt aanbevolen. Er was verwarring over het ontwerp van lokalisatie.
De aanbeveling is in plaats daarvan te gebruiken ResourceManagerStringLocalizer
. Laat de cultuur door de CurrentCulture
. Als dat geen optie is, maakt en gebruikt u een kopie van ResourceManagerWithCultureStringLocalizer.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Vóór ASP.NET Core 3.0 was public
de DebugLogger
toegangsaanpassing . In ASP.NET Core 3.0 is de toegangsaanpassing gewijzigd in internal
.
3,0
De wijziging wordt aangebracht in:
- Consistentie afdwingen met andere logger-implementaties, zoals
ConsoleLogger
. - Verminder het API-oppervlak.
Gebruik de AddDebug ILoggingBuilder
extensiemethode om logboekregistratie voor foutopsporing in te schakelen. DebugLoggerProvider bevindt zich ook nog steeds public
in het geval dat de service handmatig moet worden geregistreerd.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
Als onderdeel van het adresseren van dotnet/aspnetcore#4849, ASP.NET Core MVC het achtervoegsel Async
van actienamen standaard trimt. Vanaf ASP.NET Core 3.0 is deze wijziging van invloed op zowel routering als het genereren van koppelingen.
3,0
Houd rekening met de volgende ASP.NET Core MVC-controller:
public class ProductController : Controller
{
public async IActionResult ListAsync()
{
var model = await DbContext.Products.ToListAsync();
return View(model);
}
}
De actie is routeerbaar via Product/ListAsync
. Voor het genereren van koppelingen moet het Async
achtervoegsel worden opgegeven. Voorbeeld:
<a asp-controller="Product" asp-action="ListAsync">List</a>
In ASP.NET Core 3.0 is de actie routeerbaar via Product/List
. Code voor het genereren van koppelingen moet het Async
achtervoegsel weglaten. Voorbeeld:
<a asp-controller="Product" asp-action="List">List</a>
Deze wijziging heeft geen invloed op namen die zijn opgegeven met behulp van het [ActionName]
kenmerk. Het nieuwe gedrag kan worden uitgeschakeld door in te stellen MvcOptions.SuppressAsyncSuffixInActionNames
op false
Startup.ConfigureServices
:
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Standaard worden asynchrone .NET-methoden met achtervoegsel gebruikt Async
. Wanneer een methode echter een MVC-actie definieert, is het niet wenselijk om het Async
achtervoegsel te gebruiken.
Als uw app afhankelijk is van MVC-acties die het achtervoegsel van Async
de naam behouden, kiest u een van de volgende oplossingen:
- Gebruik het
[ActionName]
kenmerk om de oorspronkelijke naam te behouden. - Schakel de naam volledig uit door de instelling
MvcOptions.SuppressAsyncSuffixInActionNames
inStartup.ConfigureServices
:false
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
Geen
JsonResult
is verplaatst naar de Microsoft.AspNetCore.Mvc.Core
assembly. Dit type is gedefinieerd in Microsoft.AspNetCore.Mvc.Formatters.Json. Er is een kenmerk [TypeForwardedTo] op assemblyniveau toegevoegd om dit probleem voor de meeste gebruikers op te Microsoft.AspNetCore.Mvc.Formatters.Json
lossen. Apps die gebruikmaken van bibliotheken van derden kunnen problemen ondervinden.
3.0 Preview 6
Een app die gebruikmaakt van een bibliotheek op basis van 2.2, bouwt met succes.
Het compileren van een app met een bibliotheek op basis van 2.2 mislukt. Er wordt een fout met een variatie van de volgende tekst opgegeven:
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'
Zie dotnet/aspnetcore#7220 voor een voorbeeld van een dergelijk probleem.
Wijzigingen op platformniveau in de samenstelling van ASP.NET Core, zoals beschreven in aspnet/Announcements#325.
Bibliotheken die zijn gecompileerd op basis van de 2.2-versie, Microsoft.AspNetCore.Mvc.Formatters.Json
moeten mogelijk opnieuw worden gecompileerd om het probleem voor alle consumenten op te lossen. Neem contact op met de auteur van de bibliotheek als dit wordt beïnvloed. Hercompilatie van de bibliotheek aanvragen voor het doel van ASP.NET Core 3.0.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
In ASP.NET Core 1.1 is het Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
pakket (MVC precompilation tool) geïntroduceerd om ondersteuning toe te voegen voor het compileren van de publicatietijd van Razor-bestanden (.cshtml-bestanden ). In ASP.NET Core 2.1 is de Razor SDK geïntroduceerd om uit te breiden op functies van het hulpprogramma voor precompilatie. De Razor SDK heeft ondersteuning toegevoegd voor het compileren en publiceren van tijdcompilatie van Razor-bestanden. De SDK controleert de juistheid van .cshtml-bestanden tijdens de build en verbetert de opstarttijd van de app. De Razor SDK is standaard ingeschakeld en er is geen beweging vereist om deze te gaan gebruiken.
In ASP.NET Core 3.0 is het ASP.NET MVC-precompilatiehulpmiddel uit het ASP.NET Core 1.1-era verwijderd. Eerdere pakketversies blijven belangrijke bug- en beveiligingsoplossingen ontvangen in de patchrelease.
3,0
Het Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
pakket is gebruikt om MVC Razor-weergaven vooraf te compileren.
De Razor SDK biedt systeemeigen ondersteuning voor deze functionaliteit. Het Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
pakket wordt niet meer bijgewerkt.
De Razor SDK biedt meer functionaliteit en controleert de juistheid van .cshtml-bestanden tijdens de build. De SDK verbetert ook de opstarttijd van apps.
Voor gebruikers van ASP.NET Core 2.1 of hoger moet u de systeemeigen ondersteuning voor precompilatie in de Razor SDK gebruiken. Als fouten of ontbrekende functies migratie naar de Razor SDK voorkomen, opent u een probleem op dotnet/aspnetcore.
ASP.NET Core
Geen
In ASP.NET Core 3.0 zijn alle typen 'pubternal' in MVC bijgewerkt naar public
een ondersteunde naamruimte of internal
naar behoren.
In ASP.NET Core worden 'pubternale' typen gedeclareerd als public
maar zich in een .Internal
-achtervoegselnaamruimte bevinden. Hoewel deze typen zijn, hebben public
ze geen ondersteuningsbeleid en zijn ze onderhevig aan wijzigingen die fouten veroorzaken. Helaas is het onbedoeld gebruik van deze typen gebruikelijk, wat resulteert in belangrijke wijzigingen in deze projecten en het beperken van de mogelijkheid om het framework te onderhouden.
3,0
Sommige typen in MVC waren public
maar in een .Internal
naamruimte. Deze typen hadden geen ondersteuningsbeleid en waren onderhevig aan belangrijke wijzigingen.
Alle typen worden bijgewerkt zodat public
ze zich in een ondersteunde naamruimte bevinden of als gemarkeerd internal
zijn.
Onbedoeld gebruik van de 'pubternal'-typen is gebruikelijk, wat resulteert in belangrijke wijzigingen in deze projecten en het beperken van de mogelijkheid om het framework te onderhouden.
Als u typen gebruikt die echt public
zijn geworden en zijn verplaatst naar een nieuwe, ondersteunde naamruimte, werkt u uw verwijzingen bij zodat deze overeenkomen met de nieuwe naamruimten.
Als u typen gebruikt die zijn gemarkeerd als internal
, moet u een alternatief vinden. De eerder 'pubternal'-typen werden nooit ondersteund voor openbaar gebruik. Als er specifieke typen zijn in deze naamruimten die essentieel zijn voor uw apps, kunt u een probleem indienen bij dotnet/aspnetcore. Er kunnen overwegingen worden gemaakt voor het maken van de aangevraagde typen public
.
ASP.NET Core
Deze wijziging omvat typen in de volgende naamruimten:
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
Vanaf ASP.NET Core 3.0 is het Microsoft.AspNetCore.Mvc.WebApiCompatShim
pakket niet meer beschikbaar.
Het Microsoft.AspNetCore.Mvc.WebApiCompatShim
pakket (WebApiCompatShim) biedt gedeeltelijke compatibiliteit in ASP.NET Core met ASP.NET 4.x Web API 2 om het migreren van bestaande web-API-implementaties naar ASP.NET Core te vereenvoudigen. Apps die gebruikmaken van de WebApiCompatShim profiteren echter niet van de API-gerelateerde functies die worden verzonden in recente ASP.NET Core-releases. Dergelijke functies omvatten verbeterde generatie van Open API-specificatie, gestandaardiseerde foutafhandeling en het genereren van clientcode. WebApiCompatShim is verwijderd om de API-inspanningen in 3.0 beter te richten. Bestaande apps die gebruikmaken van het WebApiCompatShim, moeten worden gemigreerd naar het nieuwere [ApiController]
model.
3,0
De web-API-compatibiliteits-shim was een migratiehulpprogramma. Het beperkt de gebruikerstoegang tot nieuwe functionaliteit die is toegevoegd in ASP.NET Core.
Verwijder het gebruik van deze shim en migreer rechtstreeks naar de vergelijkbare functionaliteit in ASP.NET Core zelf.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
De RazorTemplateEngine
API is verwijderd en vervangen door Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
.
Zie Voor discussie gitHub probleem dotnet/aspnetcore#25215.
3,0
Een sjabloonengine kan worden gemaakt en gebruikt om code voor Razor-bestanden te parseren en genereren.
RazorProjectEngine
kan worden gemaakt en opgegeven hetzelfde type informatie als RazorTemplateEngine
voor het parseren en genereren van code voor Razor-bestanden. RazorProjectEngine
biedt ook extra configuratieniveaus.
RazorTemplateEngine
was te nauw gekoppeld aan de bestaande implementaties. Deze strakke koppeling heeft geleid tot meer vragen bij het correct configureren van een Razor-parseer-/generatiepijplijn.
Gebruik RazorProjectEngine
in plaats van RazorTemplateEngine
. Bekijk de volgende voorbeelden.
RazorProjectEngine projectEngine =
RazorProjectEngine.Create(RazorConfiguration.Default,
RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
builder =>
{
builder.ConfigureClass((document, classNode) =>
{
classNode.ClassName = "MyClassName";
// Can also configure other aspects of the class here.
});
// More configuration can go here
});
RazorProjectItem item = projectEngine.FileSystem.GetItem(
@"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);
// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();
ASP.NET Core
RazorTemplateEngine
RazorTemplateEngineOptions
Ondersteuning voor runtimecompilatie van Razor-weergaven en Razor Pages is verplaatst naar een afzonderlijk pakket.
3,0
Runtimecompilatie is beschikbaar zonder extra pakketten nodig te hebben.
De functionaliteit is verplaatst naar het pakket Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
De volgende API's waren eerder beschikbaar ter Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
ondersteuning van runtimecompilatie. De API's zijn nu beschikbaar via Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions
.
RazorViewEngineOptions.FileProviders
is nuMvcRazorRuntimeCompilationOptions.FileProviders
RazorViewEngineOptions.AdditionalCompilationReferences
is nuMvcRazorRuntimeCompilationOptions.AdditionalReferencePaths
Daarnaast Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange
is het verwijderd. Hercompilatie voor bestandswijzigingen is standaard ingeschakeld door te verwijzen naar het Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
pakket.
Deze wijziging was nodig om de gedeelde ASP.NET Core-frameworkafhankelijkheid van Roslyn te verwijderen.
Voor apps waarvoor runtimecompilatie of hercompilatie van Razor-bestanden is vereist, moet u de volgende stappen uitvoeren:
Voeg een verwijzing naar het
Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
pakket toe.Werk de methode van
Startup.ConfigureServices
het project bij om een aanroep naar toe teAddRazorRuntimeCompilation
voegen. Voorbeeld:services.AddMvc() .AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Verouderde API's voor het configureren van sessiecookies zijn verwijderd. Zie aspnet/Aankondigingen#257 voor meer informatie.
3,0
Deze wijziging dwingt consistentie af tussen API's voor het configureren van functies die cookies gebruiken.
Migreer het gebruik van de verwijderde API's naar de nieuwere vervangingen. Bekijk het volgende voorbeeld in Startup.ConfigureServices
:
public void ConfigureServices(ServiceCollection services)
{
services.AddSession(options =>
{
// Removed obsolete APIs
options.CookieName = "SessionCookie";
options.CookieDomain = "contoso.com";
options.CookiePath = "/";
options.CookieHttpOnly = true;
options.CookieSecure = CookieSecurePolicy.Always;
// new API
options.Cookie.Name = "SessionCookie";
options.Cookie.Domain = "contoso.com";
options.Cookie.Path = "/";
options.Cookie.HttpOnly = true;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});
}
ASP.NET Core
- Microsoft.AspNetCore.Builder.SessionOptions.CookieDomain
- Microsoft.AspNetCore.Builder.SessionOptions.CookieHttpOnly
- Microsoft.AspNetCore.Builder.SessionOptions.CookieName
- Microsoft.AspNetCore.Builder.SessionOptions.CookiePath
- Microsoft.AspNetCore.Builder.SessionOptions.CookieSecure
Vanaf ASP.NET Core 3.0 bevat het gedeelde ASP.NET Core-framework (Microsoft.AspNetCore.App
) alleen assembly's van eerste partijen die volledig zijn ontwikkeld, ondersteund en kunnen worden onderhouden door Microsoft.
Denk aan de wijziging als de herdefiniëring van grenzen voor het ASP.NET Core -platform. Het gedeelde framework kan door iedereen via GitHub worden gebouwd en biedt de bestaande voordelen van gedeelde .NET Core-frameworks aan uw apps. Enkele voordelen zijn kleinere implementatiegrootte, gecentraliseerde patches en snellere opstarttijd.
Als onderdeel van de wijziging worden enkele belangrijke wijzigingen geïntroduceerd in Microsoft.AspNetCore.App
.
3,0
Projecten waarnaar wordt verwezen Microsoft.AspNetCore.App
via een <PackageReference>
element in het projectbestand.
Microsoft.AspNetCore.App
Daarnaast bevat u de volgende subonderdelen:
- Json.NET (
Newtonsoft.Json
) - Entity Framework Core (assembly's voorafgegaan door
Microsoft.EntityFrameworkCore.
) - Roslyn (
Microsoft.CodeAnalysis
)
Een verwijzing naar Microsoft.AspNetCore.App
het projectbestand vereist <PackageReference>
geen element meer. De .NET Core SDK ondersteunt een nieuw element met de naam <FrameworkReference>
, dat het gebruik van <PackageReference>
.
Zie dotnet/aspnetcore#3612 voor meer informatie.
Entity Framework Core wordt geleverd als NuGet-pakketten. Met deze wijziging wordt het verzendmodel uitgelijnd met alle andere gegevenstoegangsbibliotheken op .NET. Het biedt Entity Framework Core het eenvoudigste pad om te blijven innoveren en tegelijkertijd de verschillende .NET-platforms te ondersteunen. De verplaatsing van Entity Framework Core uit het gedeelde framework heeft geen invloed op de status ervan als een door Microsoft ontwikkelde, ondersteunde en servicebare bibliotheek. Het .NET Core-ondersteuningsbeleid blijft van toepassing.
Json.NET en Entity Framework Core blijven werken met ASP.NET Core. Ze worden echter niet opgenomen in het gedeelde framework.
Zie De toekomst van JSON in .NET Core 3.0 voor meer informatie. Zie ook de volledige lijst met binaire bestanden die zijn verwijderd uit het gedeelde framework.
Deze wijziging vereenvoudigt het verbruik van Microsoft.AspNetCore.App
en vermindert de duplicatie tussen NuGet-pakketten en gedeelde frameworks.
Zie dit blogbericht voor meer informatie over de motivatie voor deze wijziging.
Vanaf ASP.NET Core 3.0 is het niet langer nodig voor projecten om assembly's te gebruiken als Microsoft.AspNetCore.App
NuGet-pakketten. Om het doel en het gebruik van het gedeelde framework ASP.NET Core te vereenvoudigen, worden er veel NuGet-pakketten verzonden sinds ASP.NET Core 1.0 niet meer worden geproduceerd. De API's die deze pakketten bieden, zijn nog steeds beschikbaar voor apps met behulp van een <FrameworkReference>
naar Microsoft.AspNetCore.App
. Veelvoorkomende API-voorbeelden zijn Kestrel, MVC en Razor.
Deze wijziging is niet van toepassing op alle binaire bestanden waarnaar Microsoft.AspNetCore.App
wordt verwezen in ASP.NET Core 2.x. Belangrijke uitzonderingen zijn:
Microsoft.Extensions
bibliotheken die zich blijven richten op .NET Standard, zijn beschikbaar als NuGet-pakketten (zie https://github.com/dotnet/extensions).- API's die worden geproduceerd door het ASP.NET Core-team dat geen deel uitmaakt van
Microsoft.AspNetCore.App
. De volgende onderdelen zijn bijvoorbeeld beschikbaar als NuGet-pakketten:- Entity Framework Core
- API's die integratie van derden bieden
- Experimentele functies
- API's met afhankelijkheden die niet aan de vereisten voor het gedeelde framework konden voldoen
- Extensies voor MVC die ondersteuning voor Json.NET behouden. Er wordt een API geleverd als een NuGet-pakket ter ondersteuning van Json.NET en MVC. Zie de handleiding voor ASP.NET Core-migratie voor meer informatie.
- De SignalR .NET-client blijft .NET Standard ondersteunen en wordt geleverd als een NuGet-pakket. Het is bedoeld voor veel .NET-runtimes, zoals Xamarin en UWP.
Zie Stoppen met het produceren van pakketten voor gedeelde frameworkassembly's in 3.0 voor meer informatie. Zie dotnet/aspnetcore#3757 voor discussie.
ASP.NET Core
Vanaf ASP.NET Core 3.0 worden de Microsoft.AspNetCore.All
metapackage en het overeenkomende Microsoft.AspNetCore.All
gedeelde framework niet meer geproduceerd. Dit pakket is beschikbaar in ASP.NET Core 2.2 en blijft onderhoudsupdates ontvangen in ASP.NET Core 2.1.
3,0
Apps kunnen de Microsoft.AspNetCore.All
metapackage gebruiken om het Microsoft.AspNetCore.All
gedeelde framework op .NET Core te richten.
.NET Core 3.0 bevat Microsoft.AspNetCore.All
geen gedeeld framework.
De Microsoft.AspNetCore.All
metapackage bevat een groot aantal externe afhankelijkheden.
Migreer uw project om het Microsoft.AspNetCore.App
framework te gebruiken. Onderdelen die eerder beschikbaar waren in Microsoft.AspNetCore.All
, zijn nog steeds beschikbaar in NuGet. Deze onderdelen worden nu geïmplementeerd met uw app in plaats van opgenomen te worden in het gedeelde framework.
ASP.NET Core
Geen
Het veld HandshakeProtocol.SuccessHandshakeData is verwijderd en vervangen door een helpermethode waarmee een geslaagd handshake-antwoord wordt gegenereerd op basis van een specifieke IHubProtocol
.
3,0
HandshakeProtocol.SuccessHandshakeData
was een public static ReadOnlyMemory<byte>
veld.
HandshakeProtocol.SuccessHandshakeData
is vervangen door een static
GetSuccessfulHandshake(IHubProtocol protocol)
methode die een ReadOnlyMemory<byte>
op basis van het opgegeven protocol retourneert.
Er zijn extra velden toegevoegd aan het handshake-antwoord dat niet constant is en afhankelijk van het geselecteerde protocol wordt gewijzigd.
Geen. Dit type is niet ontworpen voor gebruik vanuit gebruikerscode. Het is public
, zodat het kan worden gedeeld tussen de SignalR-server en de client. Het kan ook worden gebruikt door klant SignalR-clients die zijn geschreven in .NET. Gebruikers van SignalR mogen niet worden beïnvloed door deze wijziging.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
De ResetSendPing
en ResetTimeout
methoden zijn verwijderd uit de SignalR-API HubConnection
. Deze methoden waren oorspronkelijk alleen bedoeld voor intern gebruik, maar werden openbaar gemaakt in ASP.NET Core 2.2. Deze methoden zijn niet beschikbaar vanaf de release van ASP.NET Core 3.0 Preview 4. Zie dotnet/aspnetcore#8543 voor discussie.
3,0
ER zijn API's beschikbaar.
API's worden verwijderd.
Deze methoden waren oorspronkelijk alleen bedoeld voor intern gebruik, maar werden openbaar gemaakt in ASP.NET Core 2.2.
Gebruik deze methoden niet.
ASP.NET Core
De constructors van HubConnectionContext
SignalR zijn gewijzigd in het accepteren van een type opties, in plaats van meerdere parameters, voor toekomstbestendig toevoegen van opties. Deze wijziging vervangt twee constructors door één constructor die een type opties accepteert.
3,0
HubConnectionContext
heeft twee constructors:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
De twee constructors zijn verwijderd en vervangen door één constructor:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
De nieuwe constructor maakt gebruik van een nieuw optiesobject. De functies van HubConnectionContext
kunnen daarom in de toekomst worden uitgebreid zonder dat er meer constructors en wijzigingen die fouten veroorzaken.
In plaats van de volgende constructor te gebruiken:
HubConnectionContext connectionContext = new HubConnectionContext(
connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Gebruik de volgende constructor:
HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);
ASP.NET Core
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory)
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory, TimeSpan)
In ASP.NET Core 3.0 Preview 7 is de naam van het SignalR JavaScript-clientpakket gewijzigd van @aspnet/signalr
in @microsoft/signalr
. De naamwijziging weerspiegelt het feit dat SignalR nuttig is in meer dan alleen ASP.NET Core-apps, dankzij de Azure SignalR-service.
Als u wilt reageren op deze wijziging, wijzigt u verwijzingen in uw package.json bestanden, require
instructies en ECMAScript-instructiesimport
. Er wordt geen API gewijzigd als onderdeel van deze naam.
Zie dotnet/aspnetcore#11637 voor discussie.
3,0
Het clientpakket heeft de naam @aspnet/signalr
.
Het clientpakket heeft de naam @microsoft/signalr
.
De naamwijziging verduidelijkt dat SignalR nuttig is buiten ASP.NET Core-apps, dankzij de Azure SignalR-service.
Schakel over naar het nieuwe pakket @microsoft/signalr
.
ASP.NET Core
Geen
De methoden UseConnections
en UseSignalR
de klassen ConnectionsRouteBuilder
en HubRouteBuilder
zijn gemarkeerd als verouderd in ASP.NET Core 3.0.
3,0
SignalR-hubroutering is geconfigureerd met of UseSignalR
UseConnections
.
De oude manier om routering te configureren, is verouderd en vervangen door eindpuntroutering.
Middleware wordt verplaatst naar het nieuwe eindpuntrouteringssysteem. De oude manier om middleware toe te voegen, is verouderd.
Vervangen UseSignalR
door UseEndpoints
:
Oude code:
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Nieuwe code:
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
ASP.NET Core
- Microsoft.AspNetCore.Builder.ConnectionsAppBuilderExtensions.UseConnections(IApplicationBuilder, Action<ConnectionsRouteBuilder>)
- Microsoft.AspNetCore.Builder.SignalRAppBuilderExtensions.UseSignalR(IApplicationBuilder, Action<HubRouteBuilder>)
- Microsoft.AspNetCore.Http.Connections.ConnectionsRouteBuilder
- Microsoft.AspNetCore.SignalR.HubRouteBuilder
De inhoud van de volgende NuGet-pakketten is allemaal overbodig sinds ASP.NET Core 2.1. Daarom worden de volgende pakketten gemarkeerd als verouderd:
Om dezelfde reden worden de volgende NPM-modules gemarkeerd als afgeschaft:
De voorgaande pakketten en npm-modules worden later verwijderd in .NET 5.
3,0
De afgeschafte pakketten en npm-modules zijn bedoeld om ASP.NET Core te integreren met verschillende spa-frameworks (Single Page App). Dergelijke frameworks omvatten Angular, React en React met Redux.
Er bestaat een nieuw integratiemechanisme in het NuGet-pakket Microsoft.AspNetCore.SpaServices.Extensions . Het pakket blijft de basis van de Angular- en React-projectsjablonen sinds ASP.NET Core 2.1.
ASP.NET Core ondersteunt integratie met verschillende SPA-frameworks (Single Page App), waaronder Angular, React en React met Redux. In eerste instantie werd de integratie met deze frameworks gerealiseerd met ASP.NET Kernspecifieke onderdelen die scenario's verwerkten, zoals prerendering aan de serverzijde en integratie met Webpack. Naarmate de tijd aan de hand was, zijn de industriestandaarden veranderd. Elk van de BEVEILIGD-WACHTWOORDVERIFICATIE-frameworks heeft hun eigen standaard opdrachtregelinterfaces uitgebracht. Bijvoorbeeld Angular CLI en create-react-app.
Toen ASP.NET Core 2.1 werd uitgebracht in mei 2018, reageerde het team op de wijziging in standaarden. Er is een nieuwere en eenvoudigere manier geboden om te integreren met de eigen toolchains van de beveiligd-WACHTWOORDVERIFICATIE frameworks. Het nieuwe integratiemechanisme bestaat in het pakket Microsoft.AspNetCore.SpaServices.Extensions
en blijft de basis van de projectsjablonen Angular en React sinds ASP.NET Core 2.1.
Om te verduidelijken dat de oudere ASP.NET Kernspecifieke onderdelen irrelevant zijn en niet worden aanbevolen:
- Het pre-2.1-integratiemechanisme is gemarkeerd als verouderd.
- De ondersteunende NPM-pakketten worden gemarkeerd als afgeschaft.
Als u deze pakketten gebruikt, werkt u uw apps bij om de functionaliteit te gebruiken:
- In het
Microsoft.AspNetCore.SpaServices.Extensions
pakket. - Geleverd door de beveiligd-WACHTWOORDVERIFICATIE frameworks die u gebruikt
Raadpleeg de documentatie voor het bijbehorende BEVEILIGD-WACHTWOORDVERIFICATIE-framework om functies zoals prerendering aan de serverzijde en het opnieuw laden van hot modules in te schakelen. De functionaliteit is Microsoft.AspNetCore.SpaServices.Extensions
niet verouderd en wordt nog steeds ondersteund.
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
Microsoft.AspNetCore.SpaServices en Microsoft.AspNetCore.NodeServices geeft geen consolelogboeken weer, tenzij logboekregistratie is geconfigureerd.
3,0
Microsoft.AspNetCore.SpaServices
en Microsoft.AspNetCore.NodeServices
wordt gebruikt om automatisch een consolelogger te maken wanneer logboekregistratie niet is geconfigureerd.
Microsoft.AspNetCore.SpaServices
en Microsoft.AspNetCore.NodeServices
geeft geen consolelogboeken weer, tenzij logboekregistratie is geconfigureerd.
Er moet worden afgestemd op de wijze waarop andere ASP.NET Core-pakketten logboekregistratie implementeren.
Als het oude gedrag is vereist, voegt u de consolelogboekregistratie toe services.AddLogging(builder => builder.AddConsole())
aan uw Setup.ConfigureServices
methode om logboekregistratie van de console te configureren.
ASP.NET Core
Geen
Vanaf ASP.NET Core 3.0 is .NET Framework een niet-ondersteund doelframework.
.NET Framework 4.8 is de laatste primaire versie van .NET Framework. Nieuwe ASP.NET Core-apps moeten worden gebouwd op .NET Core. Vanaf de .NET Core 3.0-release kunt u ASP.NET Core 3.0 beschouwen als onderdeel van .NET Core.
Klanten die ASP.NET Core gebruiken met .NET Framework, kunnen op een volledig ondersteunde manier doorgaan met behulp van de 2.1 LTS-release. Ondersteuning en onderhoud voor 2.1 wordt voortgezet tot ten minste 21 augustus 2021. Deze datum is drie jaar na de declaratie van de LTS-release volgens het .NET-ondersteuningsbeleid. Ondersteuning voor ASP.NET Core 2.1-pakketten op .NET Framework wordt voor onbepaalde tijd verlengd, vergelijkbaar met het servicebeleid voor andere ASP.NET frameworks op basis van pakketten.
Zie Porting to .NET Core (Overzetten naar .NET Core) voor meer informatie over het overzetten van .NET Framework naar .NET Core.
Microsoft.Extensions
pakketten (zoals logboekregistratie, afhankelijkheidsinjectie en configuratie) en Entity Framework Core worden niet beïnvloed. Ze blijven ondersteuning bieden voor .NET Standard.
Zie het oorspronkelijke blogbericht voor meer informatie over de motivatie voor deze wijziging.
3,0
ASP.NET Core-apps kunnen worden uitgevoerd op .NET Core of .NET Framework.
ASP.NET Core-apps kunnen alleen worden uitgevoerd op .NET Core.
Ga in dat geval op een van de volgende manieren te werk:
- Houd uw app op ASP.NET Core 2.1.
- Migreer uw app en afhankelijkheden naar .NET Core.
ASP.NET Core
Geen
- API's die rapportversie nu rapporteren, rapporteren product en geen bestandsversie
- Custom EncoderFallbackBuffer-exemplaren kunnen niet recursief terugvallen
- Wijzigingen in drijvendekommaopmaak en parseringsgedrag
- Drijvendekommaparseerbewerkingen mislukken niet meer of gooien een OverflowException
- InvalidAsynchronousStateException is verplaatst naar een andere assembly
- Het vervangen van slecht gevormde UTF-8 bytereeksen volgt Unicode-richtlijnen
- TypeDescriptionProviderAttribute is verplaatst naar een andere assembly
- ZipArchiveEntry verwerkt geen archieven meer met inconsistente invoergrootten
- FieldInfo.SetValue genereert uitzondering voor statische, alleen-init-velden
- Het doorgeven van GroupCollection aan extensiemethoden die IEnumerable<T> gebruiken, vereist ondubbelzinnigheid
Veel van de API's die versies retourneren in .NET Core retourneren, retourneren nu de productversie in plaats van de bestandsversie.
In .NET Core 2.2 en vorige versies geven methoden zoals Environment.Version, RuntimeInformation.FrameworkDescriptionen het dialoogvenster bestandseigenschappen voor .NET Core-assembly's de bestandsversie weer. Vanaf .NET Core 3.0 weerspiegelen ze de productversie.
In de volgende afbeelding ziet u het verschil in versie-informatie voor de System.Runtime.dll assembly voor .NET Core 2.2 (aan de linkerkant) en .NET Core 3.0 (aan de rechterkant) zoals weergegeven in het dialoogvenster bestandseigenschappen van Windows Verkenner.
3,0
Geen. Deze wijziging moet versiedetectie intuïtief maken in plaats van obtuse.
Core .NET-bibliotheken
Aangepaste EncoderFallbackBuffer exemplaren kunnen niet recursief terugvallen. De implementatie van EncoderFallbackBuffer.GetNextChar() moet resulteren in een tekenreeks die converteert naar de doelcodering. Anders treedt er een uitzondering op.
Tijdens een transcoderingsbewerking voor teken-naar-byte detecteert de runtime ongeldige of niet-converteerbare UTF-16-reeksen en geeft deze tekens aan de EncoderFallbackBuffer.Fallback methode. De Fallback
methode bepaalt welke tekens moeten worden vervangen door de oorspronkelijke niet-converteerbare gegevens en deze tekens worden leeggezogen door een lus aan te roepen EncoderFallbackBuffer.GetNextChar .
De runtime probeert deze vervangende tekens vervolgens te transcoderen naar de doelcodering. Als deze bewerking slaagt, gaat de runtime door met transcodering vanaf waar deze is gebleven in de oorspronkelijke invoertekenreeks.
Voorheen kunnen aangepaste implementaties van EncoderFallbackBuffer.GetNextChar() tekenreeksen die niet converteerbaar zijn naar de doelcodering, retourneren. Als de vervangen tekens niet kunnen worden getranscodeerd naar de doelcodering, roept de runtime de EncoderFallbackBuffer.Fallback methode opnieuw aan met de vervangingstekens, waarbij wordt verwacht dat de EncoderFallbackBuffer.GetNextChar() methode een nieuwe vervangingsreeks retourneert. Dit proces gaat door totdat de runtime uiteindelijk een goed gevormde, converteerbare vervanging ziet of totdat een maximumaantal recursies is bereikt.
Vanaf .NET Core 3.0 moeten aangepaste implementaties van EncoderFallbackBuffer.GetNextChar() tekensreeksen retourneren die converteerbaar zijn naar de doelcodering. Als de vervangen tekens niet kunnen worden getranscodeerd naar de doelcodering, wordt er een ArgumentException gegenereerd. De runtime maakt geen recursieve aanroepen meer naar het EncoderFallbackBuffer exemplaar.
Dit gedrag is alleen van toepassing wanneer aan alle drie de volgende voorwaarden wordt voldaan:
- De runtime detecteert een ongeldige UTF-16-reeks of een UTF-16-reeks die niet kan worden geconverteerd naar de doelcodering.
- Er is een aangepaste waarde EncoderFallback opgegeven.
- De aangepaste pogingen om een nieuwe niet-gevormde of niet-onvertibele EncoderFallback UTF-16-reeks te vervangen.
3,0
De meeste ontwikkelaars hoeven geen actie te ondernemen.
Als een toepassing gebruikmaakt van een aangepaste EncoderFallback klasse EncoderFallbackBuffer , moet u ervoor zorgen dat de implementatie van EncoderFallbackBuffer.Fallback de terugvalbuffer wordt gevuld met goed gevormde UTF-16-gegevens die rechtstreeks worden omgezet in de doelcodering wanneer de methode voor het Fallback eerst wordt aangeroepen door de runtime.
Core .NET-bibliotheken
Drijvendekommaparsering en opmaakgedrag (door de Double en Single typen) zijn nu compatibel met IEEE. Dit zorgt ervoor dat het gedrag van typen drijvende komma's in .NET overeenkomt met die van andere IEEE-compatibele talen. Moet bijvoorbeeld double.Parse("SomeLiteral")
altijd overeenkomen met waarvoor C# produceert double x = SomeLiteral
.
In .NET Core 2.2 en eerdere versies zijn opmaak met Double.ToString en , en Single.ToStringparseren met Double.Parse, Double.TryParseen Single.ParseSingle.TryParse niet compatibel met IEEE. Als gevolg hiervan is het onmogelijk om te garanderen dat een waarde retourneert met een ondersteunde tekenreeks met een standaard- of aangepaste notatie. Voor sommige invoer kan de poging om een opgemaakte waarde te parseren mislukken. Voor andere invoer is de geparseerde waarde niet gelijk aan de oorspronkelijke waarde.
Vanaf .NET Core 3.0 zijn parserings- en opmaakbewerkingen met IEEE 754 compatibel.
In de volgende tabel ziet u twee codefragmenten en hoe de uitvoer verandert tussen .NET Core 2.2 en .NET Core 3.1.
Codefragment | Uitvoer op .NET Core 2.2 | Uitvoer op .NET Core 3.1 |
---|---|---|
Console.WriteLine((-0.0).ToString()); |
0 | 0- |
var value = -3.123456789123456789; Console.WriteLine(value == double.Parse(value.ToString())); |
False |
True |
Zie de verbeteringen voor drijvende komma parseren en opmaken in het blogbericht .NET Core 3.0 voor meer informatie.
3,0
De mogelijke impact op de bestaande codesectie van de drijvendekommaparsering en opmaakverbeteringen in het blogbericht .NET Core 3.0 stelt enkele wijzigingen voor die u in uw code kunt aanbrengen als u het vorige gedrag wilt behouden.
- Voor sommige verschillen in opmaak kunt u gedrag krijgen dat gelijk is aan het vorige gedrag door een andere notatietekenreeks op te geven.
- Voor verschillen in parseren is er geen mechanisme om terug te vallen op het vorige gedrag.
Core .NET-bibliotheken
De drijvendekommaparseermethoden genereren of OverflowException retourneren false
niet langer wanneer ze een tekenreeks parseren waarvan de numerieke waarde buiten het bereik van het Single type Double drijvende komma valt.
In .NET Core 2.2 en eerdere versies gooien de Double.Parse en Single.Parse methoden een OverflowException waarde op voor waarden die buiten het bereik van hun respectieve type liggen. De Double.TryParse en Single.TryParse methoden retourneren de false
tekenreeksweergaven van numerieke waarden buiten het bereik.
Vanaf .NET Core 3.0 mislukken de Double.Parse, Double.TryParseen Single.ParseSingle.TryParse methoden niet meer bij het parseren van numerieke tekenreeksen buiten het bereik. In plaats daarvan retourneren de Double parseringsmethoden voor waarden die groter zijn Double.MaxValuedan , en ze retourneren voor Double.NegativeInfinity waarden die kleiner zijn dan Double.MinValue.Double.PositiveInfinity Op dezelfde manier retourneren de Single parseringsmethoden voor waarden die groter zijn dan Single.MaxValueen ze retourneren voor Single.NegativeInfinity waarden die kleiner zijn dan Single.MinValue.Single.PositiveInfinity
Deze wijziging is aangebracht voor verbeterde naleving van IEEE 754:2008.
3,0
Deze wijziging kan op twee manieren van invloed zijn op uw code:
Uw code is afhankelijk van de handler die moet OverflowException worden uitgevoerd wanneer er een overloop plaatsvindt. In dit geval moet u de
catch
instructie verwijderen en eventueel benodigde code plaatsen in eenIf
instructie die test of Double.IsInfinity Single.IsInfinity istrue
.In uw code wordt ervan uitgegaan dat drijvendekommawaarden niet
Infinity
zijn. In dit geval moet u de benodigde code toevoegen om te controleren op drijvende-kommawaarden vanPositiveInfinity
enNegativeInfinity
.
Core .NET-bibliotheken
De InvalidAsynchronousStateException klas is verplaatst.
In .NET Core 2.2 en eerdere versies vindt u de InvalidAsynchronousStateException klasse in de assembly System.ComponentModel.TypeConverter .
Vanaf .NET Core 3.0 vindt u deze in de assembly System.ComponentModel.Primitives .
3,0
Deze wijziging is alleen van invloed op toepassingen die gebruikmaken van weerspiegeling om de InvalidAsynchronousStateException belasting aan te brengen door een methode aan te roepen, zoals Assembly.GetType of een overbelasting van Activator.CreateInstance die ervan uitgaat dat het type zich in een bepaalde assembly bevindt. Als dat het geval is, werkt u de assembly bij waarnaar wordt verwezen in de methode-aanroep om de nieuwe assemblylocatie van het type weer te geven.
Core .NET-bibliotheken
Geen.
Wanneer de UTF8Encoding klasse een slecht gevormdE UTF-8-bytereeks tegenkomt tijdens een transcoderingsbewerking van byte-naar-teken, wordt deze reeks vervangen door een '-teken (U+FFFD REPLACEMENT CHARACTER) in de uitvoertekenreeks. .NET Core 3.0 verschilt van eerdere versies van .NET Core en .NET Framework door de Unicode-best practice te volgen voor het uitvoeren van deze vervanging tijdens de transcoderingsbewerking.
Dit maakt deel uit van een grotere inspanning om de verwerking van UTF-8 in .NET te verbeteren, waaronder door de nieuwe System.Text.Unicode.Utf8 typen System.Text.Rune . Het UTF8Encoding type kreeg verbeterde mechanica voor foutafhandeling, zodat deze uitvoer consistent produceert met de nieuw geïntroduceerde typen.
Vanaf .NET Core 3.0 voert de UTF8Encoding klasse bij het transcoderingen van bytes naar tekens tekenvervanging uit op basis van de aanbevolen unicode-procedures. Het gebruikte vervangingsmechanisme wordt beschreven door de Unicode-standaard, versie 12.0, sec. 3.9 (PDF) in de kop met de titel U+FFFD Substitute of Maximal Subparts.
Dit gedrag is alleen van toepassing wanneer de invoer bytevolgorde ongeldige UTF-8-gegevens bevat. Als het UTF8Encoding exemplaar is samengesteld, throwOnInvalidBytes: true
blijft het UTF8Encoding
exemplaar bovendien ongeldige invoer invoeren in plaats van U+FFFD-vervanging uit te voeren. Zie voor meer informatie over de UTF8Encoding
constructor UTF8Encoding(Boolean, Boolean).
In de volgende tabel ziet u de impact van deze wijziging met een ongeldige invoer van 3 bytes:
Ziek gevormde 3-byteinvoer | Uitvoer vóór .NET Core 3.0 | Uitvoer vanaf .NET Core 3.0 |
---|---|---|
[ ED A0 90 ] |
[ FFFD FFFD ] (uitvoer van twee tekens) |
[ FFFD FFFD FFFD ] (Uitvoer van 3 tekens) |
De uitvoer van 3 tekens is de voorkeursuitvoer, volgens tabel 3-9 van de eerder gekoppelde Unicode Standard PDF.
3,0
Er is geen actie vereist voor het deel van de ontwikkelaar.
Core .NET-bibliotheken
De TypeDescriptionProviderAttribute klas is verplaatst.
In .NET Core 2.2 en eerdere versies vindt u de TypeDescriptionProviderAttribute klasse in de assembly System.ComponentModel.TypeConverter .
Vanaf .NET Core 3.0 vindt u deze in de System.ObjectModel-assembly .
3,0
Deze wijziging is alleen van invloed op toepassingen die gebruikmaken van weerspiegeling om het TypeDescriptionProviderAttribute type te laden door een methode aan te roepen, zoals Assembly.GetType of een overbelasting waarvan Activator.CreateInstance wordt uitgegaan dat het type zich in een bepaalde assembly bevindt. Als dat het geval is, moet de assembly waarnaar wordt verwezen in de methode-aanroep worden bijgewerkt om de nieuwe assemblylocatie van het type weer te geven.
Windows Forms
Geen.
Zip-archieven vermelden zowel gecomprimeerde grootte als niet-gecomprimeerde grootte in de centrale map en lokale header. De invoergegevens zelf geven ook de grootte aan. In .NET Core 2.2 en eerdere versies zijn deze waarden nooit gecontroleerd op consistentie. Vanaf .NET Core 3.0 zijn ze dat nu.
In .NET Core 2.2 en eerdere versies slaagt het zelfs ZipArchiveEntry.Open() als de lokale header het niet eens is met de centrale header van het zip-bestand. Gegevens worden gedecomprimeerd totdat het einde van de gecomprimeerde stroom is bereikt, zelfs als de lengte groter is dan de niet-gecomprimeerde bestandsgrootte die wordt vermeld in de centrale map/lokale header.
Vanaf .NET Core 3.0 controleert de methode of de ZipArchiveEntry.Open() lokale header en de centrale header overeenkomen met gecomprimeerde en niet-gecomprimeerde grootten van een vermelding. Als dat niet zo is, genereert de methode een InvalidDataException lijstgrootte van de lokale header en/of gegevensdescriptor van het archief die niet overeenkomen met de centrale map van het zip-bestand. Bij het lezen van een vermelding worden gedecomprimeerde gegevens afgekapt tot de niet-gecomprimeerde bestandsgrootte die wordt vermeld in de koptekst.
Deze wijziging is aangebracht om ervoor te zorgen dat de ZipArchiveEntry grootte van de gegevens correct wordt aangegeven en dat alleen die hoeveelheid gegevens wordt gelezen.
3,0
Pak een zip-archief opnieuw dat deze problemen vertoont.
Core .NET-bibliotheken
- ZipArchiveEntry.Open()
- ZipFileExtensions.ExtractToDirectory
- ZipFileExtensions.ExtractToFile
- ZipFile.ExtractToDirectory
Vanaf .NET Core 3.0 wordt er een uitzondering gegenereerd wanneer u probeert een waarde in te stellen voor een statisch InitOnly veld door aan te roepen System.Reflection.FieldInfo.SetValue.
In .NET Framework en versies van .NET Core vóór 3.0 kunt u de waarde instellen van een statisch veld dat constant is nadat het is geïnitialiseerd (gelezen in C#) door aan te roepen System.Reflection.FieldInfo.SetValue. Het instellen van een dergelijk veld op deze manier resulteerde echter in onvoorspelbaar gedrag op basis van het doelframework en optimalisatie-instellingen.
In .NET Core 3.0 en latere versies wordt er een System.FieldAccessException uitzondering gegenereerd wanneer u een statisch InitOnly veld aanroeptSetValue.
Tip
Een InitOnly veld is een veld dat alleen kan worden ingesteld op het moment dat het wordt gedeclareerd of in de constructor voor de betreffende klasse. Met andere woorden, het is constant nadat deze is geïnitialiseerd.
3,0
Initialiseer statische velden InitOnly in een statische constructor. Dit geldt zowel voor dynamische als niet-dynamische typen.
U kunt het FieldAttributes.InitOnly kenmerk ook verwijderen uit het veld en vervolgens aanroepen FieldInfo.SetValue.
Core .NET-bibliotheken
- FieldInfo.SetValue(Object, Object)
- FieldInfo.SetValue(Object, Object, BindingFlags, Binder, CultureInfo)
Het doorgeven van GroupCollection aan extensiemethoden die IEnumerable<T> gebruiken, vereist ondubbelzinnigheid
Wanneer u een extensiemethode aanroept die een IEnumerable<T>
op een GroupCollectionaanneemt, moet u het type ondubbelzinnig maken met behulp van een cast.
Vanaf .NET Core 3.0 worden System.Text.RegularExpressions.GroupCollection IEnumerable<KeyValuePair<String,Group>>
naast de andere typen geïmplementeerd, waaronder IEnumerable<Group>
. Dit resulteert in dubbelzinnigheid bij het aanroepen van een extensiemethode die een IEnumerable<T>. Als u een dergelijke extensiemethode op een GroupCollection exemplaar aanroept, Enumerable.Countziet u bijvoorbeeld de volgende compilerfout:
CS1061: 'GroupCollection' bevat geen definitie voor 'Count' en geen toegankelijke uitbreidingsmethode 'Count' die een eerste argument van het type GroupCollection accepteert (ontbreekt er een using-instructie of een assemblyverwijzing?)
In eerdere versies van .NET was er geen dubbelzinnigheid en geen compilerfout.
3,0
Dit was een onbedoelde wijziging die fouten veroorzaken. Omdat het al een tijdje zo is, zijn we niet van plan om het terug te keren. Bovendien zou een dergelijke wijziging zelf breken.
Zo GroupCollection kunt u aanroepen naar extensiemethoden die een IEnumerable<T>
met een cast accepteren, niet eenduidig maken.
// Without a cast - causes CS1061.
match.Groups.Count(_ => true)
// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);
Core .NET-bibliotheken
Elke extensiemethode die een IEnumerable<T> accepteert, wordt beïnvloed. Voorbeeld:
- System.Collections.Immutable.ImmutableArray.ToImmutableArray<TSource>(IEnumerable<TSource>)
- System.Collections.Immutable.ImmutableDictionary.ToImmutableDictionary
- System.Collections.Immutable.ImmutableHashSet.ToImmutableHashSet
- System.Collections.Immutable.ImmutableList.ToImmutableList<TSource>(IEnumerable<TSource>)
- System.Collections.Immutable.ImmutableSortedDictionary.ToImmutableSortedDictionary
- System.Collections.Immutable.ImmutableSortedSet.ToImmutableSortedSet
- System.Data.DataTableExtensions.CopyToDataTable
System.Linq.Enumerable
De meeste methoden, bijvoorbeeldSystem.Linq.Enumerable.Count- System.Linq.ParallelEnumerable.AsParallel
- System.Linq.Queryable.AsQueryable
- BEGIN TRUSTED CERTIFICATE syntaxis niet meer ondersteund in Linux
- EnvelopdCms is standaard ingesteld op AES-256-versleuteling
- Minimale grootte voor het genereren van RSAOpenSsl-sleutels is toegenomen
- .NET Core 3.0 geeft de voorkeur aan OpenSSL 1.1.x naar OpenSSL 1.0.x
- CryptoStream.Dispose transformeert het laatste blok alleen bij het schrijven
Basiscertificaten op Linux- en andere Unix-achtige systemen (maar niet macOS) kunnen in twee vormen worden weergegeven: de standaard BEGIN CERTIFICATE
PEM-header en de OpenSSL-specifieke BEGIN TRUSTED CERTIFICATE
PEM-header. Met deze laatste syntaxis kunt u aanvullende configuraties uitvoeren die compatibiliteitsproblemen met de klasse van .NET Core System.Security.Cryptography.X509Certificates.X509Chain hebben veroorzaakt. BEGIN TRUSTED CERTIFICATE
De inhoud van het basiscertificaat wordt niet meer geladen door de keten-engine die begint in .NET Core 3.0.
Voorheen werden zowel de als de BEGIN CERTIFICATE
BEGIN TRUSTED CERTIFICATE
syntaxis gebruikt om de hoofdvertrouwenslijst te vullen. Als de BEGIN TRUSTED CERTIFICATE
syntaxis is gebruikt en er extra opties zijn opgegeven in het bestand, X509Chain kan het zijn dat de vertrouwensrelatie van de keten expliciet is toegestaan (X509ChainStatusFlags.ExplicitDistrust). Als het certificaat echter ook is opgegeven met de BEGIN CERTIFICATE
syntaxis in een eerder geladen bestand, is de vertrouwensrelatie van de keten toegestaan.
Vanaf .NET Core 3.0 BEGIN TRUSTED CERTIFICATE
wordt de inhoud niet meer gelezen. Als het certificaat niet ook wordt opgegeven via een standaardsyntaxis BEGIN CERTIFICATE
, worden de X509Chain rapporten gerapporteerd dat de basis niet wordt vertrouwd (X509ChainStatusFlags.UntrustedRoot).
3,0
De meeste toepassingen worden niet beïnvloed door deze wijziging, maar toepassingen die beide basiscertificaatbronnen niet kunnen zien vanwege problemen met machtigingen, kunnen onverwachte UntrustedRoot
fouten optreden na de upgrade.
Veel Linux-distributies (of distributies) schrijven basiscertificaten naar twee locaties: een map met één certificaat per bestand en een samenvoeging van één bestand. In sommige distributies gebruikt de map met één certificaat per bestand de BEGIN TRUSTED CERTIFICATE
syntaxis terwijl de bestandssamenvoeging gebruikmaakt van de standaardsyntaxis BEGIN CERTIFICATE
. Zorg ervoor dat aangepaste basiscertificaten worden toegevoegd als BEGIN CERTIFICATE
op ten minste één van deze locaties en dat beide locaties door uw toepassing kunnen worden gelezen.
De typische map is /etc/ssl/certs/ en het typische samengevoegde bestand is /etc/ssl/cert.pem. Gebruik de opdracht openssl version -d
om de platformspecifieke hoofdmap te bepalen, die kan verschillen van /etc/ssl/. Op Ubuntu 18.04 is de map bijvoorbeeld /usr/lib/ssl/certs/ en is het bestand /usr/lib/ssl/cert.pem. /usr/lib/ssl/certs/ is echter een symlink naar /etc/ssl/certs/ en /usr/lib/ssl/cert.pem bestaat niet.
$ 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
Cryptografie
Het standaard symmetrische versleutelingsalgoritmen dat door EnvelopedCms
wordt gebruikt, zijn gewijzigd van TripleDES in AES-256.
In eerdere versies, wanneer EnvelopedCms wordt gebruikt voor het versleutelen van gegevens zonder een symmetrisch versleutelingsalgoritmen op te geven via een overbelasting van een constructor, worden de gegevens versleuteld met het algoritme TripleDES/3DES/3DEA/DES3-EDE.
Vanaf .NET Core 3.0 (via versie 4.6.0 van het NuGet-pakket System.Security.Cryptography.Pkcs ) is het standaardalgoritmen gewijzigd in AES-256 voor modernisering van algoritmen en om de beveiliging van standaardopties te verbeteren. Als een certificaat van de ontvanger van een bericht een openbare diffie-Hellman-sleutel heeft, kan de versleutelingsbewerking mislukken vanwege CryptographicException beperkingen in het onderliggende platform.
In de volgende voorbeeldcode worden de gegevens versleuteld met TripleDES als ze worden uitgevoerd op .NET Core 2.2 of eerder. Als deze wordt uitgevoerd op .NET Core 3.0 of hoger, wordt deze versleuteld met AES-256.
EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();
3,0
Als u negatieve gevolgen ondervindt van de wijziging, kunt u TripleDES-versleuteling herstellen door expliciet de id van het versleutelingsalgoritmen op te geven in een EnvelopedCms constructor die een parameter van het type AlgorithmIdentifierbevat, zoals:
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();
Cryptografie
De minimale grootte voor het genereren van nieuwe RSA-sleutels in Linux is verhoogd van 384-bits naar 512-bits.
Vanaf .NET Core 3.0 is de minimale wettelijke sleutelgrootte gerapporteerd door de LegalKeySizes
eigenschap op RSA-exemplaren van RSA.Createen RSAOpenSslRSACryptoServiceProvider op Linux verhoogd van 384 tot 512.
Als gevolg hiervan wordt in .NET Core 2.2 en eerdere versies een methode-aanroep zoals RSA.Create(384)
geslaagd. In .NET Core 3.0 en latere versies genereert de methodeaanroep RSA.Create(384)
een uitzondering die aangeeft dat de grootte te klein is.
Deze wijziging is aangebracht omdat OpenSSL, waarmee de cryptografische bewerkingen op Linux worden uitgevoerd, het minimum tussen versie 1.0.2 en 1.1.0 verhoogd. .NET Core 3.0 geeft de voorkeur aan OpenSSL 1.1.x tot 1.0.x en de minimaal gerapporteerde versie is verhoogd om deze nieuwe hogere afhankelijkheidsbeperking weer te geven.
3,0
Als u een van de betrokken API's aanroept, moet u ervoor zorgen dat de grootte van gegenereerde sleutels niet kleiner is dan het minimum van de provider.
Notitie
384-bits RSA wordt al als onveilig beschouwd (net als 512-bits RSA). Moderne aanbevelingen, zoals NIST Special Publication 800-57 Deel 1 Revisie 4, suggereren 2048-bits als de minimale grootte voor nieuw gegenereerde sleutels.
Cryptografie
.NET Core voor Linux, die in meerdere Linux-distributies werkt, kan zowel OpenSSL 1.0.x als OpenSSL 1.1.x ondersteunen. .NET Core 2.1 en .NET Core 2.2 zoeken eerst naar 1.0.x en vervolgens terugvallen op 1.1.x; .NET Core 3.0 zoekt eerst naar 1.1.x. Deze wijziging is aangebracht om ondersteuning toe te voegen voor nieuwe cryptografische standaarden.
Deze wijziging kan van invloed zijn op bibliotheken of toepassingen die platforminteroperabiliteit uitvoeren met de OpenSSL-specifieke interoptypen in .NET Core.
In .NET Core 2.2 en eerdere versies geeft de runtime de voorkeur aan het laden van OpenSSL 1.0.x boven 1.1.x. Dit betekent dat de IntPtr en SafeHandle typen voor interop met OpenSSL worden gebruikt met libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 op voorkeur.
Vanaf .NET Core 3.0 geeft de runtime de voorkeur aan het laden van OpenSSL 1.1.x via OpenSSL 1.0.x, zodat de IntPtr en SafeHandle typen voor interop met OpenSSL worden gebruikt met libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 per voorkeur. Als gevolg hiervan kunnen bibliotheken en toepassingen die rechtstreeks met OpenSSL samenwerken, incompatibele aanwijzers hebben met de .NET Core-waarden bij het upgraden van .NET Core 2.1 of .NET Core 2.2.
3,0
Bibliotheken en toepassingen die directe bewerkingen uitvoeren met OpenSSL, moeten ervoor zorgen dat ze dezelfde versie van OpenSSL gebruiken als de .NET Core-runtime.
Alle bibliotheken of toepassingen die gebruikmaken IntPtr van of SafeHandle waarden van de cryptografische .NET Core-typen rechtstreeks met OpenSSL, moeten de versie van de bibliotheek die ze gebruiken met de nieuwe SafeEvpPKeyHandle.OpenSslVersion eigenschap vergelijken om ervoor te zorgen dat de aanwijzers compatibel zijn.
Cryptografie
- SafeEvpPKeyHandle
- RSAOpenSsl(IntPtr)
- RSAOpenSsl(SafeEvpPKeyHandle)
- RSAOpenSsl.DuplicateKeyHandle()
- DSAOpenSsl(IntPtr)
- DSAOpenSsl(SafeEvpPKeyHandle)
- DSAOpenSsl.DuplicateKeyHandle()
- ECDsaOpenSsl(IntPtr)
- ECDsaOpenSsl(SafeEvpPKeyHandle)
- ECDsaOpenSsl.DuplicateKeyHandle()
- ECDiffieHellmanOpenSsl(IntPtr)
- ECDiffieHellmanOpenSsl(SafeEvpPKeyHandle)
- ECDiffieHellmanOpenSsl.DuplicateKeyHandle()
- X509Certificate.Handle
De CryptoStream.Dispose methode, die wordt gebruikt om bewerkingen te voltooien CryptoStream
, probeert het laatste blok niet meer te transformeren bij het lezen.
Als een gebruiker in eerdere .NET-versies een onvolledige leesbewerking heeft uitgevoerd bij CryptoStream gebruik in Read de modus, kan de Dispose methode een uitzondering genereren (bijvoorbeeld bij het gebruik van AES met opvulling). De uitzondering is opgetreden omdat het uiteindelijke blok is geprobeerd te worden getransformeerd, maar de gegevens onvolledig waren.
In .NET Core 3.0 en latere versies Dispose wordt niet langer geprobeerd het laatste blok te transformeren bij het lezen, waardoor onvolledige leesbewerkingen mogelijk zijn.
Met deze wijziging kunnen onvolledige leesbewerkingen uit de cryptostroom worden uitgevoerd wanneer een netwerkbewerking wordt geannuleerd, zonder dat er een uitzondering hoeft te worden afgevangen.
3,0
De meeste apps mogen niet worden beïnvloed door deze wijziging.
Als uw toepassing eerder een uitzondering heeft opgetreden in het geval van een onvolledige leesbewerking, kunt u dat catch
blok verwijderen.
Als uw app het transformeren van het laatste blok in hashscenario's heeft gebruikt, moet u er mogelijk voor zorgen dat de hele stream wordt gelezen voordat deze wordt verwijderd.
Cryptografie
Wijzigingen die fouten veroorzaken in Entity Framework
.NET Core 2.2 en eerdere versies zijn afhankelijk van het standaard-ICU-gedrag, waarmee de landinstelling C wordt toegewezen aan de en_US_POSIX landinstelling. De en_US_POSIX landinstelling heeft een ongewenst sorteringsgedrag, omdat deze geen ondersteuning biedt voor hoofdlettergevoelige tekenreeksvergelijkingen. Omdat sommige Linux-distributies de landinstelling 'C' instellen als de standaardlandinstelling, ondervonden gebruikers onverwacht gedrag.
Vanaf .NET Core 3.0 is de landinstellingstoewijzing 'C' gewijzigd om de landinstelling Invariant te gebruiken in plaats van en_US_POSIX. De landinstelling 'C' voor invarianttoewijzing wordt ook toegepast op Windows voor consistentie.
Door 'C' toe te voegen aan en_US_POSIX cultuur is er verwarring op de klant ontstaan, omdat en_US_POSIX geen hoofdlettergevoelige sorteer-/zoekreeksbewerkingen ondersteunt. Omdat de landinstelling 'C' wordt gebruikt als een standaardlandinstelling in sommige linux-distributies, hebben klanten dit ongewenste gedrag op deze besturingssystemen ervaren.
3,0
Niets specifieks meer dan het bewustzijn van deze verandering. Deze wijziging is alleen van invloed op toepassingen die gebruikmaken van de landinstelling 'C'.
Globalisatie
Alle sorterings- en cultuur-API's worden beïnvloed door deze wijziging.
Vanaf .NET Core 3.0 genereert MSBuild in het standaardscenario een andere manifestbestandsnaam voor resourcebestanden.
3,0
Vóór .NET Core 3.0, als er geen LogicalName
, ManifestResourceName
of DependentUpon
metagegevens zijn opgegeven voor een EmbeddedResource
item in het projectbestand, heeft MSBuild een manifestbestandsnaam in het patroon <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources
gegenereerd. Als RootNamespace
dit niet is gedefinieerd in het projectbestand, wordt deze standaard ingesteld op de projectnaam. De gegenereerde manifestnaam voor een resourcebestand met de naam Form1.resx in de hoofdprojectmap was bijvoorbeeld MyProject.Form1.resources.
Vanaf .NET Core 3.0 gebruikt MSBuild typegegevens uit het bronbestand om de manifestbestandsnaam in het patroon te genereren, te beginnen in .NET Core 3 Form1.cs.0.<Namespace>.<ClassName>.resources
De naamruimte en klassenaam worden geëxtraheerd uit het eerste type in het bronbestand met een colocatie. Bijvoorbeeld de gegenereerde manifestnaam voor een resourcebestand met de naam Form1.resx dat zich bevindt op een bronbestand met de naam Form1.cs MyNamespace.Form1.resources is. Het belangrijkste om op te merken is dat het eerste deel van de bestandsnaam verschilt van eerdere versies van .NET Core (MyNamespace in plaats van MyProject).
Notitie
Als u , ManifestResourceName
of DependentUpon
metagegevens hebt LogicalName
opgegeven voor een EmbeddedResource
item in het projectbestand, heeft deze wijziging geen invloed op dat resourcebestand.
Deze belangrijke wijziging is geïntroduceerd met de toevoeging van de EmbeddedResourceUseDependentUponConvention
eigenschap aan .NET Core-projecten. Resourcebestanden worden standaard niet expliciet vermeld in een .NET Core-projectbestand, dus ze hebben geen DependentUpon
metagegevens om op te geven hoe het gegenereerde .resources-bestand een naam moet geven. Wanneer EmbeddedResourceUseDependentUponConvention
dit is ingesteld true
op , wat de standaardinstelling is, zoekt MSBuild naar een bronbestand met eencolocated en extraheert een naamruimte en klassenaam uit dat bestand. Als u deze optie instelt EmbeddedResourceUseDependentUponConvention
false
, genereert MSBuild de manifestnaam op basis van het vorige gedrag, dat combineert RootNamespace
en het relatieve bestandspad.
In de meeste gevallen is er geen actie vereist voor de ontwikkelaar en moet uw app blijven werken. Als deze wijziging uw app echter onderbreekt, kunt u het volgende doen:
Wijzig de code om de naam van het nieuwe manifest te verwachten.
Meld u af voor de nieuwe naamconventie door deze in te stellen
EmbeddedResourceUseDependentUponConvention
false
in uw projectbestand.<PropertyGroup> <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention> </PropertyGroup>
MSBuild
N.v.t.
De standaardwaarde van de System.Net.Http.HttpRequestMessage.Version eigenschap is gewijzigd van 2.0 in 1.1.
3,0
In .NET Core 1.0 tot en met 2.0 is de standaardwaarde van de System.Net.Http.HttpRequestMessage.Version eigenschap 1.1. Vanaf .NET Core 2.1 is het gewijzigd in 2.1.
Vanaf .NET Core 3.0 is het standaardversienummer dat door de System.Net.Http.HttpRequestMessage.Version eigenschap wordt geretourneerd, opnieuw 1.1.
Werk uw code bij als deze afhankelijk is van de System.Net.Http.HttpRequestMessage.Version eigenschap die een standaardwaarde van 2.0 retourneert.
Netwerken
.NET Core 3.0 heeft een wijziging geïntroduceerd in de wijze waarop besturingselementen van de teksteditor een System.Windows.DataObject maken bij het slepen van tekst naar een ander besturingselement. De wijziging heeft automatische conversie uitgeschakeld, waardoor de bewerking de gegevens bewaart als DataFormats.Text of DataFormats.UnicodeText in plaats van deze te converteren naar DataFormats.StringFormat.
.NET Core 3.0
Windows Presentation Foundation
Het gegevenstype aan System.Windows.DataObject bij het slepen van tekst vanuit een besturingselement voor teksteditor was DataFormats.StringFormat.
Het gegevenstype aan System.Windows.DataObject bij het slepen van tekst vanuit een besturingselement voor teksteditor is DataFormats.Text of DataFormats.UnicodeText.
Deze wijziging is een gedragswijziging.
De wijziging was onbedoeld.
Deze wijziging is teruggedraaid in .NET 7. Voer een upgrade uit naar .NET 7 of hoger.
.NET-feedback
.NET is een open source project. Selecteer een koppeling om feedback te geven: