Partager via

Changements cassants ASP.NET Core pour les versions 3.0 et 3.1

ASP.NET Core fournit les fonctionnalités de développement d’applications web utilisées par .NET Core.

Sélectionnez l’un des liens suivants pour voir les changements cassants dans une version spécifique :

Les changements cassants suivants dans ASP.NET Core 3.0 et 3.1 sont documentés sur cette page :

ASP.NET Core 3.1

HTTP : impact des changements apportés à la propriété SameSite du navigateur sur l’authentification

Certains navigateurs, tels que Chrome et Firefox, ont apporté des changements cassants à leurs implémentations de SameSite dans le cadre de la gestion des cookies. Les changements ont un impact sur les scénarios d’authentification à distance, tels que OpenID Connect et WS-Federation, qui doivent les refuser en envoyant SameSite=None. Toutefois, SameSite=None s’arrête sur iOS 12 et certaines versions antérieures d’autres navigateurs. L’application doit détecter ces versions et omettre SameSite.

Pour plus d’informations sur ce problème, consultez dotnet/aspnetcore#14996.

Version introduite

3.1 Préversion 1

Ancien comportement

SameSite est une extension du projet de norme 2016 pour les cookies HTTP. Cela permet d’atténuer la falsification de requête intersites (CSRF, Cross Site Request Forgery). À l’origine, il s’agissait d’une fonction à laquelle les serveurs devaient adhérer en ajoutant les nouveaux paramètres. SameSite est pris en charge à partir d’ASP.NET Core 2.0.

Nouveau comportement

Google a proposé une nouveau projet de norme qui n’est pas rétrocompatible. La norme modifie le mode par défaut sur Lax et ajoute une nouvelle entrée None pour refuser. Lax suffit pour la plupart des cookies d’application. Toutefois, il arrête les scénarios intersites comme OpenID Connect et la connexion WS-Federation. La plupart des connexions OAuth ne sont pas affectées en raison de différences de traitement des flux de requêtes. Le nouveau paramètre None provoque des problèmes de compatibilité avec les clients qui ont implémenté le projet de norme précédent (par exemple, iOS 12). Les changements seront inclus dans Chrome 80. Consultez les mises à jour de SameSite dans le cadre de la chronologie des lancements de produits Chrome.

ASP.NET Core 3.1 a été mis à jour pour implémenter le nouveau comportement SameSite. La mise à jour redéfinit le comportement de SameSiteMode.None afin d’émettre SameSite=None et ajoute une nouvelle valeur, SameSiteMode.Unspecified, afin d’omettre l’attribut SameSite. Toutes les API de cookie sont désormais définies par défaut sur Unspecified bien que certains composants qui utilisent des cookies définissent des valeurs plus spécifiques à leurs scénarios tels que la corrélation OpenID Connect et les cookies nonce.

Pour obtenir d’autres changements récents dans cette zone, consultez HTTP : Certaines valeurs par défaut du cookie SameSite ont été remplacées par Aucune. Dans ASP.NET Core 3.0, la plupart des valeurs par défaut sont passées de SameSiteMode.Lax à SameSiteMode.None (mais elles utilisent toujours la norme précédente).

Raison du changement

Le navigateur et la spécification changent comme indiqué dans le texte précédent.

Les applications qui interagissent avec des sites distants, par le biais d’une connexion tierce, par exemple, doivent :

Pour obtenir des instructions de test et de détection de navigateur, consultez la section suivante.

Déterminer si vous êtes affecté

Tester votre application web à l’aide d’une version cliente qui peut opter pour le nouveau comportement. Chrome, Firefox et Microsoft Edge Chromium ont tous de nouveaux indicateurs de fonctionnalité d’acceptation qui peuvent être utilisés pour les tests. Vérifiez que votre application est compatible avec les versions antérieures du client après avoir appliqué les patches, en particulier Safari. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.

Chrome

Chrome 78 et les versions ultérieures produisent des résultats de test trompeurs. Ces versions ont mis en place une mesure d’atténuation temporaire et autorisent les cookies de moins de deux minutes. Avec les indicateurs de test appropriés activés, Chrome 76 et 77 donnent des résultats plus précis. Pour tester le nouveau comportement, activez chrome://flags/#same-site-by-default-cookies sur activé. Chrome 75 et versions antérieures échouent avec le nouveau paramètre None. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.

Google ne met pas à disposition les anciennes versions de Chrome. Toutefois, vous pouvez télécharger des versions antérieures de Chromium, ce qui suffit pour les tests. Suivez les instructions sur Télécharger Chromium.

Safari

Safari 12 a strictement implémenté le brouillon précédent et échoue s’il rencontre la nouvelle valeur None dans les cookies. Cela doit être évité via le code de détection du navigateur indiqué dans Prendre en charge les navigateurs plus anciens. Veillez à tester Safari 12 et 13, ainsi que les connexions de type système d’exploitation basées sur WebKit à l’aide de Microsoft Authentication Library (MSAL), d’Active Directory Authentication Library (ADAL) ou de toute autre bibliothèque que vous utilisez. Le problème dépend de la version sous-jacente du système d’exploitation. OSX Mojave 10.14 et iOS 12 sont connus pour avoir des problèmes de compatibilité avec le nouveau comportement. La mise à niveau vers OSX Catalina 10.15 ou iOS 13 résout le problème. Safari n’a actuellement pas d’indicateur d’adhésion pour tester le nouveau comportement de spécification.

Firefox

La prise en charge de Firefox pour la nouvelle norme peut être testée sur la version 68 et ultérieure en acceptant sur la page about:config avec l’indicateur de fonctionnalité network.cookie.sameSite.laxByDefault. Aucun problème de compatibilité n’a été signalé sur les versions antérieures de Firefox.

Microsoft Edge

Bien que Microsoft Edge prenne en charge l’ancienne norme SameSite, à partir de la version 44, il n’a pas rencontré de problèmes de compatibilité avec la nouvelle norme.

Microsoft Edge Chromium

L’indicateur de fonctionnalité est edge://flags/#same-site-by-default-cookies. Aucun problème de compatibilité n’a été observé lors du test avec Microsoft Edge Chromium 78.

Électron

Les versions d’Electron incluent des versions antérieures de Chromium. Par exemple, la version d’Electron utilisée par Microsoft Teams est Chromium 66, qui présente l’ancien comportement. Effectuez vos propres tests de compatibilité avec la version d’Electron utilisée par votre produit. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.

Prendre en charge des navigateurs plus anciens

La norme SameSite 2016 exigeait que les valeurs inconnues soient traitées comme des valeurs SameSite=Strict. Par conséquent, tous les navigateurs plus anciens qui prennent en charge la norme d’origine peuvent s’arrêter lorsqu’ils rencontrent une propriété SameSite ayant la valeur None. Les applications web doivent implémenter la détection de navigateur si elles doivent prendre en charge ces anciens navigateurs. ASP.NET Core n’implémente pas la détection de navigateur pour vous, car les valeurs d’en-tête de demande User-Agent sont hautement instables et modifiées chaque semaine. Au lieu de cela, un point d’extension dans la stratégie de cookie vous permet d’ajouter une logique propre à User-Agent.

Dans Startup.cs, ajoutez le code suivant :

private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{
    if (options.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
        // TODO: Use your User Agent library of choice here.
        if (/* UserAgent doesn't support new behavior */)
        {
            options.SameSite = SameSiteMode.Unspecified;
        }
    }
}

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
        options.OnAppendCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
        options.OnDeleteCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
    });
}

public void Configure(IApplicationBuilder app)
{
    // Before UseAuthentication or anything else that writes cookies.
    app.UseCookiePolicy();

    app.UseAuthentication();
    // code omitted for brevity
}
Commutateurs de refus

Le commutateur de compatibilité Microsoft.AspNetCore.SuppressSameSiteNone vous permet de désactiver temporairement le nouveau comportement de cookie ASP.NET Core. Ajoutez le code JSON suivant à un fichier runtimeconfig.template.json dans votre projet :

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Autres versions

Les patches SameSite connexes sont à venir pour :

  • ASP.NET Core 2.1, 2.2 et 3.0
  • Microsoft.Owin 4.1
  • System.Web (pour .NET Framework 4.7.2 et versions ultérieures)

Catégorie

ASP.NET

API affectées

ASP.NET Core 3.0

Les API Antiforgery, CORS, Diagnostics, MVC et Routage obsolètes ont été supprimées

Les membres et les commutateurs de compatibilité obsolètes dans ASP.NET Core 2.2 ont été supprimés.

Version introduite

3.0

Raison du changement

Amélioration de la surface de l’API au fil du temps.

Tout en ciblant .NET Core 2.2, suivez les instructions des messages de build obsolètes pour adopter de nouvelles API à la place.

Catégorie

ASP.NET Noyau

API affectées

Les types et membres suivants ont été marqués comme obsolètes pour ASP.NET Core 2.1 et 2.2 :

Types

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

Propriétés

  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
  • Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
  • Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
  • Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

Méthodes

Authentification : Google+ déconseillé et remplacé

Google a commencé à supprimer les connexions Google+ pour les applications dès le 28 janvier 2019.

Description de la modification

ASP.NET 4.x et ASP.NET Core ont utilisé les API de connexion Google+ pour authentifier les utilisateurs de compte Google dans les applications web. Les packages NuGet concernés sont Microsoft.AspNetCore.Authentication.Google pour ASP.NET Core et Microsoft.Owin.Security.Google pour Microsoft.Owin avec ASP.NET Web Forms et MVC.

Les API de remplacement de Google utilisent une source de données et un format différents. Les atténuations et les solutions fournies ci-dessous expliquent les changements structurels. Les applications doivent vérifier que les données elles-mêmes répondent toujours à leurs besoins. Par exemple, les noms, les adresses e-mail, les liens de profil et les photos de profil peuvent fournir des valeurs subtilement différentes de celles d’avant.

Version introduite

Toutes les versions. Ce changement est externe à ASP.NET Core.

Owin avec ASP.NET Web Forms et MVC

