Share via

Belangrijke wijzigingen in .NET Core 3.0

  • Artikel

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.

ASP.NET Core

Verouderde antiforgery-, CORS-, diagnostische, MVC- en routerings-API's verwijderd

Verouderde leden en compatibiliteitsswitches in ASP.NET Core 2.2 zijn verwijderd.

Versie geïntroduceerd

3,0

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

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

"Pubternal" API's verwijderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

De betrokken API's worden gemarkeerd met de public toegangsaanpassing en bestaan in *.Internal naamruimten.

Nieuw gedrag

De betrokken API's worden gemarkeerd met de interne toegangsaanpassing en kunnen niet meer worden gebruikt door code buiten die assembly.

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

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

Verificatie: Google+ afgeschaft en vervangen

Google begint met het afsluiten van Google+ Aanmelding voor apps vanaf 28 januari 2019.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

Alle versies. Deze wijziging is extern voor ASP.NET Core.

Owin met ASP.NET Web Forms en MVC

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.

ASP.NET Core 1.x

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.

ASP.NET Core 2.x

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.

ASP.NET Core 3.0

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

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Authentication.Google

Verificatie: de eigenschap HttpContext.Authentication is verwijderd

De afgeschafte Authentication eigenschap is HttpContext verwijderd.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Reden voor wijziging

ASP.NET Core 1.0 API's zijn vervangen door extensiemethoden in Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Zie de migratiehandleiding.

Categorie

ASP.NET Core

Betrokken API's

Verificatie: Newtonsoft.Json-typen vervangen

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.

Versie geïntroduceerd

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:

Categorie

ASP.NET Core

Betrokken API's

Verificatie: OAuthHandler ExchangeCodeAsync-handtekening is gewijzigd

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

Versie geïntroduceerd

3,0

Oud gedrag

De code en redirectUri tekenreeksen zijn doorgegeven als afzonderlijke argumenten.

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorisatie: Overbelasting van AddAuthorization verplaatst naar een andere assembly

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.

Versie geïntroduceerd

3,0

Oud gedrag

AddAuthorization methoden bestonden in Microsoft.AspNetCore.Authorization.

Nieuw gedrag

AddAuthorization methoden bestaan in Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore is de nieuwe naam voor de oude methoden.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

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

Autorisatie: IAllowAnonymous verwijderd uit AuthorizationFilterContext.Filters

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.

Versie geïntroduceerd

3,0

Oud gedrag

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.

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Autorisatie: IAuthorizationPolicyProvider-implementaties vereisen een nieuwe methode

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.

Versie geïntroduceerd

3,0

Oud gedrag

Implementaties van IAuthorizationPolicyProvider hebben geen methode nodig GetFallbackPolicyAsync .

Nieuw gedrag

Implementaties van IAuthorizationPolicyProvider vereisen een GetFallbackPolicyAsync methode.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Caching: Eigenschap CompactOnMemoryPressure verwijderd

De ASP.NET Core 3.0-release heeft de verouderde MemoryCacheOptions-API's verwijderd.

Wijzigingsbeschrijving

Deze wijziging is een vervolg op aspnet/Caching#221. Zie dotnet/extensions#1062 voor discussie.

Versie geïntroduceerd

3,0

Oud gedrag

MemoryCacheOptions.CompactOnMemoryPressure eigenschap was beschikbaar.

Nieuw gedrag

De MemoryCacheOptions.CompactOnMemoryPressure eigenschap is verwijderd.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

MemoryCacheOptions.CompactOnMemoryPressure

Caching: Microsoft.Extensions.Caching.SqlServer maakt gebruik van een nieuw SqlClient-pakket

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.

Versie geïntroduceerd

3,0

Oud gedrag

Het Microsoft.Extensions.Caching.SqlServer pakket heeft het System.Data.SqlClient pakket gebruikt.

Nieuw gedrag

Microsoft.Extensions.Caching.SqlServer maakt nu gebruik van het Microsoft.Data.SqlClient pakket.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Caching: ResponseCaching -typen 'pubternal' zijn gewijzigd in intern

