Changements cassants dans .NET Core 3.0

  • Article

Si vous effectuez une migration vers la version 3.0 de .NET Core, ASP.NET Core ou EF Core, les changements cassants répertoriés dans cet article peuvent affecter votre application.

ASP.NET Core

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.

Category

ASP.NET Core

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

Les API « Pubternal » ont été supprimées

Pour mieux gérer la surface d’API publique de ASP.NET Core, la plupart des types dans *.Internal les espaces de noms (appelés API "pubternal") sont devenus vraiment internes. Les membres de ces espaces de noms n’ont jamais été conçus pour être pris en charge en tant qu’API accessibles au public. Les API peuvent s’interrompre dans les versions mineures, ce qui est souvent le cas. Le code qui dépend de ces API s’interrompt lors de la mise à jour vers ASP.NET Core 3.0.

Pour plus d’informations, consultez dotnet/aspnetcore#4932 et dotnet/aspnetcore#11312.

Version introduite

3.0

Ancien comportement

Les API affectées sont marquées avec le modificateur d’accès public et existent dans les espaces de noms *.Internal.

Nouveau comportement

Les API affectées sont marquées avec le modificateur d’accès interne et ne peuvent plus être utilisées par le code en dehors de cet assembly.

Raison du changement

L’aide pour ces API "pubternal" était la suivante :

  • Peut changer sans préavis.
  • N’ont pas été soumis aux stratégies .NET pour empêcher les changements cassants.

Le fait de quitter les API public (même dans les espaces de noms *.Internal) était déroutant pour les clients.

Arrêtez d’utiliser ces API "pubternal". Si vous avez des questions sur d’autres API, ouvrez un problème dans le référentiel dotnet/aspnetcore.

Par exemple, considérez le code de mise en mémoire tampon des requêtes HTTP suivant dans un projet ASP.NET Core 2.2. La méthode d’extension EnableRewind existe dans l’espace de noms Microsoft.AspNetCore.Http.Internal.

HttpContext.Request.EnableRewind();

Dans un projet ASP.NET Core 3.0, remplacez l’appel EnableRewind par un appel à la méthode d’extension EnableBuffering. La fonctionnalité de mise en mémoire tampon des requêtes fonctionne comme dans le passé. EnableBuffering appelle l’API désormais internal.

HttpContext.Request.EnableBuffering();

Category

ASP.NET Core

API affectées

Toutes les API des espaces de noms Microsoft.AspNetCore.* et Microsoft.Extensions.* qui ont un segment Internal dans le nom de l’espace de noms. Par exemple :

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

Authentification : Google+ déconseillé et remplacé

Google commence à arrêter la connexion 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.Owin3.1.0 et ultérieures, une atténuation temporaire est décrite ici. 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();

Category

ASP.NET Core

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.

Category

ASP.NET Core

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 le remplacement CreateTicketAsync, comme illustré ici. L'objet JsonDocument implémente l'objet IDisposable.

La liste suivante présente les changements connus :

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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;

Category

ASP.NET Core

API affectées

None

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

Category

ASP.NET Core

API affectées

None

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)

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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 :

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

Category

ASP.NET Core

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>

Category

ASP.NET Core

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

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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>

Category

ASP.NET Core

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 pour utiliser le nouveau modèle d’intergiciel comme illustré ici.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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

Category

ASP.NET Core

API affectées

None

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 Préversion 3. 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.

Category

ASP.NET Core

API affectées

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.

Category

ASP.NET Core

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

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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

Category

ASP.NET Core

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

Category

ASP.NET Core

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

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

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

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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

Category

ASP.NET Core

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.

Category

ASP.NET Core

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.

Category

ASP.NET Core

API affectées

None

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.

Category

ASP.NET Core

API affectées

None

Bibliothèques .NET Core

Les API qui indiquent la version indiquent désormais le produit et non la version de fichier

La plupart des API qui retournent des versions dans .NET Core retournent désormais la version du produit plutôt que la version du fichier.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, les méthodes, telles que Environment.Version, RuntimeInformation.FrameworkDescription et la boîte de dialogue des propriétés de fichier pour les assemblys .NET Core reflètent la version de fichier. À compter de .NET Core 3.0, elles reflètent la version du produit.

La figure suivante illustre la différence entre les informations de version pour l’assembly System.Runtime.dll de .NET Core 2.2 (à gauche) et de .NET Core 3.0 (à droite), comme indiqué dans la boîte de dialogue des propriétés du fichier de l’Explorateur Windows.