Pour Microsoft.Owin la version 3.1.0 et ultérieure, une atténuation temporaire est décrite dans les impacts de l’arrêt Google+. Les applications doivent terminer le test d’atténuation pour vérifier les changements apportés au format de données. Il est prévu de mettre en production la version Microsoft.Owin 4.0.1 avec un correctif. Les applications utilisant une version antérieure doivent être mises à jour vers la version 4.0.1.

ASP.NET Core 1.x

L’atténuation dans Owin avec ASP.NET Web Forms et MVC peut être adaptée à ASP.NET Core 1.x. Les patches de packages NuGet ne sont pas prévus, car la version 1.x a atteint l’état de fin de vie.

ASP.NET Core 2.x

Pour Microsoft.AspNetCore.Authentication.Google version 2.x, remplacez votre appel existant à AddGoogle dans Startup.ConfigureServices par le code suivant :

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

Les patches 2.1 et 2.2 de février ont incorporé la reconfiguration précédente comme nouvelle valeur par défaut. Aucun patch n’est prévu pour ASP.NET Core 2.0 depuis sa fin de vie.

ASP.NET Core 3.0

L’atténuation donnée pour ASP.NET Core 2.x peut également être utilisée pour ASP.NET Core 3.0. Dans les prochaines préversions 3.0, le package Microsoft.AspNetCore.Authentication.Google peut être supprimé. À la place, les utilisateurs sont dirigés vers Microsoft.AspNetCore.Authentication.OpenIdConnect. Le code suivant montre comment remplacer AddGoogle par AddOpenIdConnect dans Startup.ConfigureServices. Ce remplacement peut être utilisé avec ASP.NET Core 2.0 et versions ultérieures et peut être adapté pour ASP.NET Core 1.x si nécessaire.

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

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Authentication.Google

Authentication : propriété HttpContext.Authentication supprimée

La propriété Authentication déconseillée sur HttpContext a été supprimée.

Description de la modification

Dans le cadre de dotnet/aspnetcore#6504, la propriété Authentication déconseillée sur HttpContext a été supprimée. La propriété Authentication est déconseillée depuis 2.0. Un guide de migration a été publié pour migrer le code à l’aide de cette propriété déconseillée vers les nouvelles API de remplacement. Les classes/API inutilisées restantes liées à l’ancienne pile d’authentification ASP.NET Core 1.x ont été supprimées dans la validation dotnet/aspnetcore@d7a7c65.

Pour plus d’informations, consultez dotnet/aspnetcore#6533.

Version introduite

3.0

Raison du changement

Les API ASP.NET Core 1.0 ont été remplacées par des méthodes d’extension dans Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Consultez le guide de migration.

Catégorie

ASP.NET Noyau

API affectées

Authentification : types Newtonsoft.Json remplacés

Dans ASP.NET Core 3.0, les types Newtonsoft.Json utilisés dans les API d’authentification ont été remplacés par des types System.Text.Json. Sauf dans les cas suivants, l’utilisation de base des packages d’authentification n’est pas affectée :

  • Classes dérivées des fournisseurs OAuth, telles que celles d’aspnet-contrib.
  • Implémentations avancées de manipulation des revendications.

Pour plus d’informations, consultez dotnet/aspnetcore#7105. Pour plus d’informations, consultez dotnet/aspnetcore#7289.

Version introduite

3.0

Pour les implémentations OAuth dérivées, le changement le plus courant consiste à remplacer JObject.Parse par JsonDocument.Parse dans la substitution CreateTicketAsync, comme indiqué dans dotnet/aspnetcore#7105. L'objet JsonDocument implémente l'objet IDisposable.

La liste suivante présente les changements connus :

Catégorie

ASP.NET Noyau

API affectées

Authentification : la signature OAuthHandler ExchangeCodeAsync a été modifiée

Dans ASP.NET Core 3.0, la signature de OAuthHandler.ExchangeCodeAsync est passé de :

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

Par :

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

Version introduite

3.0

Ancien comportement

Les chaînes code et redirectUri ont été passées en tant qu’arguments distincts.

Nouveau comportement

Code et RedirectUri sont des propriétés sur OAuthCodeExchangeContext qui peuvent être définies via le constructeur OAuthCodeExchangeContext. Le nouveau type OAuthCodeExchangeContext est le seul argument passé à OAuthHandler.ExchangeCodeAsync.

Raison du changement

Ce changement permet de fournir des paramètres supplémentaires sans rupture. Il n’est pas nécessaire de créer de nouvelles surcharges ExchangeCodeAsync.

Construisez un OAuthCodeExchangeContext avec les valeurs code et redirectUri appropriées. Une instance AuthenticationProperties doit être fournie. Cette instance OAuthCodeExchangeContext unique peut être passée à OAuthHandler.ExchangeCodeAsync au lieu de plusieurs arguments.

Catégorie

ASP.NET Noyau

API affectées

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorisation : la surcharge AddAuthorization a été déplacée vers un autre assembly

Les méthodes principales AddAuthorization utilisées pour résider dans Microsoft.AspNetCore.Authorization ont été renommées en AddAuthorizationCore. Les anciennes méthodes AddAuthorization existent toujours, mais se trouvent dans l’assembly Microsoft.AspNetCore.Authorization.Policy à la place. Les applications utilisant les deux méthodes ne doivent voir aucun impact. Notez que Microsoft.AspNetCore.Authorization.Policy est désormais fourni dans l’infrastructure partagée plutôt qu’un package autonome, comme indiqué dans Infrastructure partagée : Assemblys supprimés de Microsoft.AspNetCore.App.

Version introduite

3.0

Ancien comportement

Les méthodes AddAuthorization existaient dans Microsoft.AspNetCore.Authorization.

Nouveau comportement

Les méthodes AddAuthorization existent dans Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore est le nouveau nom des anciennes méthodes.

Raison du changement

AddAuthorization est un meilleur nom de méthode pour l’ajout de tous les services communs nécessaires à l’autorisation.

Ajoutez une référence à Microsoft.AspNetCore.Authorization.Policy ou utilisez AddAuthorizationCore à la place.

Catégorie

ASP.NET Noyau

API affectées

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

Autorisation : IAllowAnonymous supprimé de AuthorizationFilterContext.Filters

Depuis ASP.NET Core 3.0, MVC n’ajoute pas les attributs AllowAnonymousFilters pour pour [AllowAnonymous] qui ont été découverts sur les contrôleurs et les méthodes d’action. Ce changement est traité localement pour les dérivés de AuthorizeAttribute, mais il s’agit d’un changement cassant pour les implémentations IAsyncAuthorizationFilter et IAuthorizationFilter. Ces implémentations inclues dans un wrapper dans un attribut [TypeFilter] sont un moyen populaire et pris en charge d’obtenir une autorisation fortement typée basée sur les attributs lorsque la configuration et l’injection de dépendances sont requises.

Version introduite

3.0

Ancien comportement

IAllowAnonymous est apparu dans la collection AuthorizationFilterContext.Filters. Le test de la présence de l’interface était une approche valide pour remplacer ou désactiver le filtre sur les méthodes de contrôleur individuelles.

Nouveau comportement

IAllowAnonymous n’apparaît plus dans la collection AuthorizationFilterContext.Filters. Les implémentations IAsyncAuthorizationFilter qui dépendent de l’ancien comportement provoquent généralement des réponses HTTP 401 non autorisées ou HTTP 403 Interdites intermittentes.

Raison du changement

Une nouvelle stratégie de routage des points de terminaison a été introduite dans ASP.NET Core 3.0.

Recherchez dans les métadonnées du point de terminaison pour IAllowAnonymous. Par exemple :

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

Un exemple de cette technique est présenté dans cette méthode HasAllowAnonymous.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Autorisation : les implémentations IAuthorizationPolicyProvider nécessitent une nouvelle méthode

Dans ASP.NET Core 3.0, une nouvelle méthode GetFallbackPolicyAsync a été ajoutée à IAuthorizationPolicyProvider. Cette stratégie de secours est utilisée par l’intergiciel d’autorisation lorsqu’aucune stratégie n’est spécifiée.

Pour plus d’informations, consultez dotnet/aspnetcore#9759.

Version introduite

3.0

Ancien comportement

Les implémentations de IAuthorizationPolicyProvider n’ont pas besoin d’une méthode GetFallbackPolicyAsync.

Nouveau comportement

Les implémentations de IAuthorizationPolicyProvider ont besoin d’une méthode GetFallbackPolicyAsync.

Raison du changement

Une nouvelle méthode était nécessaire pour être utilisée par le nouveau AuthorizationMiddleware lorsqu’aucune stratégie n’est spécifiée.

Ajoutez la méthode GetFallbackPolicyAsync à vos implémentations de IAuthorizationPolicyProvider.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Mise en cache : propriété CompactOnMemoryPressure supprimée

La version ASP.NET Core 3.0 a supprimé les API MemoryCacheOptions obsolètes.

Description de la modification

Ce changement est un suivi de aspnet/Caching#221. Pour en savoir plus, consultez dotnet/extensions#1062.

Version introduite

3.0

Ancien comportement

La propriété MemoryCacheOptions.CompactOnMemoryPressure était disponible.

Nouveau comportement

La propriété MemoryCacheOptions.CompactOnMemoryPressure a été supprimée.

Raison du changement

Le compactage automatique du cache a provoqué des problèmes. Pour éviter tout comportement inattendu, le cache ne doit être compacté que si nécessaire.

Pour compacter le cache, effectuez un downcast vers MemoryCache et appelez Compact si nécessaire.

Catégorie

ASP.NET Noyau

API affectées

MemoryCacheOptions.CompactOnMemoryPressure

Mise en cache : Microsoft.Extensions.Caching.SqlServer utilise le nouveau package SqlClient

Le package Microsoft.Extensions.Caching.SqlServer utilisera le nouveau package Microsoft.Data.SqlClient à la place du package System.Data.SqlClient. Ce changement peut entraîner de légers changements cassants du comportement. Pour plus d’informations, consultez Présentation du nouveau Microsoft.Data.SqlClient.