In ASP.NET Core 3.0 zijn 'pubternal'-typen gewijzigd internalin ResponseCaching .

Daarnaast worden standaard implementaties van IResponseCachingPolicyProvider en IResponseCachingKeyProvider niet meer toegevoegd aan services als onderdeel van de AddResponseCaching methode.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Oud gedrag

Deze typen zijn openbaar zichtbaar, maar niet ondersteund.

Nieuw gedrag

Deze typen zijn nu internal.

Reden voor wijziging

Het internal bereik weerspiegelt het niet-ondersteunde beleid beter.

Kopieertypen die worden gebruikt door uw app of bibliotheek.

Categorie

ASP.NET Core

Betrokken API's

Gegevensbescherming: DataProtection.Blobs maakt gebruik van nieuwe Azure Storage-API's

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.

Versie geïntroduceerd

3,0

Oud gedrag

Het pakket verwijst naar het WindowsAzure.Storage NuGet-pakket. Het pakket verwijst naar het Microsoft.Azure.Storage.Blob NuGet-pakket.

Nieuw gedrag

Het pakket verwijst naar het Azure.Storage.Blob NuGet-pakket.

Reden voor wijziging

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;

Categorie

ASP.NET Core

Betrokken API's

Geen

Hosting: AspNetCoreModule V1 verwijderd uit Windows Hosting Bundle

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.

Versie geïntroduceerd

3,0

Oud gedrag

ANCM V1 is opgenomen in de Windows Hosting Bundle.

Nieuw gedrag

ANCM V1 is niet opgenomen in de Windows Hosting Bundle.

Reden voor wijziging

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" />.

Categorie

ASP.NET Core

Betrokken API's

Geen

Hosting: Algemene host beperkt opstartconstructorinjectie

De enige typen die de algemene host ondersteunt voor Startup klasseconstructorinjectie zijn IHostEnvironment, IWebHostEnvironmenten IConfiguration. Apps die worden gebruikt WebHost , worden niet beïnvloed.

Wijzigingsbeschrijving

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:

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

ASP.NET Core 3.0:

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

Host 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, IWebHostEnvironmenten IConfiguration kunnen worden geïnjecteerd. Deze wijziging voorkomt DI-problemen, zoals het dupliceren van een singleton-service.

Versie geïntroduceerd

3,0

Reden voor wijziging

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)

Categorie

ASP.NET Core

Betrokken API's

Geen

Hosting: HTTPS-omleiding ingeschakeld voor out-of-process-apps van IIS

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.

Versie geïntroduceerd

3,0

Oud gedrag

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.

Nieuw gedrag

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.

Reden voor wijziging

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 en UseHsts naar de methode van Startup.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 voorgaande ASPNETCORE_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.

Categorie

ASP.NET Core

Betrokken API's

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hosting: IHostingEnvironment- en IApplicationLifetime-typen gemarkeerd als verouderd en vervangen

Er zijn nieuwe typen geïntroduceerd om bestaande IHostingEnvironment en IApplicationLifetime typen te vervangen.

Versie geïntroduceerd

3,0

Oud gedrag

Er waren twee verschillende IHostingEnvironment en IApplicationLifetime typen van Microsoft.Extensions.Hosting en Microsoft.AspNetCore.Hosting.

Nieuw gedrag

De oude typen zijn gemarkeerd als verouderd en vervangen door nieuwe typen.

Reden voor wijziging

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

Nieuwe typen:

De nieuwe IHostEnvironment IsDevelopment en IsProduction extensiemethoden bevinden zich in de Microsoft.Extensions.Hosting naamruimte. Deze naamruimte moet mogelijk worden toegevoegd aan uw project.

Categorie

ASP.NET Core

Betrokken API's

Hosting: ObjectPoolProvider verwijderd uit WebHostBuilder-afhankelijkheden

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.

Versie geïntroduceerd

3,0

Oud gedrag

WebHostBuilder biedt ObjectPoolProvider standaard in de DI-container.

Nieuw gedrag

WebHostBuilder biedt ObjectPoolProvider niet meer standaard in de DI-container.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