Difference in product version information

Version introduite

3.0

Aucun. Ce changement devrait simplifier la détection des versions et la rendre plus intuitive.

Category

Bibliothèques .NET Core

API affectées

Les instances EncoderFallbackBuffer personnalisées ne peuvent pas revenir en arrière de manière récursive

Les instances EncoderFallbackBuffer personnalisées ne peuvent pas revenir en arrière de manière récursive. L’implémentation de EncoderFallbackBuffer.GetNextChar() doit entraîner une séquence de caractères convertible en encodage de destination. Autrement, une exception se produit.

Description de la modification

Pendant une opération de transcodage de caractère à octet, le runtime détecte les séquences UTF-16 mal formées ou non convertibles et fournit ces caractères à la méthode EncoderFallbackBuffer.Fallback. La méthode Fallback détermine quels caractères doivent être substitués aux données non modifiables d’origine et ces caractères sont vidés en appelant EncoderFallbackBuffer.GetNextChar dans une boucle.

Le runtime tente ensuite de transcoder ces caractères de substitution vers l’encodage cible. Si cette opération réussit, le runtime continue le transcodage à partir de l’endroit où il s’est arrêté dans la chaîne d’entrée d’origine.

Auparavant, les implémentations personnalisées de EncoderFallbackBuffer.GetNextChar() peuvent retourner des séquences de caractères qui ne sont pas convertibles en l’encodage de destination. Si les caractères substitués ne peuvent pas être transcodés en l’encodage cible, le runtime appelle de nouveau la méthode EncoderFallbackBuffer.Fallback avec les caractères de substitution, en attendant que la méthode EncoderFallbackBuffer.GetNextChar() retourne une nouvelle séquence de substitution. Ce processus se poursuit jusqu’à ce que le runtime rencontre éventuellement une substitution bien formée, convertible ou jusqu’à ce qu’un nombre maximal de récursions soit atteint.

À compter de .NET Core 3.0, les implémentations personnalisées de EncoderFallbackBuffer.GetNextChar() doivent retourner des séquences de caractères convertibles en l’encodage de destination. Si les caractères substitués ne peuvent pas être transcodés vers l’encodage cible, une exception ArgumentException est levée. Le runtime n’effectue plus d’appels récursifs dans l’instance EncoderFallbackBuffer.

Ce comportement s’applique uniquement lorsque les trois conditions suivantes sont remplies :

  • Le runtime détecte une séquence UTF-16 mal formée ou une séquence UTF-16 qui ne peut pas être convertie en encodage cible.
  • Une commande EncoderFallback personnalisée a été spécifiée.
  • La commande personnalisée EncoderFallback tente de remplacer une nouvelle séquence UTF-16 mal formée ou non convertible.

Version introduite

3.0

La plupart des développeurs n’ont pas besoin de prendre de mesures.

Si une application utilise une classe EncoderFallback et EncoderFallbackBuffer personnalisée, assurez-vous que l’implémentation de EncoderFallbackBuffer.Fallback remplit la mémoire tampon de secours avec des données UTF-16 bien formées qui sont directement convertibles en encodage cible lorsque la méthode Fallback est appelée pour la première fois par le runtime.

Category

Bibliothèques .NET Core

API affectées

Comportement de mise en forme et d’analyse de type virgule flottante modifié

Le comportement d’analyse et de mise en forme de type virgule flottante (par les types Double et Single) est désormais conforme à l’IEEE. Cela garantit que le comportement des types virgule flottante dans .NET correspond à celui d’autres langages conformes à l’IEEE. Par exemple, double.Parse("SomeLiteral") doit toujours correspondre à ce que C# produit pour double x = SomeLiteral.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la mise en forme avec Double.ToString et Single.ToString et l’analyse avec Double.Parse, Double.TryParse, Single.Parse et Single.TryParse ne sont pas conformes à l’IEEE. Par conséquent, il est impossible de garantir qu’une valeur effectue un aller-retour avec n’importe quelle chaîne de format standard ou personnalisée prise en charge. Pour certaines entrées, la tentative d’analyse d’une valeur formatée peut échouer et, pour d’autres, la valeur analysée n’est pas égale à la valeur d’origine.

À compter de .NET Core 3.0, les opérations d’analyse et de mise en forme de type virgule flottante sont conformes à l’IEEE 754.

Le tableau suivant présente deux extraits de code et la façon dont la sortie change entre .NET Core 2.2 et .NET Core 3.1.