Version introduite

3.0

Ancien comportement

Le package Microsoft.Extensions.Caching.SqlServer a utilisé le package System.Data.SqlClient.

Nouveau comportement

Microsoft.Extensions.Caching.SqlServer utilise maintenant le package Microsoft.Data.SqlClient.

Raison du changement

Microsoft.Data.SqlClient est un nouveau package qui est généré à partir de System.Data.SqlClient. C’est là que tout le travail des nouvelles fonctionnalités sera effectué à partir de maintenant.

Les clients ne doivent pas avoir à s’inquiéter de ce changement cassant, sauf s’ils utilisent des types retournés par le package Microsoft.Extensions.Caching.SqlServer et les castent en types System.Data.SqlClient. Par exemple, si quelqu’un castait un DbConnection vers l’ancien type SqlConnection, il doit remplacer le cast par le nouveau type Microsoft.Data.SqlClient.SqlConnection.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Mise en cache : les types « pubternal » ResponseCaching sont passés en interne

Dans ASP.NET Core 3.0, les types « pubternal » dans ResponseCaching ont été modifiés en internal.

En outre, les implémentations par défaut de IResponseCachingPolicyProvider et IResponseCachingKeyProvider ne sont plus ajoutées aux services dans le cadre de la méthode AddResponseCaching.

Description de la modification

Dans ASP.NET Core, les types « pubternal » sont déclarés comme public mais résident dans un espace de noms avec le suffixe .Internal. Bien que ces types soient publics, ils n’ont aucune stratégie de support et sont sujets à des changements cassants. Malheureusement, l’utilisation accidentelle de ces types a été fréquente, ce qui a entraîné des changements cassants dans ces projets en limitant la capacité à gérer l’infrastructure.

Version introduite

3.0

Ancien comportement

Ces types étaient visibles publiquement, mais non pris en charge.

Nouveau comportement

Ces types sont désormais internal.

Raison du changement

L’étendue internal reflète mieux la stratégie non prise en charge.

Copiez les types utilisés par votre application ou bibliothèque.

Catégorie

ASP.NET Noyau

API affectées

Protection des données : DataProtection.Blobs utilise de nouvelles API de stockage Azure

Azure.Extensions.AspNetCore.DataProtection.Blobs dépend des bibliothèques de stockage Azure. Ces bibliothèques ont renommé leurs assemblys, packages et espaces de noms. À compter de ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs utilise les nouveaux packages et API avec le préfixe Azure.Storage..

Pour toute question sur les API de stockage Azure, utilisez https://github.com/Azure/azure-storage-net. Pour plus d’informations sur ce problème, consultez dotnet/aspnetcore#19570.

Version introduite

3.0

Ancien comportement

Le package a référencé le package NuGet WindowsAzure.Storage. Le package référence le package NuGet Microsoft.Azure.Storage.Blob.

Nouveau comportement

Le package référence le package NuGet Azure.Storage.Blob.

Raison du changement

Ce changement permet à Azure.Extensions.AspNetCore.DataProtection.Blobs de migrer vers les packages de stockage Azure recommandés.

Si vous devez toujours utiliser les plus anciennes API de stockage Azure avec ASP.NET Core 3.0, ajoutez une dépendance directe au package WindowsAzure.Storage ou Microsoft.Azure.Storage. Ce package peut être installé en même temps que les nouvelles API Azure.Storage.

Dans de nombreux cas, la mise à niveau implique uniquement le changement des instructions using pour utiliser les nouveaux espaces de noms :

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

Catégorie

ASP.NET Noyau

API affectées

Aucun

Hébergement : AspNetCoreModule V1 supprimé de l’offre groupée d’hébergement Windows

À compter de ASP.NET Core 3.0, l’offre groupée d’hébergement Windows ne contiendra pas AspNetCoreModule (ANCM) V1.

ANCM V2 est rétrocompatible avec ANCM OutOfProcess et est recommandé pour une utilisation avec des applications ASP.NET Core 3.0.

Pour plus d’informations, consultez dotnet/aspnetcore#7095.

Version introduite

3.0

Ancien comportement

ANCM V1 est inclus dans l’offre groupée d’hébergement Windows.

Nouveau comportement

ANCM V1 n’est pas inclus dans l’offre groupée d’hébergement Windows.

Raison du changement

ANCM V2 est rétrocompatible avec ANCM OutOfProcess et est recommandé pour une utilisation avec des applications ASP.NET Core 3.0.

Utilisez ANCM V2 avec des applications ASP.NET Core 3.0.

Si ANCM V1 est requis, il peut être installé à l’aide de l’offre groupée d’hébergement Windows ASP.NET Core 2.1 ou 2.2.

Ce changement arrête les applications ASP.NET Core 3.0 qui :

  • ont explicitement opté pour l’utilisation d’ANCM V1 avec <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> ;
  • ont un fichier web.config personnalisé avec <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Hébergement : l’hôte générique restreint l’injection de constructeur de démarrage

Les seuls types pris en charge par l’hôte générique pour l’injection de constructeur de classe Startup sont IHostEnvironment, IWebHostEnvironment et IConfiguration. Les applications utilisant WebHost ne sont pas affectées.

Description de la modification

Avant ASP.NET Core 3.0, l’injection de constructeur pouvait être utilisée pour des types arbitraires dans le constructeur de la classe Startup. Dans ASP.NET Core 3.0, la pile web a été placée sur une nouvelle plateforme sur la bibliothèque hôte générique. Vous pouvez voir le changement dans le fichier Program.cs des modèles :

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 utilise un conteneur d’injection de dépendances (ID) pour générer l’application. WebHost utilise deux conteneurs : un pour l’hôte et un autre pour l’application. Par conséquent, le constructeur Startup ne prend plus en charge l’injection de service personnalisé. Seuls IHostEnvironment, IWebHostEnvironment et IConfiguration peuvent être injectés. Ce changement permet d’éviter les problèmes de l’ID, tels que la création d’un doublon d’un service singleton.

Version introduite

3.0

Raison du changement

Ce changement est une conséquence du placement sur une nouvelle plateforme de la pile web sur la bibliothèque hôte générique.

Injectez des services dans la signature de la méthode Startup.Configure. Par exemple :

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

Catégorie

ASP.NET Noyau

API affectées

Aucun

Hébergement : redirection HTTPS activée pour les applications hors processus IIS

La version 13.0.19218.0 du module ASP.NET Core (ANCM) pour l’hébergement via IIS hors processus active une fonctionnalité de redirection HTTPS existante pour les applications ASP.NET Core 3.0 et 2.2.

Pour plus d’informations, consultez dotnet/aspnetcore#15243.

Version introduite

3.0

Ancien comportement

Le modèle de projet ASP.NET Core 2.1 a d’abord introduit le support des méthodes d’intergiciel HTTPS comme UseHttpsRedirection et UseHsts. L’activation de la redirection HTTPS nécessitait l’ajout d’une configuration, car les applications en cours de développement n’utilisent pas le port par défaut 443. La Sécurité du transport strict HTTP (HSTS) est active uniquement si la requête utilise déjà HTTPS. Localhost est ignoré par défaut.

Nouveau comportement

Dans ASP.NET Core 3.0, le scénario HTTPS IIS a été amélioré. Avec l’amélioration, une application peut découvrir les ports HTTPS du serveur et faire fonctionner UseHttpsRedirection par défaut. Le composant in-process a effectué la découverte de ports avec la fonctionnalité IServerAddresses, ce qui affecte uniquement les applications ASP.NET Core 3.0, car la bibliothèque in-process est versionnée avec l’infrastructure. Le composant hors processus a été modifié pour ajouter automatiquement la variable d’environnement ASPNETCORE_HTTPS_PORT. Ce changement a affecté les applications ASP.NET Core 2.2 et 3.0, car le composant hors processus est partagé globalement. Les applications ASP.NET Core 2.1 ne sont pas affectées, car elles utilisent une version antérieure à ANCM par défaut.

Le comportement précédent a été modifié dans ASP.NET Core 3.0.1 et 3.1.0 Préversion 3 pour inverser les changements de comportement dans ASP.NET Core 2.x. Ces changements affectent uniquement les applications hors processus IIS.

Comme indiqué ci-dessus, l’installation de ASP.NET Core 3.0.0 a eu pour effet secondaire d’activer également l’intergiciel UseHttpsRedirection dans les applications ASP.NET Core 2.x. Un changement a été apporté à ANCM dans ASP.NET Core 3.0.1 et 3.1.0 Préversion 3, de telle sorte que leur installation n’ait plus cet effet sur les applications ASP.NET Core 2.x. La variable d’environnement ASPNETCORE_HTTPS_PORT qu’ANCM a renseignée dans ASP.NET Core 3.0.0 a été modifiée en ASPNETCORE_ANCM_HTTPS_PORT dans ASP.NET Core 3.0.1 et 3.1.0 Préversion 3. UseHttpsRedirection a également été mis à jour dans ces versions pour comprendre les variables nouvelles et anciennes. ASP.NET Core 2.x ne sera pas mis à jour. Par conséquent, cela rétablit le comportement précédent de la désactivation par défaut.

Raison du changement

Amélioration de la fonctionnalité ASP.NET Core 3.0.

Aucune action n’est requise si vous souhaitez que tous les clients utilisent HTTPS. Pour autoriser certains clients à utiliser HTTP, effectuez l’une des étapes suivantes :

  • Supprimez les appels vers UseHttpsRedirection et UseHsts depuis la méthode Startup.Configure de votre projet, puis redéployez l’application.

  • Dans votre fichier web.config, définissez la variable d’environnement ASPNETCORE_HTTPS_PORT sur une chaîne vide. Ce changement peut se produire directement sur le serveur sans redéployer l’application. Par exemple :

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

UseHttpsRedirectionpeut toujours être :

  • activé manuellement dans ASP.NET Core 2.x en définissant la variable d’environnement ASPNETCORE_HTTPS_PORT sur le numéro de port approprié (443 dans la plupart des scénarios de production) ;
  • désactivé dans ASP.NET Core 3.x en définissant ASPNETCORE_ANCM_HTTPS_PORT avec une valeur de chaîne vide. Cette valeur est définie de la même façon que dans l’exemple précédent ASPNETCORE_HTTPS_PORT.