HTTP: DefaultHttpContext-uitbreidbaarheid verwijderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

Klassen kunnen worden afgeleid van DefaultHttpContext.

Nieuw gedrag

Klassen kunnen niet worden afgeleid van DefaultHttpContext.

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames-constanten zijn gewijzigd in statisch alleen-lezen

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.

Versie geïntroduceerd

3,0

Oud gedrag

Deze velden waren constvroeger .

Nieuw gedrag

Deze velden zijn nu static readonly.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Wijzigingen in de infrastructuur van antwoordtekst

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.

Versie geïntroduceerd

3,0

Oud gedrag

Er zijn drie API's gekoppeld aan de HTTP-antwoordtekst:

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

Nieuw gedrag

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.

Reden voor wijziging

De motivatie is om de antwoordtekst-API's te combineren tot één nieuwe functie-interface.

Gebruik IHttpResponseBodyFeature waar u eerder gebruikte IHttpResponseFeature.Body, IHttpSendFileFeatureof IHttpBufferingFeature.

Categorie

ASP.NET Core

Betrokken API's

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.

Versie geïntroduceerd

3,0

Oud gedrag

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.

Nieuw gedrag

Alle betrokken API's zijn standaard ingesteld SameSiteMode.Noneop .

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

HTTP: Synchrone IO uitgeschakeld op alle servers

Vanaf ASP.NET Core 3.0 worden synchrone serverbewerkingen standaard uitgeschakeld.

Wijzigingsbeschrijving

AllowSynchronousIO is een optie op elke server die synchrone IO-API's zoals HttpRequest.Body.Read, HttpResponse.Body.Writeen 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 Disposewordt aangeroepen, roept u in plaats daarvan de nieuwe DisposeAsync API aan.

Zie dotnet/aspnetcore#7644 voor discussie.

Versie geïntroduceerd

3,0

Oud gedrag

HttpRequest.Body.Read, HttpResponse.Body.Writeen Stream.Flush standaard zijn toegestaan.

Nieuw gedrag

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.

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

Identiteit: Overbelasting van methode AddDefaultUI verwijderd

Vanaf ASP.NET Core 3.0 bestaat de methode IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) niet meer.

Versie geïntroduceerd

3,0

Reden voor wijziging

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>

Categorie

ASP.NET Core

Betrokken API's

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identiteit: de standaard Bootstrap-versie van de gebruikersinterface is gewijzigd

Vanaf ASP.NET Core 3.0 wordt de identiteitsgebruikersinterface standaard gebruikt met versie 4 van Bootstrap.

Versie geïntroduceerd

3,0

Oud gedrag

De services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); methode-aanroep was hetzelfde als services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nieuw gedrag

De services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); methode-aanroep is hetzelfde als services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

Geen

Identiteit: SignInAsync genereert uitzondering voor niet-geverifieerde identiteit

Genereert standaard SignInAsync een uitzondering voor principals/identiteiten waarin IsAuthenticated .false

Versie geïntroduceerd

3,0

Oud gedrag

SignInAsyncaccepteert alle principals/identiteiten, inclusief identiteiten waarin IsAuthenticated .false

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Identiteit: SignInManager-constructor accepteert nieuwe parameter

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.

Versie geïntroduceerd

3,0

Reden voor wijziging

De motivatie voor de wijziging was het toevoegen van ondersteuning voor nieuwe e-mail-/bevestigingsstromen in Identiteit.

Als u handmatig een SignInManagerafhankelijkheidsinjectie maakt, geeft u een implementatie van IUserConfirmation of pakt u een van de afhankelijkheidsinjectie die u wilt leveren.

Categorie

ASP.NET Core

Betrokken API's

SignInManager<TUser>

Identiteit: UI maakt gebruik van de functie statische webassets

ASP.NET Core 3.0 heeft een functie voor statische webactiva geïntroduceerd en de gebruikersinterface van identiteit heeft deze gebruikt.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Oud gedrag

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.

Nieuw gedrag

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.

Reden voor wijziging

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>

Categorie

ASP.NET Core

Betrokken API's

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Verbindingsadapters verwijderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