Extrait de code Sortie sur .NET Core 2.2 Sortie sur .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Pour plus d’informations, consultez le billet de blog Améliorations de l’analyse et de la mise en forme de type virgule flottante dans .NET Core 3.0.

Version introduite

3.0

La section Impact potentiel sur le code existant du billet de blog Améliorations de l’analyse et de la mise en forme de type virgule flottante dans .NET Core 3.0 suggère les changements que vous pouvez apporter à votre code si vous souhaitez maintenir le comportement précédent.

  • Pour certaines différences de mise en forme, vous pouvez obtenir un comportement équivalent au comportement précédent en spécifiant une chaîne de format différente.
  • Pour les différences d’analyse, il n’existe aucun mécanisme pour revenir au comportement précédent.

Category

Bibliothèques .NET Core

API affectées

Les opérations d’analyse de type virgule flottante n’échouent plus ou lèvent une OverflowException

Les méthodes d’analyse de type virgule flottante ne lèvent plus d’exception OverflowException et ne retournent plus false lorsqu’elles analysent une chaîne dont la valeur numérique est en dehors de la plage du type virgule flottante Single ou Double.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, les méthodes Double.Parse et Single.Parse lèvent une exception OverflowException pour les valeurs en dehors de la plage pour leur type respectif. Les méthodes Double.TryParse et Single.TryParse retournent false pour les représentations de la chaîne des valeurs numériques hors plage.

À compter de .NET Core 3.0, les méthodes Double.Parse, Double.TryParse, Single.Parse et Single.TryParse n’échouent plus lors de l’analyse des chaînes numériques hors limites. Au lieu de cela, les méthodes d’analyse Double retournent Double.PositiveInfinity pour les valeurs supérieures à Double.MaxValue et Double.NegativeInfinity pour les valeurs inférieures à Double.MinValue. De même, les méthodes d’analyse Single retournent Single.PositiveInfinity pour les valeurs supérieures à Single.MaxValue, et Single.NegativeInfinity pour les valeurs inférieures à Single.MinValue.

Ce changement a été apporté pour améliorer la conformité à l’IEEE 754:2008.

Version introduite

3.0

Ce changement peut affecter votre code de deux façons :

  • Votre code dépend du gestionnaire de OverflowException à exécuter lors d’un dépassement. Dans ce cas, vous devez supprimer l’instruction catch et placer tout code nécessaire dans une instruction If qui vérifie si Double.IsInfinity ou Single.IsInfinity est égal à true.

  • Votre code suppose que les valeurs de type virgule flottante sont différentes de Infinity. Dans ce cas, vous devez ajouter le code nécessaire pour vérifier les valeurs de type virgule flottante PositiveInfinity et NegativeInfinity.

Category

Bibliothèques .NET Core

API affectées

InvalidAsynchronousStateException déplacé vers un autre assembly

La classe InvalidAsynchronousStateException a été déplacée.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la classe InvalidAsynchronousStateException se trouve dans l’assembly System.ComponentModel.TypeConverter.

À compter de .NET Core 3.0, elle réside dans l’assembly System.ComponentModel.Primitives.

Version introduite

3.0

Ce changement affecte uniquement les applications qui utilisent la réflexion pour charger le InvalidAsynchronousStateException en appelant une méthode telle que Assembly.GetType ou une surcharge de Activator.CreateInstance qui suppose que le type se trouve dans un assembly particulier. Si c’est le cas, mettez à jour l’assembly référencé dans l’appel de méthode pour refléter le nouvel emplacement d’assembly du type.

Category

Bibliothèques .NET Core

API affectées

Aucun.

Le remplacement de séquences d’octets UTF-8 mal formées suit les instructions Unicode

Quand la classe UTF8Encoding rencontre une séquence d’octets UTF-8 incorrecte lors d’une opération de transcodage d’un octet à un caractère, elle remplace cette séquence par un caractère de remplacement « � » (caractère de remplacement U + FFFD) dans la chaîne de sortie. .NET Core 3.0 diffère des versions précédentes de .NET Core et de .NET Framework en suivant les meilleures pratiques Unicode pour effectuer ce remplacement pendant l’opération de transcodage.

Cela fait partie d’un effort plus large pour améliorer la gestion UTF-8 dans .NET, notamment par les nouveaux types System.Text.Unicode.Utf8 et System.Text.Rune. Le type UTF8Encoding a reçu des mécanismes de gestion des erreurs améliorés afin qu’il produise une sortie cohérente avec les types nouvellement introduits.