Les machines exécutant des applications ASP.NET Core 3.0.0 doivent installer le runtime ASP.NET Core 3.0.1 avant d’installer l’ANCM ASP.NET Core 3.1.0 Préversion 3. Cela garantit que UseHttpsRedirection continue de fonctionner comme prévu pour les applications ASP.NET Core 3.0.

Dans Azure App Service, ANCM se déploie selon une planification distincte du runtime en raison de sa nature globale. ANCM a été déployé sur Azure avec ces changements après le déploiement de ASP.NET Core 3.0.1 et 3.1.0.

Catégorie

ASP.NET Noyau

API affectées

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hébergement : types IHostingEnvironment et IApplicationLifetime marqués comme obsolètes et remplacés

De nouveaux types ont été introduits pour remplacer les typesIHostingEnvironment et IApplicationLifetime existants.

Version introduite

3.0

Ancien comportement

Il y avait deux types IHostingEnvironment et IApplicationLifetime différents de Microsoft.Extensions.Hosting et Microsoft.AspNetCore.Hosting.

Nouveau comportement

Les anciens types ont été marqués comme obsolètes et remplacés par de nouveaux types.

Raison du changement

Lorsque Microsoft.Extensions.Hosting a été introduit dans ASP.NET Core 2.1, certains types comme IHostingEnvironment et IApplicationLifetime ont été copiés à partir de Microsoft.AspNetCore.Hosting. Certains changements de ASP.NET Core 3.0 entraînent l’inclusion des espaces de noms Microsoft.Extensions.Hosting et Microsoft.AspNetCore.Hosting par les applications. Toute utilisation de ces types en double provoque une erreur du compilateur « référence ambiguë » lorsque les deux espaces de noms sont référencés.

Remplacement de toutes les utilisations des anciens types par les types nouvellement introduits comme ci-dessous :

Types obsolètes (avertissement) :

Nouveaux types :

Les nouvelles méthodes d’extension IHostEnvironmentIsDevelopment et IsProduction se trouvent dans l’espace de noms Microsoft.Extensions.Hosting. Cet espace de noms doit peut-être être ajouté à votre projet.

Catégorie

ASP.NET Noyau

API affectées

Hébergement : ObjectPoolProvider supprimé des dépendances WebHostBuilder

Afin de rendre ASP.NET Core plus payant, le ObjectPoolProvider a été supprimé de l’ensemble principal de dépendances. Des composants spécifiques qui s’appuient sur ObjectPoolProvider l’ajoutent désormais eux-mêmes.

Pour plus d’informations, consultez dotnet/aspnetcore#5944.

Version introduite

3.0

Ancien comportement

WebHostBuilder fournit ObjectPoolProvider par défaut dans le conteneur de l’ID.

Nouveau comportement

WebHostBuilder ne fournit plus ObjectPoolProvider par défaut dans le conteneur de l’ID.

Raison du changement

Ce changement a été apporté pour rendre ASP.NET Core plus payant.

Si votre composant nécessite ObjectPoolProvider, il doit être ajouté à vos dépendances via le IServiceCollection.

Catégorie

ASP.NET Noyau

API affectées

Aucun

HTTP : l’extensibilité DéfautHttpContext a été supprimée

Dans le cadre des améliorations du niveau de performance de ASP.NET Core 3.0, l’extensibilité de DefaultHttpContext a été supprimée. La classe est maintenant sealed. Pour plus d’informations, consultez dotnet/aspnetcore#6504.

Si vos tests unitaires utilisent Mock<DefaultHttpContext>, utilisez Mock<HttpContext> ou new DefaultHttpContext() à la place.

Pour plus d’informations, consultez dotnet/aspnetcore#6534.

Version introduite

3.0

Ancien comportement

Les classes peuvent dériver de DefaultHttpContext.

Nouveau comportement

Les classes ne peuvent pas dériver de DefaultHttpContext.

Raison du changement

L’extensibilité a été initialement fournie pour permettre le regroupement du HttpContext, mais elle a introduit une complexité inutile et entravé d’autres optimisations.

Si vous utilisez Mock<DefaultHttpContext> dans vos tests unitaires, commencez à utiliser Mock<HttpContext> à la place.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP : les constantes HeaderNames sont passées à des champs statiques en lecture seule

À compter de ASP.NET Core 3.0 Préversion 5, les champs dans Microsoft.Net.Http.Headers.HeaderNames sont passés de const à static readonly.

Pour plus d’informations, consultez dotnet/aspnetcore#9514.

Version introduite

3.0

Ancien comportement

Ces champs étaient const auparavant.

Nouveau comportement

Ces champs sont désormais static readonly.

Raison du changement

Changements :

  • Empêche l’incorporation des valeurs au-delà des limites de l’assembly, ce qui permet des corrections de valeur en fonction des besoins.
  • Permet des vérifications d’égalité des références plus rapides.

Recompilez sur 3.0. Le code source utilisant ces champs des manières suivantes ne peut plus le faire :

  • En tant qu’argument d’attribut
  • En tant que case dans une instruction switch
  • Lors de la définition d’un autre const

Pour contourner le changement cassant, basculez vers l’utilisation de constantes de noms d’en-tête autodéfinis ou de littéraux de chaîne.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.Net.Http.Headers.HeaderNames

HTTP : changements de l’infrastructure du corps de la réponse

L’infrastructure qui supporte un corps de réponse HTTP a changé. Si vous utilisez HttpResponse directement, vous n’avez pas besoin d’apporter de changements de code. Lisez plus en détail si vous incluez dans un wrapper ou remplacez HttpResponse.Body ou si vous accédez à HttpContext.Features.

Version introduite

3.0

Ancien comportement

Trois API étaient associées au corps de la réponse HTTP :

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

Nouveau comportement

Si vous remplacez HttpResponse.Body, il remplace IHttpResponseBodyFeature en entier par un wrapper autour de votre flux donné à l’aide de StreamResponseBodyFeature pour fournir des implémentations par défaut pour toutes les API attendues. La restauration du flux d’origine rétablit ce changement.

Raison du changement

La motivation est de combiner les API du corps de la réponse dans une nouvelle interface de fonctionnalité unique.

Utilisez IHttpResponseBodyFeature là où vous utilisiez IHttpResponseFeature.Body, IHttpSendFileFeature ou IHttpBufferingFeature précédemment.

Catégorie

ASP.NET Noyau

API affectées

SameSite est une option pour les cookies permettant d’atténuer certaines attaques de falsification de requête intersites (CSRF, Cross Site Request Forgery). Lors de l’introduction initiale de cette option, des valeurs par défaut incohérentes étaient utilisées dans différentes API ASP.NET Core. L’incohérence a conduit à des résultats confus. À partir de ASP.NET Core 3.0, ces valeurs par défaut sont mieux alignées. Vous devez choisir cette fonctionnalité par composant.

Version introduite

3.0

Ancien comportement

Des API similaires ASP.NET Core utilisaient des valeurs par défaut SameSiteMode différentes. Un exemple de l’incohérence est observé dans HttpResponse.Cookies.Append(String, String) et HttpResponse.Cookies.Append(String, String, CookieOptions), qui ont respectivement la valeur par défaut SameSiteMode.None et SameSiteMode.Lax.

Nouveau comportement

La valeur par défaut de toutes les API affectées est SameSiteMode.None.

Raison du changement

La valeur par défaut a été modifiée pour faire de SameSite une fonctionnalité d’activation.

Chaque composant qui émet des cookies doit décider si SameSite convient à ses scénarios. Évaluez votre utilisation des API affectées et reconfigurez SameSite en fonction des besoins.

Catégorie

ASP.NET Noyau

API affectées

HTTP : E/S synchrones désactivées sur tous les serveurs

À compter de ASP.NET Core 3.0, les opérations de serveur synchrone sont désactivées par défaut.

Description de la modification

AllowSynchronousIOest une option dans chaque serveur qui active ou désactive les API d’E/S synchrones comme HttpRequest.Body.Read, HttpResponse.Body.Write et Stream.Flush. Ces API ont longtemps été une source de privation de threads et de blocages d’applications. À compter de ASP.NET Core 3.0 Préversion 3, ces opérations synchrones sont désactivées par défaut.

Serveurs affectés :

  • Crécerelle
  • HttpSys
  • Iis in-process
  • TestServer

Attendez-vous aux erreurs suivantes :

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

Chaque serveur a une option AllowSynchronousIO qui contrôle ce comportement et la valeur par défaut pour tous les serveurs est désormais false.

Le comportement peut également être remplacé sur demande en tant qu’atténuation temporaire. Par exemple :

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

Si vous rencontrez des problèmes avec un TextWriter ou un autre flux appelant une API synchrone dans Dispose, appelez la nouvelle API DisposeAsync à la place.

Pour plus d’informations, consultez dotnet/aspnetcore#7644.

Version introduite

3.0

Ancien comportement

Par défaut, HttpRequest.Body.Read, HttpResponse.Body.Write et Stream.Flush sont autorisés.

Nouveau comportement

Ces API synchrones ne sont pas autorisées par défaut :

Attendez-vous aux erreurs suivantes :

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

Raison du changement

Ces API synchrones ont longtemps été une source de privation de threads et de blocages d’applications. À compter de ASP.NET Core 3.0 Préversion 3, les opérations synchrones sont désactivées par défaut.

Utilisez les versions asynchrones des méthodes. Le comportement peut également être remplacé sur demande en tant qu’atténuation temporaire.

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

Catégorie

ASP.NET Noyau

API affectées

Identité : surcharge de méthode AddDefaultUI supprimée

À compter de ASP.NET Core 3.0, la surcharge de méthode IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) n’existe plus.

Version introduite

3.0

Raison du changement

Ce changement est le résultat de l’adoption de la fonctionnalité de ressources web statiques.