Kestrel-uitbreidbaarheidsonderdelen zijn gemaakt met behulp van IConnectionAdapter.

Nieuw gedrag

Kestrel-uitbreidbaarheidsonderdelen worden gemaakt als middleware.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

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

Kestrel: Lege HTTPS-assembly verwijderd

De assembly Microsoft.AspNetCore.Server.Kestrel.Https is verwijderd.

Versie geïntroduceerd

3,0

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Kestrel: Aanvraag trailer headers verplaatst naar nieuwe verzameling

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.

Versie geïntroduceerd

3,0

Oud gedrag

Aanvraagtrailerheaders worden toegevoegd aan de HttpRequest.Headers verzameling.

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

HttpRequest.Headers

Kestrel: Transportabstracties verwijderd en openbaar gemaakt

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.

Versie geïntroduceerd

3,0

Oud gedrag

  • Transportgerelateerde abstracties waren beschikbaar in de Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions bibliotheek.
  • De ListenOptions.NoDelay accommodatie was beschikbaar.

Nieuw gedrag

  • De IConnectionListener interface is geïntroduceerd in de Microsoft.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 en SocketTransportOptions).
  • SchedulingMode is niet meer beschikbaar.

Reden voor wijziging

ASP.NET Core 3.0 is verwijderd van 'pubternal'-API's.

Categorie

ASP.NET Core

Betrokken API's

Geen

Lokalisatie: ResourceManagerWithCultureStringLocalizer en WithCulture gemarkeerd als verouderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

Methoden zijn niet gemarkeerd als Obsolete.

Nieuw gedrag

Methoden worden gemarkeerd Obsolete.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

  • Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
  • Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture

Logboekregistratie: DebugLogger-klasse intern gemaakt

Vóór ASP.NET Core 3.0 was publicde DebugLoggertoegangsaanpassing . In ASP.NET Core 3.0 is de toegangsaanpassing gewijzigd in internal.

Versie geïntroduceerd

3,0

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Async-achtervoegsel afgekapt van controlleractienamen

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.

Versie geïntroduceerd

3,0

Oud gedrag

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>

Nieuw gedrag

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

Reden voor wijziging

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 in Startup.ConfigureServices:false
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Categorie

ASP.NET Core

Betrokken API's

Geen

MVC: JsonResult is verplaatst naar Microsoft.AspNetCore.Mvc.Core

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.

Versie geïntroduceerd

3.0 Preview 6

Oud gedrag

Een app die gebruikmaakt van een bibliotheek op basis van 2.2, bouwt met succes.

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Hulpprogramma voor precompilatie afgeschaft

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.

Versie geïntroduceerd

3,0

Oud gedrag

Het Microsoft.AspNetCore.Mvc.Razor.ViewCompilation pakket is gebruikt om MVC Razor-weergaven vooraf te compileren.

Nieuw gedrag

De Razor SDK biedt systeemeigen ondersteuning voor deze functionaliteit. Het Microsoft.AspNetCore.Mvc.Razor.ViewCompilation pakket wordt niet meer bijgewerkt.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

MVC: 'Pubternal'-typen zijn gewijzigd in intern

In ASP.NET Core 3.0 zijn alle typen 'pubternal' in MVC bijgewerkt naar public een ondersteunde naamruimte of internal naar behoren.

Wijzigingsbeschrijving

In ASP.NET Core worden 'pubternale' typen gedeclareerd als public maar zich in een .Internal-achtervoegselnaamruimte bevinden. Hoewel deze typen zijn, hebben publicze 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.

Versie geïntroduceerd

3,0

Oud gedrag

Sommige typen in MVC waren public maar in een .Internal naamruimte. Deze typen hadden geen ondersteuningsbeleid en waren onderhevig aan belangrijke wijzigingen.

Nieuw gedrag

Alle typen worden bijgewerkt zodat public ze zich in een ondersteunde naamruimte bevinden of als gemarkeerd internalzijn.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

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

MVC: Web-API-compatibiliteitsshim verwijderd