Description de la modification

À compter de .NET Core 3.0, lors du transcodage en caractères, la classe UTF8Encoding effectue une substitution de caractères en fonction des meilleures pratiques Unicode. Le mécanisme de substitution utilisé est décrit parNorme Unicode, Version 12.0, Sec. 3.9 (PDF) dans le titre intitulé Substitution U+FFFD des sous-parties maximales.

Ce comportement s’applique uniquement lorsque la séquence d’octets d’entrée contient des données UTF-8 mal formées. En outre, si l’instance UTF8Encoding a été construite avec throwOnInvalidBytes: true, l’instance UTF8Encoding continue de lever sur une entrée non valide plutôt que d’effectuer un remplacement U+FFFD. Pour plus d’informations sur le constructeur UTF8Encoding, consultez UTF8Encoding(Boolean, Boolean).

Le tableau suivant illustre l’impact de ce changement avec une entrée de 3 octets non valide :

Entrée de 3 octets mal formée Sortie avant .NET Core 3.0 Sortie commençant pas .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (sortie à 2 caractères) [ FFFD FFFD FFFD ] (sortie à 3 caractères)

La sortie à 3 caractères est la sortie préférée, selon le tableau 3-9 du PDF de la norme Unicode précédemment cité.

Version introduite

3.0

Aucune action n’est requise de la part du développeur.

Category

Bibliothèques .NET Core

API affectées

TypeDescriptionProviderAttribute déplacé vers un autre assembly

La classe TypeDescriptionProviderAttribute a été déplacée.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, la classe TypeDescriptionProviderAttribute réside dans l’assembly System.ComponentModel.TypeConverter.

À compter de .NET Core 3.0, elle réside dans l’assembly System.ObjectModel.

Version introduite

3.0

Ce changement affecte uniquement les applications qui utilisent la réflexion pour charger le type TypeDescriptionProviderAttribute en appelant une méthode telle que Assembly.GetType ou une surcharge de Activator.CreateInstance qui suppose que le type se trouve dans un assembly particulier. Si c’est le cas, l’assembly référencé dans l’appel de méthode doit être mis à jour pour refléter le nouvel emplacement d’assembly du type.

Category

Windows Forms

API affectées

Aucun.

ZipArchiveEntry ne gère plus les archives avec des tailles d’entrée incohérentes

Les archives zip indiquent à la fois la taille compressée et la taille non compressée des données dans le répertoire central et l’en-tête local. Les données d’entrée elles-mêmes indiquent également leur taille. Dans .NET Core 2.2 et versions antérieures, ces valeurs n’ont jamais été vérifiées par souci de cohérence. À partir de .NET Core 3.0, elles le sont.

Description de la modification

Dans .NET Core 2.2 et versions antérieures, ZipArchiveEntry.Open() réussit même si l’en-tête local n’est pas en accord avec l’en-tête central du fichier zip. Les données sont compressées jusqu’à ce que la fin du flux compressé soit atteinte même si sa longueur dépasse la taille de fichier non compressée répertoriée dans le répertoire central/en-tête local.

À compter de .NET Core 3.0, la méthode ZipArchiveEntry.Open() vérifie que l’en-tête local et l’en-tête central s’accordent sur les tailles compressée et non compressée d’une entrée. Si ce n’est pas le cas, la méthode lève un InvalidDataException si l’en-tête local et/ou le descripteur de données de l’archive répertorient des tailles qui ne correspondent pas au répertoire central du fichier zip. Lors de la lecture d’une entrée, les données décompressées sont tronquées à la taille de fichier non compressée répertoriée dans l’en-tête.

Ce changement a été apporté pour s’assurer qu’un ZipArchiveEntry représente correctement la taille de ses données et que seule cette quantité de données est lue.

Version introduite

3.0

Repackagez toute archive zip qui présente ces problèmes.

Category

Bibliothèques .NET Core

API affectées

FieldInfo.SetValue lève une exception pour les champs statiques et init uniquement

À compter de .NET Core 3.0, une exception est levée lorsque vous tentez de définir une valeur sur un champ statique InitOnly en appelant System.Reflection.FieldInfo.SetValue.

Description de la modification