Appelez IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) au lieu de la surcharge qui prend deux arguments. Si vous utilisez Bootstrap 3, ajoutez également la ligne suivante à un élément <PropertyGroup> dans votre fichier projet :

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Catégorie

ASP.NET Noyau

API affectées

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identité : la version Bootstrap par défaut de l’interface utilisateur a été modifiée

À compter de ASP.NET Core 3.0, l’interface utilisateur d’identité utilise par défaut la version 4 de Bootstrap.

Version introduite

3.0

Ancien comportement

L’appel de méthode services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); était le même que services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nouveau comportement

L’appel de méthode services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); est le même que services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Raison du changement

Bootstrap 4 a été mis en production pendant la période ASP.NET Core 3.0.

Vous êtes concerné par ce changement si vous utilisez l’interface utilisateur d’identité par défaut et que vous l’avez ajoutée dans Startup.ConfigureServices, comme illustré dans l’exemple suivant :

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

Effectuez l'une des opérations suivantes :

  • Migrez votre application pour utiliser Bootstrap 4 à l’aide de son guide de migration.

  • Mettre à jour Startup.ConfigureServices pour appliquer l’utilisation de Bootstrap 3. Par exemple :

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

Catégorie

ASP.NET Noyau

API affectées

Aucun

Identité : SignInAsync lève l’exception pour l’identité non authentifiée

Par défaut, SignInAsync lève une exception pour les principaux/identités dans laquelle IsAuthenticated est false.

Version introduite

3.0

Ancien comportement

SignInAsync accepte tous les principaux/identités, y compris les identités dans lesquelles IsAuthenticated est false.

Nouveau comportement

Par défaut, SignInAsync lève une exception pour les principaux/identités dans laquelle IsAuthenticated est false. Il existe un nouvel indicateur pour supprimer ce comportement, mais le comportement par défaut a changé.

Raison du changement

L’ancien comportement était problématique, car, par défaut, ces principaux étaient rejetés par [Authorize] / RequireAuthenticatedUser().

Dans ASP.NET Core 3.0 Préversion 6, il existe un indicateur RequireAuthenticatedSignIn sur AuthenticationOptions qui est true par défaut. Définissez cet indicateur sur false pour restaurer l’ancien comportement.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Identité : le constructeur SignInManager accepte le nouveau paramètre

À compter de ASP.NET Core 3.0, un nouveau paramètre IUserConfirmation<TUser> a été ajouté au constructeur SignInManager. Pour plus d’informations, consultez dotnet/aspnetcore#8356.

Version introduite

3.0

Raison du changement

La motivation du changement était d’ajouter le support des nouveaux flux d’e-mail/confirmation dans l’identité.

Si vous construisez manuellement un SignInManager, fournissez une implémentation de IUserConfirmation ou récupérez-en une à partir de l’injection de dépendances à fournir.

Catégorie

ASP.NET Noyau

API affectées

SignInManager<TUser>

Identité : l’interface utilisateur utilise la fonctionnalité de ressources web statiques

ASP.NET Core 3.0 a introduit une fonctionnalité de ressources web statiques et l’interface utilisateur d’identité l’a adoptée.

Description de la modification

Suite à l’adoption par l’interface utilisateur d’identité de la fonctionnalité des ressources web statiques :

  • La sélection de l’infrastructure s’effectue à l’aide de la propriétéIdentityUIFrameworkVersion dans votre fichier projet.
  • Bootstrap 4 est l’infrastructure d’interface utilisateur par défaut pour l’interface utilisateur Identité. Bootstrap 3 a atteint sa fin de vie et vous devez envisager de migrer vers une version prise en charge.

Version introduite

3.0

Ancien comportement

L’infrastructure d’interface utilisateur par défaut pour l’interface utilisateur Identité était Bootstrap 3. L’infrastructure de l’interface utilisateur peut être configurée à l’aide d’un paramètre pour l’appel de méthode AddDefaultUI dans Startup.ConfigureServices.

Nouveau comportement

L’infrastructure d’interface utilisateur par défaut pour l’interface utilisateur Identité est Bootstrap 4. L’infrastructure de l’interface utilisateur doit être configurée dans votre fichier projet, au lieu de celle dans l’appel de méthode AddDefaultUI.

Raison du changement

L’adoption de la fonctionnalité de ressources web statiques exige que la configuration de l’infrastructure de l’interface utilisateur passe à MSBuild. La décision sur l’infrastructure à incorporer est à prendre au moment de la génération. Ce n’est pas une décision de runtime.

Consultez l’interface utilisateur de votre site pour vous assurer que les nouveaux composants Bootstrap 4 sont compatibles. Si nécessaire, utilisez la propriété MSBuild IdentityUIFrameworkVersion pour revenir à la dernière version de Bootstrap 3. Ajoutez la propriété à un élément <PropertyGroup> dans votre fichier projet :

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Catégorie

ASP.NET Noyau

API affectées

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel : adaptateurs de connexion supprimés

Dans le cadre du déplacement des API « pubternal » vers public, le concept d’un IConnectionAdapter a été supprimé de Kestrel. Les adaptateurs de connexion sont remplacés par un intergiciel de connexion (similaire au middleware HTTP dans le pipeline ASP.NET Core, mais pour les connexions de niveau inférieur). HTTPS et la journalisation des connexions sont passés des adaptateurs de connexion à l’intergiciel de connexion. Ces méthodes d’extension doivent continuer à fonctionner en toute transparence, mais les détails de l’implémentation ont changé.

Pour plus d’informations, consultez dotnet/aspnetcore#11412. Pour plus d’informations, consultez dotnet/aspnetcore#11475.

Version introduite

3.0

Ancien comportement

Les composants d’extensibilité Kestrel ont été créés à l’aide de IConnectionAdapter.

Nouveau comportement

Les composants d’extensibilité Kestrel sont créés en tant qu’intergiciel.

Raison du changement

Ce changement est destiné à fournir une architecture d’extensibilité plus flexible.

Convertissez toutes les implémentations de IConnectionAdapter afin d'utiliser le nouveau patron d’intergiciel, comme indiqué dans dotnet/aspnetcore#11412.

Catégorie

ASP.NET Noyau

API affectées

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

Kestrel : assembly HTTPS vide supprimé

L’assembly Microsoft.AspNetCore.Server.Kestrel.Https a été supprimé.

Version introduite

3.0

Raison du changement

Dans ASP.NET Core 2.1, le contenu de Microsoft.AspNetCore.Server.Kestrel.Https a été déplacé vers Microsoft.AspNetCore.Server.Kestrel.Core. Ce changement n’était pas un changement cassant, il a été effectué à l’aide des attributs [TypeForwardedTo].

  • Les bibliothèques faisant référence à Microsoft.AspNetCore.Server.Kestrel.Https 2.0 doivent mettre à jour toutes les dépendances ASP.NET Core vers la version 2.1 ou ultérieure. Sinon, elles peuvent s’arrêter lorsqu’elles sont chargées dans une application ASP.NET Core 3.0.
  • Les applications et bibliothèques ciblant ASP.NET Core 2.1 et versions ultérieures doivent supprimer toutes les références directes au package NuGet Microsoft.AspNetCore.Server.Kestrel.Https.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Kestrel : les en-têtes de code de fin des requêtes ont été déplacés vers la nouvelle collection

Dans les versions antérieures, Kestrel a ajouté des en-têtes de code de fin segmentés HTTP/1.1 dans la collection d’en-têtes des requêtes lorsque le corps de la requête a été lu jusqu’au bout. Ce comportement a suscité des préoccupations concernant l’ambiguïté entre les en-têtes et les codes de fin. La décision a été prise de déplacer les codes de fin vers une nouvelle collection.

Les codes de fin des requêtes HTTP/2 n’étaient pas disponibles dans ASP.NET Core 2.2, mais ils sont désormais disponibles dans cette nouvelle collection dans ASP.NET Core 3.0.

De nouvelles méthodes d’extension de requêtes ont été ajoutées pour accéder à ces codes de fin.

Les codes de fin HTTP/1.1 sont disponibles une fois que l’ensemble du corps de la requête a été lu.

Les codes de fin HTTP/2 sont disponibles une fois qu’ils sont envoyés par le client. Le client n’envoie pas les codes de fin tant que le corps de la requête n’a pas été mis en mémoire tampon par le serveur. Vous devrez peut-être lire le corps de la demande pour libérer de l’espace tampon. Les codes de fin sont toujours disponibles si vous lisez le corps de la demande jusqu’au bout. Les codes de fin marquent la fin du corps.

Version introduite

3.0

Ancien comportement

Les en-têtes de codes de fin des requêtes sont ajoutés à la collection HttpRequest.Headers.

Nouveau comportement

Les en-têtes de code de fin des requêtes ne sont pas présents dans la collection HttpRequest.Headers. Utilisez les méthodes d’extension suivantes sur HttpRequest pour y accéder :

  • GetDeclaredTrailers() : obtient l’en-tête « Code de fin » des requêtes qui répertorie les codes de fin à attendre après le corps.
  • SupportsTrailers() : indique si la demande prend en charge la réception des en-têtes de code de fin.
  • CheckTrailersAvailable() : détermine si la requête prend en charge les codes de fin et s’ils sont disponibles pour la lecture.
  • GetTrailer(string trailerName) : obtient l’en-tête du code de fin demandé à partir de la réponse.

Raison du changement

Les codes de fin sont une fonctionnalité clé dans des scénarios tels que gRPC. La fusion des codes de fin pour des en-têtes de demande a dérouté les utilisateurs.

Utilisez les méthodes d’extension associées au code de fin sur HttpRequest pour accéder aux codes de fin.

Catégorie

ASP.NET Noyau

API affectées

HttpRequest.Headers

Kestrel : abstractions de transport supprimées et rendues publiques

Dans le cadre de l’éloignement des API « pubternal », les API de couche de transport Kestrel sont exposées en tant qu’interface publique dans la bibliothèque Microsoft.AspNetCore.Connections.Abstractions.

Version introduite

3.0