Vanaf ASP.NET Core 3.0 is het Microsoft.AspNetCore.Mvc.WebApiCompatShim pakket niet meer beschikbaar.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine-API verwijderd

De RazorTemplateEngine API is verwijderd en vervangen door Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Zie Voor discussie gitHub probleem dotnet/aspnetcore#25215.

Versie geïntroduceerd

3,0

Oud gedrag

Een sjabloonengine kan worden gemaakt en gebruikt om code voor Razor-bestanden te parseren en genereren.

Nieuw gedrag

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.

Reden voor wijziging

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 maken en configureren
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
        });
Code genereren voor een Razor-bestand
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();

Categorie

ASP.NET Core

Betrokken API's

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Runtime-compilatie is verplaatst naar een pakket

Ondersteuning voor runtimecompilatie van Razor-weergaven en Razor Pages is verplaatst naar een afzonderlijk pakket.

Versie geïntroduceerd

3,0

Oud gedrag

Runtimecompilatie is beschikbaar zonder extra pakketten nodig te hebben.

Nieuw gedrag

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 nu MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences is nu MvcRazorRuntimeCompilationOptions.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.

Reden voor wijziging

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:

  1. Voeg een verwijzing naar het Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation pakket toe.

  2. Werk de methode van Startup.ConfigureServices het project bij om een aanroep naar toe te AddRazorRuntimeCompilationvoegen. Voorbeeld:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Categorie

ASP.NET Core

Betrokken API's

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Sessiestatus: Verouderde API's verwijderd

Verouderde API's voor het configureren van sessiecookies zijn verwijderd. Zie aspnet/Aankondigingen#257 voor meer informatie.

Versie geïntroduceerd

3,0

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

Gedeeld framework: Assembly's verwijderd uit Microsoft.AspNetCore.App

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Oud gedrag

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)

Nieuw gedrag

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.

Reden voor wijziging

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:

Zie Stoppen met het produceren van pakketten voor gedeelde frameworkassembly's in 3.0 voor meer informatie. Zie dotnet/aspnetcore#3757 voor discussie.

Categorie

ASP.NET Core

Betrokken API's

Gedeeld framework: Microsoft.AspNetCore.All verwijderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

Apps kunnen de Microsoft.AspNetCore.All metapackage gebruiken om het Microsoft.AspNetCore.All gedeelde framework op .NET Core te richten.

Nieuw gedrag

.NET Core 3.0 bevat Microsoft.AspNetCore.All geen gedeeld framework.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

SignalR: HandshakeProtocol.SuccessHandshakeData vervangen

Het veld HandshakeProtocol.SuccessHandshakeData is verwijderd en vervangen door een helpermethode waarmee een geslaagd handshake-antwoord wordt gegenereerd op basis van een specifieke IHubProtocol.

Versie geïntroduceerd

3,0

Oud gedrag

HandshakeProtocol.SuccessHandshakeData was een public static ReadOnlyMemory<byte> veld.

Nieuw gedrag

HandshakeProtocol.SuccessHandshakeData is vervangen door een static GetSuccessfulHandshake(IHubProtocol protocol) methode die een ReadOnlyMemory<byte> op basis van het opgegeven protocol retourneert.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

HandshakeProtocol.SuccessHandshakeData

SignalR: HubConnection ResetSendPing- en ResetTimeout-methoden verwijderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

ER zijn API's beschikbaar.

Nieuw gedrag

API's worden verwijderd.

Reden voor wijziging

Deze methoden waren oorspronkelijk alleen bedoeld voor intern gebruik, maar werden openbaar gemaakt in ASP.NET Core 2.2.

Gebruik deze methoden niet.

Categorie

ASP.NET Core

Betrokken API's

SignalR: HubConnectionContext-constructors zijn gewijzigd

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.

Versie geïntroduceerd

3,0

Oud gedrag

HubConnectionContext heeft twee constructors:

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

Nieuw gedrag

De twee constructors zijn verwijderd en vervangen door één constructor:

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

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

SignalR: de naam van het JavaScript-clientpakket is gewijzigd

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.

Versie geïntroduceerd

3,0

Oud gedrag