Dans .NET Framework et les versions de .NET Core antérieures à la version 3.0, vous pouvez définir la valeur d’un champ statique qui est constante après son initialisation (en lecture seule en C#) en appelant System.Reflection.FieldInfo.SetValue. Cependant, le fait de définir un tel champ de cette manière a entraîné un comportement imprévisible basé sur la version cible de .Net Framework et les paramètres d’optimisation.

Dans .NET Core 3.0 et versions ultérieures, lorsque vous appelez SetValue sur un champ InitOnly statique, une exception System.FieldAccessException est levée.

Conseil

Un champ InitOnly est un champ qui ne peut être défini qu’au moment où il est déclaré ou dans le constructeur pour la classe conteneur. En d’autres termes, il est constant après son initialisation.

Version introduite

3.0

Initialisez des champs InitOnly statiques dans un constructeur statique. Cela s’applique aux types dynamiques et non dynamiques.

Vous pouvez également supprimer l’attribut FieldAttributes.InitOnly du champ, puis appeler FieldInfo.SetValue.

Category

Bibliothèques .NET Core

API affectées

Le passage de GroupCollection à des méthodes d’extension prenant IEnumerable<T> nécessite de lever l’ambiguïté

Lors de l’appel d’une méthode d’extension qui prend un IEnumerable<T> sur un GroupCollection, vous devez lever l’ambiguïté du type à l’aide d’un forçage de type.

Description de la modification

À compter de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implémente IEnumerable<KeyValuePair<String,Group>> en plus des autres types, notamment IEnumerable<Group>. Cela entraîne une ambiguïté lors de l’appel d’une méthode d’extension qui prend un IEnumerable<T>. Si vous appelez une telle méthode d’extension sur une instance GroupCollection, par exemple Enumerable.Count, l’erreur du compilateur suivante s’affichera :

CS1061 : « GroupCollection » ne contient pas de définition pour « Nombre » et aucune méthode d’extension accessible « Nombre » acceptant un premier argument de type « GroupCollection » n’a été trouvée (une directive using ou une référence d’assembly est-elle manquante ?)

Dans les versions précédentes de .NET, il n’y avait aucune ambiguïté et aucune erreur du compilateur.

Version introduite

3.0

Raison du changement

Il s’agissait d’un changement cassant involontaire. Comme c’est le cas depuis un certain temps, nous n’avons pas l’intention de le rétablir. En outre, un tel changement serait lui-même cassant.

Pour les instances GroupCollection, vous pouvez lever l’ambiguïté des appels aux méthodes d’extension qui acceptent un IEnumerable<T> avec un forçage de type.

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

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

Category

Bibliothèques .NET Core

API affectées

Toute méthode d’extension qui accepte un élément IEnumerable<T> est affectée. Par exemple :

Chiffrement

La syntaxe « BEGIN TRUSTED CERTIFICATE » n’est plus prise en charge pour les certificats racines sur Linux

Les certificats racines sur Linux et les autres systèmes de type Unix (mais pas macOS) peuvent être présentés sous deux formes : l’en-tête PEM BEGIN CERTIFICATE standard et l’en-tête PEM BEGIN TRUSTED CERTIFICATE spécifique à OpenSSL. La dernière syntaxe permet d’utiliser une configuration supplémentaire qui a provoqué des problèmes de compatibilité avec la classe System.Security.Cryptography.X509Certificates.X509Chain de .NET Core. Le contenu du certificat racine BEGIN TRUSTED CERTIFICATE n’est plus chargé par le moteur de chaîne à partir de .NET Core 3.0.

Description de la modification

Auparavant, les syntaxes BEGIN TRUSTED CERTIFICATE et BEGIN CERTIFICATE étaient utilisées pour remplir la liste d’approbation racine. Si la syntaxe BEGIN TRUSTED CERTIFICATE a été utilisée et que des options supplémentaires ont été spécifiées dans le fichier, il est possible que X509Chain ait indiqué que l’approbation de chaîne a été explicitement interdite (X509ChainStatusFlags.ExplicitDistrust). Toutefois, si le certificat a également été spécifié avec la syntaxe BEGIN CERTIFICATE dans un fichier précédemment chargé, l’approbation de chaîne a été autorisée.

À compter de .NET Core 3.0, le contenu BEGIN TRUSTED CERTIFICATE n’est plus lus. Si le certificat n’est pas également spécifié via une syntaxe BEGIN CERTIFICATE standard, la X509Chain indique que la racine n’est pas approuvée (X509ChainStatusFlags.UntrustedRoot).

Version introduite

3.0

La plupart des applications ne sont pas affectées par ce changement, mais les applications qui ne peuvent pas voir les deux sources de certificat racine en raison de problèmes d’autorisations peuvent rencontrer des erreurs UntrustedRoot inattendues après la mise à niveau.

De nombreuses distributions Linux écrivent des certificats racines dans deux emplacements : un répertoire à un certificat par fichier et une concaténation à un fichier. Dans certaines distributions, le répertoire à un certificat par fichier utilise la syntaxe BEGIN TRUSTED CERTIFICATE tandis que la concaténation des fichiers utilise la syntaxe BEGIN CERTIFICATE standard. Vérifiez que tous les certificats racines personnalisés sont ajoutés comme BEGIN CERTIFICATE dans l’un de ces emplacements au minimum et que les deux emplacements peuvent être lus par votre application.

Le répertoire classique est /etc/ssl/certs/ et le fichier concaténé classique est /etc/ssl/cert.pem. Utilisez la commande openssl version -d pour déterminer la racine spécifique à la plateforme, qui peut différer de /etc/ssl/. Par exemple, sur Ubuntu 18.04, le répertoire est /usr/lib/ssl/certs/ et le fichier est /usr/lib/ssl/cert.pem. Toutefois, /usr/lib/ssl/certs/ est un lien symbolique vers /etc/ssl/certs/ et /usr/lib/ssl/cert.pem n’existe pas.

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

Category

Chiffrement

API affectées

EnvelopedCms est défini par défaut sur le chiffrement AES-256

L’algorithme de chiffrement symétrique par défaut utilisé par EnvelopedCms est passé de TripleDES à AES-256.

Description de la modification

Dans les versions précédentes, lorsque EnvelopedCms est utilisé pour chiffrer des données sans spécifier d’algorithme de chiffrement symétrique via une surcharge de constructeur, les données sont chiffrées avec l’algorithme TripleDES/3DES/3DEA/DES3-EDE.

À compter de .NET Core 3.0 (via la version 4.6.0 du package NuGet System.Security.Cryptography.Pkcs), l’algorithme par défaut a été remplacé par AES-256 pour la modernisation de l’algorithme et pour améliorer la sécurité des options par défaut. Si un certificat de destinataire de message a une clé publique Diffie-Hellman (non EC), l’opération de chiffrement peut échouer avec une CryptographicException en raison de limitations au niveau de la plateforme sous-jacente.

Dans l’exemple de code suivant, les données sont chiffrées avec TripleDES si elles s’exécutent sur .NET Core 2.2 ou une version antérieure. Si vous exécutez .NET Core 3.0 ou une version ultérieure, elles sont chiffrées avec AES-256.

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

Version introduite

3.0

Si ce changement vous impacte négativement, vous pouvez restaurer le chiffrement TripleDES en spécifiant explicitement l’identificateur de l’algorithme de chiffrement dans un constructeur EnvelopedCms qui inclut un paramètre de type AlgorithmIdentifier, par exemple :

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

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

Category

Chiffrement

API affectées

La taille minimale pour la génération de clés RSAOpenSsl a augmenté

La taille minimale pour la génération de nouvelles clés RSA sur Linux est passée de 384 bits à 512 bits.

Description de la modification

À compter de .NET Core 3.0, la taille minimale de clé légale indiquée par la propriété LegalKeySizes sur les instances RSA de RSA.Create, RSAOpenSsl et RSACryptoServiceProvider sur Linux a augmenté de 384 à 512.

Par conséquent, dans .NET Core 2.2 et les versions antérieures, un appel de méthode tel que RSA.Create(384) aboutit. Dans .NET Core 3.0 et les versions ultérieures, l’appel de méthode RSA.Create(384) lève une exception indiquant que la taille est trop petite.

Ce changement a été apporté car OpenSSL, qui effectue les opérations de chiffrement sur Linux, a augmenté son minimum entre les versions 1.0.2 et 1.1.0. .NET Core 3.0 préfère OpenSSL 1.1.x à 1.0.x et la version signalée minimale a augmenté pour refléter cette nouvelle limitation de dépendance plus élevée.

Version introduite

3.0

Si vous appelez l’une des API affectées, vérifiez que la taille des clés générées n’est pas inférieure au minimum du fournisseur.

Notes

RSA 384 bits est déjà considéré comme non sécurisé (comme l’est RSA 512 bits). Les suggestions modernes, telles que la publication spéciale NIST 800-57 Partie 1 Révision 4, suggèrent d’utiliser la taille minimale 2 048 bits pour les clés nouvellement générées.

Category

Chiffrement

API affectées

.NET Core 3.0 préfère OpenSSL 1.1.x à OpenSSL 1.0.x

.NET Core pour Linux, qui fonctionne sur plusieurs distributions Linux, peut prendre en charge OpenSSL 1.0.x et OpenSSL 1.1.x. .NET Core 2.1 et .NET Core 2.2 recherchent d’abord 1.0.x, puis reviennent à 1.1.x ; .NET Core 3.0 recherche d’abord 1.1.x. Ce changement a été apporté pour ajouter le support des nouvelles normes de chiffrement.

Ce changement peut avoir un impact sur les bibliothèques ou applications qui assurent l’interopérabilité des plateformes avec les types d’interopérabilité spécifiques à OpenSSL dans .NET Core.

Description de la modification

Dans .NET Core 2.2 et les versions antérieures, le runtime préfère charger OpenSSL 1.0.x sur 1.1.x. Cela signifie que les types IntPtr et SafeHandle pour l’interopérabilité avec OpenSSL sont utilisés avec libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 par préférence.

À compter de .NET Core 3.0, le runtime préfère charger OpenSSL 1.1.x sur OpenSSL 1.0.x, de sorte que les types IntPtr et SafeHandle pour l’interopérabilité avec OpenSSL sont utilisés avec libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 par préférence. Par conséquent, les bibliothèques et les applications qui interagissent directement avec OpenSSL peuvent avoir des pointeurs incompatibles avec les valeurs exposées à .NET Core lors de la mise à niveau à partir de .NET Core 2.1 ou .NET Core 2.2.

Version introduite

3.0

Les bibliothèques et applications qui effectuent des opérations directes avec OpenSSL doivent veiller à s’assurer qu’elles utilisent la même version d’OpenSSL que le runtime .NET Core.

Toutes les bibliothèques ou applications qui utilisent les valeurs IntPtr ou SafeHandle des types de chiffrement .NET Core directement avec OpenSSL doivent comparer la version de la bibliothèque qu’elles utilisent avec la nouvelle propriété SafeEvpPKeyHandle.OpenSslVersion pour s’assurer que les pointeurs sont compatibles.

Category

Chiffrement

API affectées

CryptoStream.Dispose transforme le bloc final uniquement lors de l’écriture

La méthode CryptoStream.Dispose, utilisée pour finaliser les opérations CryptoStream, ne tente plus de transformer le bloc final lors de la lecture.

Description de la modification

Dans les versions précédentes de .NET, si un utilisateur effectuait une lecture incomplète lors de l’utilisation de CryptoStream en mode Read, la méthode Dispose pouvait lever une exception (par exemple, lors de l’utilisation d’AES avec un remplissage). L’exception était levée car une tentative de transformation du bloc final survenait alors que les données étaient incomplètes.

Dans .NET Core 3.0 et les versions ultérieures, Dispose ne tente plus de transformer le bloc final lors de la lecture, ce qui permet des lectures incomplètes.

Raison du changement

Ce changement permet des lectures incomplètes du flux de chiffrement lorsqu’une opération réseau est annulée, sans avoir besoin d’intercepter une exception.

Version introduite

3.0

La plupart des applications ne doivent pas être affectées par ce changement.

Si votre application a précédemment intercepté une exception en cas de lecture incomplète, vous pouvez supprimer ce bloc catch. Si votre application a utilisé la transformation du bloc final dans les scénarios de hachage, vous devrez peut-être vous assurer que l’ensemble du flux est lu avant sa suppression.

Category

Chiffrement

API affectées

Entity Framework Core

Changements cassants d’Entity Framework Core

Globalisation

Les paramètres régionaux « C » sont mappés aux paramètres régionaux invariants

.NET Core 2.2 et les versions antérieures dépendent du comportement d’ICU par défaut, qui mappe les paramètres régionaux « C » aux paramètres régionaux en_US_POSIX. Les paramètres régionaux en_US_POSIX ont un comportement de classement indésirable, car ils ne prennent pas en charge les comparaisons de chaînes insensibles à la casse. Étant donné que certaines distributions Linux définissent les paramètres régionaux « C » comme paramètres régionaux par défaut, les utilisateurs rencontraient un comportement inattendu.

Description de la modification

À partir de .NET Core 3.0, le mappage de paramètres régionaux « C » a changé pour utiliser les paramètres régionaux invariants au lieu de en_US_POSIX. Le mappage des paramètres régionaux « C » à l’invariant est également appliqué à Windows pour la cohérence.

Le mappage de « C » à la culture en_US_POSIX a provoqué la confusion parmi les clients, car en_US_POSIX ne prend pas en charge les opérations de tri/recherche de chaînes insensibles à la casse. Étant donné que les paramètres régionaux « C » sont utilisés comme paramètres régionaux par défaut dans certaines distributions Linux, les clients rencontraient ce comportement non souhaité sur ces systèmes d’exploitation.

Version introduite

3.0

Rien de particulier à part la conscience de ce changement. Ce changement affecte uniquement les applications qui utilisent le mappage de paramètres régionaux « C ».

Category

Globalisation

API affectées

Toutes les API de classement et de culture sont affectées par ce changement.

MSBuild

Changement de nom du fichier manifeste de ressources

À compter de .NET Core 3.0, par défaut, MSBuild génère un autre nom de fichier manifeste pour les fichiers de ressources.

Version introduite

3.0

Description de la modification

Avant .NET Core 3.0, si aucune métadonnées LogicalName, ManifestResourceName ou DependentUpon avaient été spécifiées pour un élément EmbeddedResource dans le fichier projet, MSBuild générait un nom de fichier manifeste dans le modèle <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Si RootNamespace n’est pas défini dans le fichier projet, il est défini par défaut sur le nom du projet. Par exemple, le nom du manifeste généré pour un fichier de ressources nommé Form1.resx dans le répertoire du projet racine était MyProject.Form1.resources.

À compter de .NET Core 3.0, si un fichier de ressources est colocalisé avec un fichier source du même nom (par exemple, Form1.resx et Form1.cs), MSBuild utilise des informations type du fichier source pour générer le nom du fichier manifeste dans le modèle<Namespace>.<ClassName>.resources. L’espace de noms et le nom de classe sont extraits du premier type dans le fichier source colocalisé. Par exemple, le nom du manifeste généré pour un fichier de ressources nommé Form1.resx colocalisé avec un fichier source nommé Form1.cs est MyNamespace.Form1.resources. La principale chose à noter est que la première partie du nom de fichier est différente des versions antérieures de .NET Core (MyNamespace au lieu de MyProject).

Notes

Si vous avez des métadonnées LogicalName, ManifestResourceName ou DependentUpon spécifiées sur un élément EmbeddedResource dans le fichier projet, ce changement n’affecte pas ce fichier de ressources.

Ce changement cassant a été introduit avec l’ajout de la propriété EmbeddedResourceUseDependentUponConvention aux projets .NET Core. Par défaut, les fichiers de ressources ne sont pas répertoriés explicitement dans un fichier projet .NET Core. Ils n’ont donc aucune métadonnées DependentUpon pour spécifier comment nommer le fichier .resources généré. Quand EmbeddedResourceUseDependentUponConvention est défini sur true, qui est la valeur par défaut, MSBuild recherche un fichier source colocalisé et extrait un espace de noms et un nom de classe à partir de ce fichier. Si vous définissez EmbeddedResourceUseDependentUponConvention sur false, MSBuild génère le nom du manifeste en fonction du comportement précédent, qui combine RootNamespace et le chemin du fichier relatif.

Dans la plupart des cas, aucune action n’est requise de la part du développeur et votre application devrait continuer à fonctionner. Toutefois, si ce changement arrête votre application, vous pouvez :

  • Modifier votre code pour avoir un nouveau nom de manifeste.

  • Refuser la nouvelle convention d’affectation de noms en définissant EmbeddedResourceUseDependentUponConvention sur false dans votre fichier projet.

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

Category

MSBuild

API affectées

N/A

Mise en réseau

La valeur par défaut de HttpRequestMessage.Version est passée à 1.1

La valeur par défaut de la propriété System.Net.Http.HttpRequestMessage.Version est passée de 2.0 à 1.1.

Version introduite

3.0

Description de la modification

Dans .NET Core 1.0 à 2.0, la valeur par défaut de la propriété System.Net.Http.HttpRequestMessage.Version est 1.1. À compter de .NET Core 2.1, il a été remplacé par la version 2.1.

À compter de .NET Core 3.0, le numéro de version par défaut retourné par la propriété System.Net.Http.HttpRequestMessage.Version est de nouveau 1.1.

Mettez à jour votre code s’il dépend de la propriété System.Net.Http.HttpRequestMessage.Version qui retourne une valeur par défaut de 2.0.

Category

Mise en réseau

API affectées

Voir aussi