Ancien comportement

  • Des abstractions liées au transport étaient disponibles dans la bibliothèque Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.
  • La propriété ListenOptions.NoDelay était disponible.

Nouveau comportement

  • L’interface IConnectionListener a été introduite dans la bibliothèque Microsoft.AspNetCore.Connections.Abstractions pour exposer les fonctionnalités les plus utilisées de la bibliothèque ...Transport.Abstractions.
  • le NoDelay est désormais disponible dans les options de transport (LibuvTransportOptions et SocketTransportOptions).
  • SchedulingMode n’est plus disponible.

Raison du changement

ASP.NET Core 3.0 a été retiré des API « pubternal ».

Catégorie

ASP.NET Noyau

API affectées

Aucun

Localisation : ResourceManagerWithCultureStringLocalizer et WithCulture marqués comme obsolètes

La classe ResourceManagerWithCultureStringLocalizer et le membre de l’interface WithCulture sont souvent des sources de confusion pour les utilisateurs de la localisation, en particulier lors de la création de leur propre implémentation IStringLocalizer. Ces éléments donnent à l’utilisateur l’impression qu’une instance IStringLocalizer est « par langage, par ressource ». En réalité, les instances doivent uniquement être « par ressource ». Le langage recherché est déterminé par le CultureInfo.CurrentUICulture au moment de l’exécution. Pour éliminer la source de confusion, les API ont été marquées comme obsolètes dans ASP.NET Core 3.0. Les API seront supprimées dans une version ultérieure.

Pour connaître le contexte, consultez dotnet/aspnetcore#3324. Pour plus d’informations, consultez dotnet/aspnetcore#7756.

Version introduite

3.0

Ancien comportement

Les méthodes n’ont pas été marquées comme Obsolete.

Nouveau comportement

Les méthodes sont marquées Obsolete.

Raison du changement

Les API représentaient un cas d’usage qui n’est pas recommandé. Il y avait une confusion au sujet de la conception de la localisation.

La recommandation est d’utiliser ResourceManagerStringLocalizer à la place. Laissez la culture être définie par le CurrentCulture. Si ce n’est pas une option, créez et utilisez une copie de ResourceManagerWithCultureStringLocalizer.

Catégorie

ASP.NET Noyau

API affectées

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

Journalisation : la classe DebugLogger est devenue interne

Avant ASP.NET Core 3.0, le modificateur d’accès de DebugLogger était public. Dans ASP.NET Core 3.0, le modificateur d’accès est passé à internal.

Version introduite

3.0

Raison du changement

Le changement est apporté à :

  • Appliquez la cohérence avec d’autres implémentations de l’enregistreur d’événements, telles que ConsoleLogger.
  • Réduisez la surface de l’API.

Utilisez la méthode d’extension AddDebugILoggingBuilder pour activer la journalisation de débogage. DebugLoggerProvider est également toujours public dans le cas où le service doit être inscrit manuellement.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC : suffixe asynchrone découpé des noms d’action du contrôleur

Dans le cadre de l’adressage dotnet/aspnetcore#4849, ASP.NET Core MVC découpe le suffixe Async des noms d’action par défaut. À compter de ASP.NET Core 3.0, ce changement affecte à la fois le routage et la génération de liens.

Version introduite

3.0

Ancien comportement

Prenez en compte le contrôleur MVC ASP.NET Core suivant :

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

L’action est routable via Product/ListAsync. La génération de liens nécessite la spécification du suffixe Async. Par exemple :

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

Nouveau comportement

Dans ASP.NET Core 3.0, l’action est routable via Product/List. Le code de génération de lien doit omettre le suffixe Async. Par exemple :

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

Ce changement n’affecte pas les noms spécifiés à l’aide de l’attribut [ActionName]. Le nouveau comportement peut être désactivé en définissant MvcOptions.SuppressAsyncSuffixInActionNamesfalse sur Startup.ConfigureServices :

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

Raison du changement

Par convention, les méthodes .NET asynchrones contiennent le suffixe Async. Toutefois, lorsqu’une méthode définit une action MVC, il n’est pas souhaitable d’utiliser le suffixe Async.

Si votre application dépend des actions MVC qui préservent le suffixe Async du nom, choisissez l’une des atténuations suivantes :

  • Utilisez l’attribut [ActionName] pour conserver le nom d’origine.
  • Désactivez entièrement le renommage en définissant MvcOptions.SuppressAsyncSuffixInActionNames sur false dans Startup.ConfigureServices :
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Catégorie

ASP.NET Noyau

API affectées

Aucun

MVC : JsonResult déplacé vers Microsoft.AspNetCore.Mvc.Core

JsonResult a été déplacé vers l’assembly Microsoft.AspNetCore.Mvc.Core. Ce type était utilisé pour être défini dans Microsoft.AspNetCore.Mvc.Formatters.Json. Un attribut [TypeForwardedTo] au niveau de l’assembly a été ajouté àMicrosoft.AspNetCore.Mvc.Formatters.Json pour résoudre ce problème pour la majorité des utilisateurs. Les applications qui utilisent des bibliothèques tierces peuvent rencontrer des problèmes.

Version introduite

3.0 Préversion 6

Ancien comportement

Une application utilisant une bibliothèque basée sur la version 2.2 est générée avec succès.

Nouveau comportement

Une application utilisant une bibliothèque 2.2 échoue à la compilation. Une erreur contenant une variante du texte suivant est fournie :

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'

Pour obtenir un exemple de ce type de problème, consultez dotnet/aspnetcore#7220.

Raison du changement

Changements au niveau de la plateforme de la composition des ASP.NET Core comme décrit dans aspnet/Announcements#325.

Les bibliothèques compilées sur la version 2.2 de Microsoft.AspNetCore.Mvc.Formatters.Json peuvent devoir être recompilées pour résoudre le problème pour tous les contrôles serveur consommateur. S’il est concerné, contactez l’auteur de la bibliothèque. Demandez la recompilation de la bibliothèque pour cibler ASP.NET Core 3.0.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Mvc.JsonResult

MVC : outil de précompilation déconseillé

Dans ASP.NET Core 1.1, le package Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (outil de précompilation MVC) a été introduit pour ajouter le support de la compilation au moment de la publication des fichiers Razor (fichiers .cshtml). Dans ASP.NET Core 2.1, le Kit de développement logiciel (SDK) Razor a été introduit pour développer les fonctionnalités de l’outil de précompilation. Le Kit de développement logiciel (SDK) Razor a ajouté le support de la compilation au moment de la génération et de la publication des fichiers Razor. Le Kit de développement logiciel (SDK) vérifie l’exactitude des fichiers .cshtml au moment de la génération tout en s’améliorant au moment du démarrage de l’application. Le Kit de développement logiciel (SDK) Razor est activé par défaut et aucun mouvement n’est nécessaire pour commencer à l’utiliser.

Dans ASP.NET Core 3.0, l’outil de précompilation MVC 1.1-era ASP.NET Core a été supprimé. Les versions de package antérieures continueront de recevoir des patches importants de bogues et de sécurité dans la mise en production du patch.

Version introduite

3.0

Ancien comportement

Le package Microsoft.AspNetCore.Mvc.Razor.ViewCompilation a été utilisé pour précompiler les affichages Razor MVC.

Nouveau comportement

Le Kit de développement logiciel (SDK) Razor prend en charge cette fonctionnalité en mode natif. Le package Microsoft.AspNetCore.Mvc.Razor.ViewCompilation n’est plus mis à jour.

Raison du changement

Le Kit de développement logiciel (SDK) Razor fournit davantage de fonctionnalités et vérifie l’exactitude des fichiers .cshtml au moment de la génération. Le Kit de développement logiciel (SDK) améliore également le temps de démarrage de l’application.

Pour les utilisateurs de ASP.NET Core 2.1 ou version ultérieure, mettez à jour pour utiliser le support native de la précompilation dans le Kit de développement logiciel (SDK) Razor. Si des bogues ou des fonctionnalités manquantes empêchent la migration vers le Kit de développement logiciel (SDK) Razor, ouvrez un problème sur dotnet/aspnetcore.

Catégorie

ASP.NET Noyau

API affectées

Aucun

MVC : les types « pubternal » sont passés en interne

Dans ASP.NET Core 3.0, tous les types « pubternal » dans MVC ont été mis à jour pour être public dans un espace de noms pris en charge ou internal le cas échéant.

Description de la modification

Dans ASP.NET Core, les types « pubternal » sont déclarés comme public mais résident dans un espace de noms avec le suffixe .Internal. Bien que ces types soient public, ils n’ont aucune stratégie de support et sont sujets à des changements cassants. Malheureusement, l’utilisation accidentelle de ces types a été fréquente, ce qui a entraîné des changements cassants dans ces projets en limitant la capacité à gérer l’infrastructure.

Version introduite

3.0

Ancien comportement

Certains types dans MVC étaient public mais dans un espace de noms .Internal. Ces types n’avaient aucune stratégie de support et étaient sujets à des changements cassants.

Nouveau comportement

Tous ces types sont mis à jour pour être public dans un espace de noms pris en charge ou marqués comme internal.

Raison du changement

L’utilisation accidentelle de ces types « pubternal » a été fréquente, ce qui a entraîné des changements cassants dans ces projets en limitant la capacité à gérer l’infrastructure.

Si vous utilisez des types qui sont devenus vraiment public et qui ont été déplacés vers un nouvel espace de noms pris en charge, mettez à jour vos références pour qu’elles correspondent aux nouveaux espaces de noms.

Si vous utilisez des types qui ont été marqués comme internal, vous devez trouver une alternative. Les types « pubternal » précédents n’étaient jamais pris en charge pour un usage public. S’il existe des types spécifiques dans ces espaces de noms qui sont critiques pour vos applications, signalez un problème sur dotnet/aspnetcore. Des considérations peuvent être prises en compte pour créer les types public demandés.

Catégorie

ASP.NET Noyau

API affectées

Ce changement inclut les types dans les espaces de noms suivants :

  • 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 : le shim de compatibilité de l’API web a été supprimé