Het clientpakket heeft de naam @aspnet/signalr.

Nieuw gedrag

Het clientpakket heeft de naam @microsoft/signalr.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

SignalR: UseSignalR- en UseConnections-methoden gemarkeerd als verouderd

De methoden UseConnections en UseSignalR de klassen ConnectionsRouteBuilder en HubRouteBuilder zijn gemarkeerd als verouderd in ASP.NET Core 3.0.

Versie geïntroduceerd

3,0

Oud gedrag

SignalR-hubroutering is geconfigureerd met of UseSignalR UseConnections.

Nieuw gedrag

De oude manier om routering te configureren, is verouderd en vervangen door eindpuntroutering.

Reden voor wijziging

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

Categorie

ASP.NET Core

Betrokken API's

SPA's: SpaServices en NodeServices gemarkeerd als verouderd

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.

Versie geïntroduceerd

3,0

Oud gedrag

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.

Nieuw gedrag

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.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

SPAs: SpaServices en NodeServices vallen niet meer terug op consolelogger

Microsoft.AspNetCore.SpaServices en Microsoft.AspNetCore.NodeServices geeft geen consolelogboeken weer, tenzij logboekregistratie is geconfigureerd.

Versie geïntroduceerd

3,0

Oud gedrag

Microsoft.AspNetCore.SpaServices en Microsoft.AspNetCore.NodeServices wordt gebruikt om automatisch een consolelogger te maken wanneer logboekregistratie niet is geconfigureerd.

Nieuw gedrag

Microsoft.AspNetCore.SpaServices en Microsoft.AspNetCore.NodeServices geeft geen consolelogboeken weer, tenzij logboekregistratie is geconfigureerd.

Reden voor wijziging

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Doelframework: .NET Framework-ondersteuning verwijderd

Vanaf ASP.NET Core 3.0 is .NET Framework een niet-ondersteund doelframework.

Wijzigingsbeschrijving

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

Versie geïntroduceerd

3,0

Oud gedrag

ASP.NET Core-apps kunnen worden uitgevoerd op .NET Core of .NET Framework.

Nieuw gedrag

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.

Categorie

ASP.NET Core

Betrokken API's

Geen

Core .NET-bibliotheken

API's die rapportversie nu rapporteren, rapporteren product en geen bestandsversie

Veel van de API's die versies retourneren in .NET Core retourneren, retourneren nu de productversie in plaats van de bestandsversie.

Wijzigingsbeschrijving

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.

Verschil in productversiegegevens

Versie geïntroduceerd

3,0

Geen. Deze wijziging moet versiedetectie intuïtief maken in plaats van obtuse.

Categorie

Core .NET-bibliotheken

Betrokken API's

Custom EncoderFallbackBuffer-exemplaren kunnen niet recursief terugvallen

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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.

Categorie

Core .NET-bibliotheken

Betrokken API's

Drijvende-kommaopmaak en parseringsgedrag gewijzigd

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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.

Categorie

Core .NET-bibliotheken

Betrokken API's

Drijvendekommaparseerbewerkingen mislukken niet meer of gooien een OverflowException

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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 een If instructie die test of Double.IsInfinity Single.IsInfinity is true.

  • In uw code wordt ervan uitgegaan dat drijvendekommawaarden niet Infinityzijn. In dit geval moet u de benodigde code toevoegen om te controleren op drijvende-kommawaarden van PositiveInfinity en NegativeInfinity.

Categorie

Core .NET-bibliotheken

Betrokken API's

InvalidAsynchronousStateException is verplaatst naar een andere assembly

De InvalidAsynchronousStateException klas is verplaatst.

Wijzigingsbeschrijving

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 .

Versie geïntroduceerd

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.

Categorie

Core .NET-bibliotheken

Betrokken API's

Geen.

Het vervangen van slecht gevormde UTF-8 bytereeksen volgt Unicode-richtlijnen

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.

Wijzigingsbeschrijving

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: trueblijft 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.

Versie geïntroduceerd

3,0

Er is geen actie vereist voor het deel van de ontwikkelaar.

Categorie