À compter de ASP.NET Core 3.0, le package Microsoft.AspNetCore.Mvc.WebApiCompatShim n’est plus disponible.

Description de la modification

Le package Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) fournit une compatibilité partielle dans ASP.NET Core avec ASP.NET API Web 4.x 2 pour simplifier la migration des implémentations d’API web existantes vers ASP.NET Core. Toutefois, les applications qui utilisent WebApiCompatShim ne bénéficient pas des fonctionnalités liées à l’API qui sont livrées dans les versions récentes ASP.NET Core. Ces fonctionnalités incluent l’amélioration de la génération de spécifications Open API, la gestion standardisée des erreurs et la génération du code client. Pour mieux concentrer les efforts de l’API dans la version 3.0, WebApiCompatShim a été supprimé. Les applications existantes utilisant WebApiCompatShim doivent migrer vers le modèle [ApiController] plus récent.

Version introduite

3.0

Raison du changement

Le shim de compatibilité de l’API web était un outil de migration. Il limite l’accès utilisateur aux nouvelles fonctionnalités ajoutées dans ASP.NET Core.

Supprimez l’utilisation de ce shim et migrez directement vers les fonctionnalités similaires dans ASP.NET Core lui-même.

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor : l’API RazorTemplateEngine a été supprimée

L’API RazorTemplateEngine a été supprimée et remplacée par Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Pour plus d’informations, consultez le problème GitHub dotnet/aspnetcore#25215.

Version introduite

3.0

Ancien comportement

Un moteur de modèle peut être créé et utilisé pour analyser et générer du code pour les fichiers Razor.

Nouveau comportement

RazorProjectEngine peut être créé avec le même type d’informations que RazorTemplateEngine pour analyser et générer du code pour les fichiers Razor. RazorProjectEngine fournit également des niveaux de configuration supplémentaires.

Raison du changement

RazorTemplateEngine était trop étroitement couplé aux implémentations existantes. Ce couplage serré a conduit à plus de questions lors de la tentative de configurer correctement un pipeline d’analyse/génération Razor.

Utilisez RazorProjectEngine au lieu de RazorTemplateEngine. Voici quelques exemples.

Créer et configurer RazorProjectEngine
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

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

            // More configuration can go here
        });
Générer du code pour un fichier Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

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

Catégorie

ASP.NET Noyau

API affectées

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor : compilation du runtime déplacée vers un package

Le support de la compilation du runtime des affichages Razor et des pages Razor a été déplacée vers un package distinct.

Version introduite

3.0

Ancien comportement

La compilation runtime est disponible sans avoir besoin de packages supplémentaires.

Nouveau comportement

La fonctionnalité a été déplacée vers le package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

Les API suivantes étaient précédemment disponibles dans Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions pour prendre en charge la compilation du runtime. Les API sont désormais disponibles via Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders est maintenant MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences est maintenant MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

En outre, Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange a été supprimé. La recompilation sur les changements de fichier est activée par défaut en référençant le package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

Raison du changement

Ce changement était nécessaire pour supprimer la dépendance de l’infrastructure partagée ASP.NET Core envers Roslyn.

Les applications qui nécessitent une compilation ou une recompilation du runtime de fichiers Razor doivent effectuer les étapes suivantes :

  1. Ajouter une référence au package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

  2. Mettre à jour la méthode Startup.ConfigureServices du projet pour inclure un appel à AddRazorRuntimeCompilation. Par exemple :

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Catégorie

ASP.NET Noyau

API affectées

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

État de session : API obsolètes supprimées

Les API obsolètes pour la configuration des cookies de session ont été supprimées. Pour plus d’informations, consultez aspnet/Announcements#257.

Version introduite

3.0

Raison du changement

Ce changement applique la cohérence entre les API pour la configuration des fonctionnalités qui utilisent des cookies.

Migrez l’utilisation des API supprimées vers leurs remplacements plus récents. Prenons l’exemple suivant dans 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;
    });
}

Catégorie

ASP.NET Noyau

API affectées

Infrastructure partagée : les assemblys supprimés de Microsoft.AspNetCore.App

À compter de ASP.NET Core 3.0, l’infrastructure partagée ASP.NET Core (Microsoft.AspNetCore.App) contient uniquement des assemblys internes entièrement développés, pris en charge et pouvant être gérés par Microsoft.

Description de la modification

Considérez le changement comme la redéfinition des limites de la « plateforme » ASP.NET Core. L’infrastructure partagée sera compilable par la source par n’importe qui via GitHub et continuera d’offrir les avantages existants des infrastructures partagées .NET Core à vos applications. Certains avantages incluent une taille de déploiement plus petite, une mise à jour corrective centralisée et un temps de démarrage plus rapide.

Dans le cadre du changement, certains changements cassants notables sont introduits dans Microsoft.AspNetCore.App.

Version introduite

3.0

Ancien comportement

Projets référencés Microsoft.AspNetCore.App via un élément <PackageReference> dans le fichier projet.