Core .NET-bibliotheken

Betrokken API's

TypeDescriptionProviderAttribute is verplaatst naar een andere assembly

De TypeDescriptionProviderAttribute klas is verplaatst.

Wijzigingsbeschrijving

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 .

Versie geïntroduceerd

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.

Categorie

Windows Forms

Betrokken API's

Geen.

ZipArchiveEntry verwerkt geen archieven meer met inconsistente invoergrootten

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Pak een zip-archief opnieuw dat deze problemen vertoont.

Categorie

Core .NET-bibliotheken

Betrokken API's

FieldInfo.SetValue genereert uitzondering voor statische, alleen-init-velden

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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.

Categorie

Core .NET-bibliotheken

Betrokken API's

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.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

3,0

Reden voor wijziging

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

Categorie

Core .NET-bibliotheken

Betrokken API's

Elke extensiemethode die een IEnumerable<T> accepteert, wordt beïnvloed. Voorbeeld:

Cryptografie

De syntaxis 'BEGIN TRUSTED CERTIFICATE' wordt niet meer ondersteund voor basiscertificaten in Linux

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.

Wijzigingsbeschrijving

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

Versie geïntroduceerd

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

Categorie

Cryptografie

Betrokken API's

EnvelopdCms is standaard ingesteld op AES-256-versleuteling

Het standaard symmetrische versleutelingsalgoritmen dat door EnvelopedCms wordt gebruikt, zijn gewijzigd van TripleDES in AES-256.

Wijzigingsbeschrijving

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

Versie geïntroduceerd

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

Categorie

Cryptografie

Betrokken API's

Minimale grootte voor het genereren van RSAOpenSsl-sleutels is toegenomen

De minimale grootte voor het genereren van nieuwe RSA-sleutels in Linux is verhoogd van 384-bits naar 512-bits.

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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.

Categorie

Cryptografie

Betrokken API's

.NET Core 3.0 geeft de voorkeur aan OpenSSL 1.1.x naar OpenSSL 1.0.x

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

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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.

Categorie

Cryptografie

Betrokken API's

CryptoStream.Dispose transformeert het laatste blok alleen bij het schrijven

De CryptoStream.Dispose methode, die wordt gebruikt om bewerkingen te voltooien CryptoStream , probeert het laatste blok niet meer te transformeren bij het lezen.

Wijzigingsbeschrijving

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.

Reden voor wijziging

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.

Versie geïntroduceerd

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.

Categorie

Cryptografie

Betrokken API's

Entity Framework Core

Wijzigingen die fouten veroorzaken in Entity Framework

Globalisatie

De landinstelling 'C' wordt toegewezen aan de landinstelling voor invariant

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

Wijzigingsbeschrijving

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.

Versie geïntroduceerd

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

Categorie

Globalisatie

Betrokken API's

Alle sorterings- en cultuur-API's worden beïnvloed door deze wijziging.

MSBuild

Naam van resourcemanifestbestand wijzigen

Vanaf .NET Core 3.0 genereert MSBuild in het standaardscenario een andere manifestbestandsnaam voor resourcebestanden.

Versie geïntroduceerd

3,0

Wijzigingsbeschrijving

Vóór .NET Core 3.0, als er geen LogicalName, ManifestResourceNameof DependentUpon metagegevens zijn opgegeven voor een EmbeddedResource item in het projectbestand, heeft MSBuild een manifestbestandsnaam in het patroon <RootNamespace>.<ResourceFilePathFromProjectRoot>.resourcesgegenereerd. 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 , ManifestResourceNameof DependentUpon metagegevens hebt LogicalNameopgegeven 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 trueop , 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>

Categorie

MSBuild

Betrokken API's

N.v.t.

Netwerken

Standaardwaarde van HttpRequestMessage.Version is gewijzigd in 1.1

De standaardwaarde van de System.Net.Http.HttpRequestMessage.Version eigenschap is gewijzigd van 2.0 in 1.1.

Versie geïntroduceerd

3,0

Wijzigingsbeschrijving

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.

Categorie

Netwerken

Betrokken API's

Zie ook