En outre, Microsoft.AspNetCore.App contenait les sous-composants suivants :

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (assemblys avec le préfixe Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Nouveau comportement

Une référence à Microsoft.AspNetCore.App ne nécessite plus d’élément <PackageReference> dans le fichier projet. Le Kit de développement logiciel (SDK) .NET Core prend en charge un nouvel élément appelé <FrameworkReference>, qui remplace l’utilisation de <PackageReference>.

Pour plus d’informations, consultez dotnet/aspnetcore#3612.

Entity Framework Core expédié comme des packages NuGet. Ce changement aligne le modèle d’expédition sur toutes les autres bibliothèques d’accès aux données sur .NET. Il fournit à Entity Framework Core le chemin d’accès le plus simple pour continuer à innover tout en prenant en charge les différentes plateformes .NET. Le déplacement d’Entity Framework Core hors de l’infrastructure partagée n’a aucun impact sur son état en tant que bibliothèque développée, prise en charge et utilisable par Microsoft. La stratégie de support de .NET Core continue de le couvrir.

Json.NET et Entity Framework Core continuent de fonctionner avec ASP.NET Core. Toutefois, ils ne seront pas inclus dans l’infrastructure partagée.

Pour plus d’informations, consultez L’avenir de JSON dans .NET Core 3.0. Consultez également la liste complète des composants binaires supprimés de l’infrastructure partagée.

Raison du changement

Ce changement simplifie la consommation de Microsoft.AspNetCore.App et réduit la duplication entre les packages NuGet et les infrastructures partagées.

Pour plus d’informations sur la motivation de ce changement, consultez ce billet de blog.

À compter de ASP.NET Core 3.0, il n’est plus nécessaire que les projets consomment des assemblys dans Microsoft.AspNetCore.App en tant que packages NuGet. Pour simplifier le ciblage et l’utilisation de l’infrastructure partagée ASP.NET Core, de nombreux packages NuGet livrés depuis ASP.NET Core 1.0 ne sont plus produits. Les API que ces packages fournissent sont toujours disponibles pour les applications à l’aide d’un <FrameworkReference> pour Microsoft.AspNetCore.App. Les exemples d’API courants incluent Kestrel, MVC et Razor.

Ce changement ne s’applique pas à tous les composants binaires référencés via Microsoft.AspNetCore.App dans ASP.NET Core 2.x. Les exceptions notables sont les suivantes :

  • Les bibliothèques Microsoft.Extensions qui continuent de cibler .NET Standard sont disponibles en tant que packages NuGet (consultez https://github.com/dotnet/extensions).
  • Les API produites par l’équipe ASP.NET Core qui ne font pas partie de Microsoft.AspNetCore.App. Par exemple, les composants suivants sont disponibles en tant que packages NuGet :
  • Extensions de MVC qui gèrent le support de Json.NET. Une API est fournie en tant que package NuGet pour prendre en charge l’utilisation de Json.NET et MVC. Consultez le guide de migration ASP.NET Core pour plus d’informations.
  • Le client SignalR .NET continue de prendre en charge .NET Standard et est fourni en tant que package NuGet. Il est destiné à être utilisé sur de nombreux runtimes .NET, tels que Xamarin et UWP.

Pour plus d’informations, consultez Arrêter la production de packages pour les assemblys d’infrastructures partagées dans la version 3.0. Pour plus d’informations, consultez dotnet/aspnetcore#3757.

Catégorie

ASP.NET Noyau

API affectées

Infrastructure partagée : Microsoft.AspNetCore.All supprimé

À compter de ASP.NET Core 3.0, le métapaquet Microsoft.AspNetCore.All et l’infrastructure partagée Microsoft.AspNetCore.All correspondante ne sont plus produits. Ce package est disponible dans ASP.NET Core 2.2 et continuera de recevoir des mises à jour de maintenance dans ASP.NET Core 2.1.

Version introduite

3.0

Ancien comportement

Les applications peuvent utiliser le métapaquet Microsoft.AspNetCore.All pour cibler l’infrastructure partagée Microsoft.AspNetCore.All sur .NET Core.

Nouveau comportement

.NET Core 3.0 n’inclut pas d’infrastructure partagée Microsoft.AspNetCore.All.

Raison du changement

Le métapaquet Microsoft.AspNetCore.All comprenait un grand nombre de dépendances externes.

Migrez votre projet pour utiliser l’infrastructure Microsoft.AspNetCore.App. Les composants qui étaient précédemment disponibles dans Microsoft.AspNetCore.All sont toujours disponibles sur NuGet. Ces composants sont désormais déployés avec votre application au lieu d’être inclus dans l’infrastructure partagée.

Catégorie

ASP.NET Noyau

API affectées

Aucun

SignalR : HandshakeProtocol.SuccessHandshakeData remplacé

Le champ HandshakeProtocol.SuccessHandshakeData a été supprimé et remplacé par une méthode d’assistance qui génère une réponse de négociation réussie en fonction d’un IHubProtocolspécifique.

Version introduite

3.0

Ancien comportement

HandshakeProtocol.SuccessHandshakeData était un champ public static ReadOnlyMemory<byte>.

Nouveau comportement

HandshakeProtocol.SuccessHandshakeData a été remplacé par une méthode staticGetSuccessfulHandshake(IHubProtocol protocol) qui retourne un ReadOnlyMemory<byte> basé sur le protocole spécifié.

Raison du changement

Des champs supplémentaires ont été ajoutés à la réponse d’établissement d'une liaison. Ils ne sont pas constants et changent en fonction du protocole sélectionné.

Aucun. Ce type n’est pas conçu pour être utilisé à partir du code utilisateur. Il s’agit de public et il peut donc être partagé entre le serveur SignalR et le client. Il peut également être utilisé par les clients SignalR du client écrits dans .NET. Les utilisateurs de SignalR ne doivent pas être affectés par ce changement.

Catégorie

ASP.NET Noyau

API affectées

HandshakeProtocol.SuccessHandshakeData

SignalR : méthodes HubConnection ResetSendPing et ResetTimeout supprimées

Les méthodes ResetSendPing et ResetTimeout ont été supprimées de l’API HubConnection SignalR. Ces méthodes étaient initialement destinées uniquement à un usage interne, mais ont été rendues publiques dans ASP.NET Core 2.2. Ces méthodes ne seront pas disponibles à partir de la version ASP.NET Core 3.0 Préversion 4. Pour plus d’informations, consultez dotnet/aspnetcore#8543.

Version introduite

3.0

Ancien comportement

Les API étaient disponibles.

Nouveau comportement

Les API sont supprimées.

Raison du changement

Ces méthodes étaient initialement destinées uniquement à un usage interne, mais ont été rendues publiques dans ASP.NET Core 2.2.

N’utilisez pas ces méthodes.

Catégorie

ASP.NET Noyau

API affectées

SignalR : les constructeurs HubConnectionContext ont été modifiés

Les constructeurs HubConnectionContext de SignalR ont été changés pour accepter un type d’options, plutôt que plusieurs paramètres, en options d’ajout à l’épreuve du temps. Ce changement remplace deux constructeurs par un seul constructeur qui accepte un type d’options.

Version introduite

3.0

Ancien comportement

HubConnectionContext a deux constructeurs :

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

Nouveau comportement

Les deux constructeurs ont été supprimés et remplacés par un seul constructeur :

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

Raison du changement

Le nouveau constructeur utilise un nouvel objet d’options. Par conséquent, les fonctionnalités de HubConnectionContext peuvent être développées à l’avenir sans apporter plus de constructeurs ni de changements cassants.

Au lieu d’utiliser le constructeur suivant :

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

Utilisez le constructeur suivant :

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

Catégorie

ASP.NET Noyau

API affectées

SignalR : changement du nom du package client JavaScript

Dans ASP.NET Core 3.0 Préversion 7, le nom du package client JavaScript SignalR est passé de @aspnet/signalr à @microsoft/signalr. Le changement de nom reflète le fait que l’utilité de SignalR est plus large que pour les applications ASP.NET Core seules, grâce à Azure SignalR Service.

Pour réagir à ce changement, modifiez les références dans vos fichiers package.json, instructions require et instructions import ECMAScript. Aucune API ne sera modifiée dans le cadre de ce renommage.

Pour plus d’informations, consultez dotnet/aspnetcore#11637.

Version introduite

3.0

Ancien comportement

Le package client a été nommé @aspnet/signalr.

Nouveau comportement

Le package client est nommé @microsoft/signalr.

Raison du changement

Le changement de nom précise que SignalR est utile au-delà des applications ASP.NET Core, grâce à Azure SignalR Service.

Basculez vers le nouveau package @microsoft/signalr.

Catégorie

ASP.NET Noyau

API affectées

Aucun

SignalR : méthodes UseSignalR et UseConnections marquées comme obsolètes

Les méthodes UseConnections et UseSignalR et les classes ConnectionsRouteBuilder et HubRouteBuilder sont marquées comme obsolètes dans ASP.NET Core 3.0.

Version introduite

3.0

Ancien comportement

Le routage du hub SignalR a été configuré à l’aide de UseSignalR ou UseConnections.

Nouveau comportement

L’ancienne méthode de configuration du routage a été obsolète et remplacée par le routage de point de terminaison.

Raison du changement

L’intergiciel est déplacé vers le nouveau système de routage du point de terminaison. L’ancienne méthode d’ajout d’intergiciels est devenue obsolète.

Remplacez UseSignalR par UseEndpoints :

Ancien code :

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

Nouveau code :

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

Catégorie

ASP.NET Noyau

API affectées

SPA : SpaServices et NodeServices marqués comme obsolètes

Le contenu des packages NuGet suivants n’a pas été nécessaire depuis ASP.NET Core 2.1. Par conséquent, les packages suivants sont marqués comme obsolètes :

Pour la même raison, les modules npm suivants sont marqués comme déconseillés :

Les packages précédents et les modules npm seront supprimés ultérieurement dans .NET 5.

Version introduite

3.0

Ancien comportement

Les packages déconseillés et les modules npm étaient destinés à intégrer ASP.NET Core à différentes infrastructures d’applications monopages (SPA). Ces infrastructures incluent Angular, React et React avec Redux.

Nouveau comportement

Un nouveau mécanisme d’intégration existe dans le package NuGet Microsoft.AspNetCore.SpaServices.Extensions. Le package reste la base des modèles de projet Angular et React depuis ASP.NET Core 2.1.

Raison du changement

ASP.NET Core prend en charge l’intégration à différentes infrastructures d’applications monopages (SPA), notamment Angular, React et React avec Redux. Au départ, l’intégration à ces infrastructures a été effectuée avec des composants spécifiques à ASP.NET Core qui géraient des scénarios tels que le prérendu côté serveur et l’intégration à Webpack. Au fil du temps, les normes de l’industrie ont changé. Chacune des infrastructures SPA a publié ses propres interfaces de ligne de commande standard. Par exemple, Angular CLI et create-react-app.

Lorsque ASP.NET Core 2.1 a été publié en mai 2018, l’équipe a réagi au changement de normes. Un moyen plus récent et plus simple d’intégrer les propres chaînes d’outils des infrastructures SPA a été fourni. Le nouveau mécanisme d’intégration existe dans le package Microsoft.AspNetCore.SpaServices.Extensions et reste la base des modèles de projet Angular et React depuis ASP.NET Core 2.1.

Pour clarifier que les anciens composants spécifiques aux ASP.NET Core sont non pertinents et non recommandés :

  • Le mécanisme d’intégration antérieur à la version 2.1 est marqué comme obsolète.
  • Les packages npm de support sont marqués comme déconseillés.

Si vous utilisez ces packages, mettez à jour vos applications pour utiliser les fonctionnalités suivantes :

  • Dans le package Microsoft.AspNetCore.SpaServices.Extensions.
  • Fournis par les infrastructures SPA que vous utilisez

Pour activer des fonctionnalités telles que le prérendu côté serveur et le rechargement de module à chaud, consultez la documentation de l’infrastructure SPA correspondante. La fonctionnalité dans Microsoft.AspNetCore.SpaServices.Extensionsn’est pas obsolète et continuera d’être prise en charge.

Catégorie

ASP.NET Noyau

API affectées

SPA : SpaServices et NodeServices ne reviennent plus à l’enregistreur d’événements de la console

Microsoft.AspNetCore.SpaServices et Microsoft.AspNetCore.NodeServices n’affichent pas les journaux de console, sauf si la journalisation est configurée.

Version introduite

3.0

Ancien comportement

Microsoft.AspNetCore.SpaServices et Microsoft.AspNetCore.NodeServices utilisés pour créer automatiquement un enregistreur d’événements de console lorsque la journalisation n’est pas configurée.

Nouveau comportement

Microsoft.AspNetCore.SpaServices et Microsoft.AspNetCore.NodeServices n’affichent pas les journaux de console, sauf si la journalisation est configurée.

Raison du changement

Il est nécessaire de s’aligner sur la façon dont les autres packages ASP.NET Core implémentent la journalisation.

Si l’ancien comportement est requis, pour configurer la journalisation de la console, ajoutez services.AddLogging(builder => builder.AddConsole()) à votre méthode Setup.ConfigureServices.

Catégorie

ASP.NET Noyau

API affectées

Aucun

Version cible de .Net Framework : le support .NET Framework a été annulé

À compter de ASP.NET Core 3.0, .NET Framework est une version cible de .Net Framework non prise en charge.

Description de la modification

.NET Framework 4.8 est la dernière version principale de .NET Framework. Les nouvelles applications ASP.NET Core doivent être basées sur .NET Core. À compter de la version de .NET Core 3.0, vous pouvez considérer ASP.NET Core 3.0 comme faisant partie de .NET Core.

Les clients qui utilisent ASP.NET Core avec .NET Framework peuvent continuer de manière entièrement prise en charge à l’aide de la version 2.1 LTS. Le support et la maintenance de la version 2.1 se poursuivent jusqu’au 21 août 2021 au moins. Il s’agit de trois ans après la déclaration de la version LTS conformément à la stratégie de support .NET. Le support des packages ASP.NET Core 2.1 sur .NET Framework s’étendra indéfiniment, comme la stratégie de maintenance des autres infrastructures de ASP.NET basées sur des packages.

Pour plus d’informations sur le déplacement de .NET Framework vers .NET Core, consultez Déplacement vers .NET Core.

Les packages Microsoft.Extensions (tels que la journalisation, l’injection de dépendances et la configuration) et Entity Framework Core ne sont pas affectés. Ils continueront à prendre en charge .NET Standard.

Pour plus d’informations sur la motivation de ce changement, consultez le billet de blog d’origine.

Version introduite

3.0

Ancien comportement

Les applications ASP.NET Core peuvent s’exécuter sur .NET Core ou .NET Framework.

Nouveau comportement

Les applications ASP.NET Core ne peuvent s’exécuter que sur .NET Core.

Effectuez l'une des opérations suivantes :

  • Conservez votre application sur ASP.NET Core 2.1.
  • Migrez votre application et vos dépendances vers .NET Core.

Catégorie

ASP.NET Noyau

API affectées

Aucun