Cambios importantes en .NET Core 3.0
Si va a migrar a la versión 3.0 de .NET Core, ASP.NET Core o EF Core, es posible que los cambios importantes de este artículo afecten a la aplicación.
ASP.NET Core
- Se han quitado las API Antiforgery, CORS, Diagnostics, MVC y Routing obsoletas
- API "Pubternal" quitadas
- Autenticación: Google+ en desuso
- Autenticación: se ha quitado la propiedad HttpContext.Authentication
- Autenticación: se han reemplazado los tipos Newtonsoft.Json
- Autenticación: se ha cambiado la firma ExchangeCodeAsync de OAuthHandler
- Autorización: la sobrecarga de AddAuthorization se ha movido a otro ensamblado
- Autorización: se ha quitado IAllowAnonymous de AuthorizationFilterContext.Filters
- Autorización: las implementaciones de IAuthorizationPolicyProvider requieren un método nuevo
- Almacenamiento en caché: se ha quitado la propiedad CompactOnMemoryPressure
- Almacenamiento en caché: Microsoft.Extensions.Caching.SqlServer usa el paquete nuevo SqlClient
- Almacenamiento en caché: los tipos "pubternal" de ResponseCaching se han cambiado a internal
- Protección de datos: uso de nuevas API de Azure Storage por parte de DataProtection.Blobs
- Hospedaje: se ha quitado AspNetCoreModule V1 del conjunto de hospedaje de Windows
- Hospedaje: el host genérico restringe la inserción del constructor de Startup
- Hospedaje: redireccionamiento de HTTPS habilitado para aplicaciones fuera de proceso de IIS
- Hospedaje: se han reemplazado los tipos IHostingEnvironment e IApplicationLifetime
- Hospedaje: se ha quitado ObjectPoolProvider de las dependencias de WebHostBuilder
- HTTP: se ha quitado la extensibilidad de DefaultHttpContext
- HTTP: los campos HeaderNames se han cambiado a static readonly
- HTTP: cambios en la infraestructura del cuerpo de respuesta
- HTTP: se han cambiado algunos valores predeterminados de cookie de SameSite
- HTTP: se ha deshabilitado la E/S sincrónica de forma predeterminada
- Identidad: se ha quitado la sobrecarga del método AddDefaultUI
- Identidad: cambio de versión de arranque de IU
- Identidad: SignInAsync produce una excepción para la identidad no autenticada
- Identidad: el constructor SignInManager acepta un nuevo parámetro
- Identidad: la interfaz de usuario usa la característica de recursos web estáticos
- Kestrel: se han quitado los adaptadores de conexión
- Kestrel: se ha quitado un ensamblado HTTPS vacío
- Kestrel: se han movido los encabezados de finalizador de solicitud a una nueva recopilación
- Kestrel: cambios en la capa de abstracción de transporte
- Localización: API marcadas como obsoletas
- Registro: la clase DebugLogger se ha convertido en interna
- MVC: se ha quitado el sufijo Async de acción de controlador
- MVC: JsonResult se ha trasladado a Microsoft.AspNetCore.Mvc.Core
- MVC: herramienta de precompilación en desuso
- MVC: los tipos se han cambiado a internal
- MVC: se han quitado las correcciones de compatibilidad (shim) con la API web
- Razor: API RazorTemplateEngine eliminada
- Razor: la compilación en tiempo de ejecución se ha movido a un paquete
- Estado de sesión: se han quitado las API obsoletas
- Marco compartido: eliminación de ensamblados de Microsoft.AspNetCore.App
- Marco compartido: se ha eliminado Microsoft.AspNetCore.All
- SignalR: se ha reemplazado HandshakeProtocol.SuccessHandshakeData
- SignalR: se han quitado métodos de HubConnection
- SignalR: se han cambiado los constructores de HubConnectionContext
- SignalR: se ha cambiado el nombre del paquete de cliente de JavaScript
- SignalR: API obsoletas
- SPA: SpaServices y NodeServices se han marcado como obsoletos
- SPA: cambio predeterminado de reserva de registrador de consola de SpaServices y NodeServices
- Marco de destino: no se admite .NET Framework
Se han quitado las API Antiforgery, CORS, Diagnostics, MVC y Routing obsoletas
Se han quitado los miembros obsoletos y los modificadores de compatibilidad en ASP.NET Core 2.2.
Versión introducida
3.0
Motivo del cambio
Mejora de la superficie de API a lo largo del tiempo.
Acción recomendada
Aunque el destino es .NET Core 2,2, siga la guía de los mensajes de compilación obsoletos para adoptar nuevas API en su lugar.
Categoría
ASP.NET Core
API afectadas
Los tipos y miembros siguientes se marcaron como obsoletos para ASP.NET Core 2.1 y 2.2:
Tipos
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
Constructores
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)
Propiedades
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étodos
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
- Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor,Object)
API "Pubternal" quitadas
Para mantener mejor la superficie de la API pública de ASP.NET Core, la mayoría de los tipos de los espacios de nombres *.Internal
(conocidos como API "pubternal") se han vuelto realmente internos. Los miembros de estos espacios de nombres nunca debían admitirse como API de acceso público. Las API podían dividirse en versiones secundarias y con frecuencia lo hacían. El código que depende de estas API se divide cuando se actualiza a ASP.NET Core 3.0.
Para más información, consulte dotnet/aspnetcore#4932 y dotnet/aspnetcore#11312.
Versión introducida
3.0
Comportamiento anterior
Las API afectadas se marcan con el modificador de acceso public
y existen en los espacios de nombres *.Internal
.
Comportamiento nuevo
Las API afectadas se marcan con el modificador de acceso internal y ya no se pueden usar en el código fuera de ese ensamblado.
Motivo del cambio
Las instrucciones para estas API de "pubternal" eran las siguientes:
- Podían cambiar sin previo aviso.
- No estaban sujetas a las directivas de .NET para evitar cambios importantes.
La salida de las API public
(incluso en los espacios de nombres de *.Internal
) era confusa para los clientes.
Acción recomendada
Deje de usar estas API "pubternal". Si tiene alguna pregunta sobre API alternativas, abra una incidencia en el repositorio dotnet/aspnetcore.
Por ejemplo, considere el siguiente código de almacenamiento en búfer de solicitudes HTTP en un proyecto ASP.NET Core 2.2. El método de extensión EnableRewind
existe en el espacio de nombres Microsoft.AspNetCore.Http.Internal
.
HttpContext.Request.EnableRewind();
En un proyecto ASP.NET Core 3.0, reemplace la llamada EnableRewind
por una llamada al método de extensión EnableBuffering
. La característica de almacenamiento en búfer de solicitudes funciona igual que lo hacía antes. EnableBuffering
llama a la API internal
ahora.
HttpContext.Request.EnableBuffering();
Categoría
ASP.NET Core
API afectadas
Todas las API de los espacios de nombres Microsoft.AspNetCore.*
y Microsoft.Extensions.*
que tienen un segmento Internal
en el nombre del espacio de nombres. Por ejemplo:
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
Autenticación: Google+ se ha dejado en desuso y se ha reemplazado
Google está empezando a apagar el inicio de sesión de Google+ en las aplicaciones a partir del 28 de enero de 2019.
Descripción del cambio
ASP.NET 4.x y ASP.NET Core han estado usando las API de inicio de sesión de Google+ para autenticar a los usuarios de cuentas de Google en las aplicaciones web. Los paquetes NuGet afectados son Microsoft.AspNetCore.Authentication.Google para ASP.NET Core y Microsoft.Owin.Security.Google para Microsoft.Owin
con ASP.NET Web Forms y MVC.
Las API de reemplazo de Google utilizan un formato y un origen de datos distintos. Las mitigaciones y soluciones que se proporcionan a continuación tienen en cuenta los cambios estructurales. Las aplicaciones deben comprobar que los datos en sí cumplen sus requisitos. Por ejemplo, los nombres, las direcciones de correo electrónico, los vínculos de perfil y las fotos de perfil pueden proporcionar valores ligeramente distintos a los anteriores.
Versión introducida
Todas las versiones. Este cambio es externo a ASP.NET Core.
Acción recomendada
Owin con ASP.NET Web Forms y MVC
En el caso de Microsoft.Owin
3.1.0 y versiones posteriores, se describe una mitigación temporal aquí. Las aplicaciones deben completar las pruebas con la mitigación para comprobar si hay cambios en el formato de datos. Existen planes para lanzar Microsoft.Owin
4.0.1 con una corrección. Las aplicaciones que usen cualquier versión anterior deben actualizarse a la versión 4.0.1.
ASP.NET Core 1.x
La mitigación en Owin con ASP.NET Web Forms y MVC puede adaptarse a ASP.NET Core 1.x. Las revisiones del paquete NuGet no están planeadas porque 1.x ha alcanzado el estado final del ciclo de vida.
ASP.NET Core 2.x
En el caso la versión 2.x de Microsoft.AspNetCore.Authentication.Google
, reemplace la llamada existente a AddGoogle
en Startup.ConfigureServices
por el código siguiente:
.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");
});
Las revisiones 2.1 y 2.2 de febrero incorporaron la reconfiguración anterior como el nuevo valor predeterminado. No hay ninguna revisión planeada para ASP.NET Core 2.0 porque ha alcanzado el final del ciclo de vida.
ASP.NET Core 3.0
La mitigación proporcionada para ASP.NET Core 2.x también puede usarse para ASP.NET Core 3.0. En versiones preliminares futuras de la versión 3.0, se puede quitar el paquete Microsoft.AspNetCore.Authentication.Google
. A los usuarios se les dirigirá a Microsoft.AspNetCore.Authentication.OpenIdConnect
en su lugar. El código siguiente muestra cómo reemplazar AddGoogle
por AddOpenIdConnect
en Startup.ConfigureServices
. Este reemplazo se puede usar con ASP.NET Core 2.0 y versiones posteriores, y se puede adaptar para ASP.NET Core 1.x, según sea necesario.
.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();
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Authentication.Google
Autenticación: se ha quitado la propiedad HttpContext.Authentication
La propiedad Authentication
en desuso se ha quitado en HttpContext
.
Descripción del cambio
Como parte de dotnet/aspnetcore#6504, la propiedad Authentication
en desuso se ha quitado en HttpContext
. La propiedad Authentication
se ha dejado en desuso desde la versión 2.0. Se ha publicado una guía de migración para migrar código con esta propiedad en desuso a las nuevas API de reemplazo. Las clases o API restantes no utilizadas relacionadas con la pila de autenticación antigua ASP.NET Core 1.x se han quitado en la confirmación dotnet/aspnetcore@d7a7c65.
Para obtener información, vea dotnet/aspnetcore#6533.
Versión introducida
3.0
Motivo del cambio
Las API de ASP.NET Core 1.0 se han reemplazado por métodos de extensión en Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Acción recomendada
Consulte la guía de migración.
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Http.Authentication.AuthenticateInfo
- Microsoft.AspNetCore.Http.Authentication.AuthenticationManager
- Microsoft.AspNetCore.Http.Authentication.AuthenticationProperties
- Microsoft.AspNetCore.Http.Features.Authentication.AuthenticateContext
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeBehavior
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeContext
- Microsoft.AspNetCore.Http.Features.Authentication.DescribeSchemesContext
- Microsoft.AspNetCore.Http.Features.Authentication.IAuthenticationHandler
- Microsoft.AspNetCore.Http.Features.Authentication.IHttpAuthenticationFeature.Handler
- Microsoft.AspNetCore.Http.Features.Authentication.SignInContext
- Microsoft.AspNetCore.Http.Features.Authentication.SignOutContext
- Microsoft.AspNetCore.Http.HttpContext.Authentication
Autenticación: se han reemplazado los tipos Newtonsoft.Json
En ASP.NET Core 3.0, los tipos de Newtonsoft.Json
utilizados en las API de autenticación se han reemplazado por tipos de System.Text.Json
. Excepto en los casos siguientes, el uso básico de los paquetes de autenticación no se ve afectado:
- Clases que se derivan de los proveedores de OAuth, como las de aspnet-contrib.
- Implementaciones avanzadas de manipulación de notificaciones.
Para obtener más información, consulte dotnet/aspnetcore#7105. Para obtener información, vea dotnet/aspnetcore#7289.
Versión introducida
3.0
Acción recomendada
En el caso de las implementaciones de OAuth derivadas, el cambio más común es reemplazar JObject.Parse
por JsonDocument.Parse
en la invalidación CreateTicketAsync
, tal como se muestra aquí. JsonDocument
implementa IDisposable
.
En la lista siguiente se describen los cambios conocidos:
- ClaimAction.Run(JObject, ClaimsIdentity, String) se convierte en
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
. Todas las implementaciones derivadas deClaimAction
se ven afectadas de manera similar. - ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) se convierte en
MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
. - ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, String, Func<JObject,String>) se convierte en
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
. - Ha habido un constructor anterior de OAuthCreatingTicketContext que se ha quitado y otro que ha reemplazado
JObject
porJsonElement
. La propiedadUser
y el métodoRunClaimActions
se han actualizado para que coincidan. - Success(JObject) ahora acepta un parámetro de tipo
JsonDocument
en lugar deJObject
. La propiedadResponse
se ha actualizado para que coincida.OAuthTokenResponse
ahora es descartable y se eliminará medianteOAuthHandler
. Las implementaciones de OAuth derivadas que invalidanExchangeCodeAsync
no necesitan desecharJsonDocument
oOAuthTokenResponse
. - UserInformationReceivedContext.User ha cambiado de
JObject
aJsonDocument
. - TwitterCreatingTicketContext.User ha cambiado de
JObject
aJsonElement
. - El último parámetro de TwitterHandler.CreateTicketAsync(ClaimsIdentity,AuthenticationProperties,AccessToken,JObject) se ha cambiado de
JObject
aJsonElement
. El método de reemplazo es TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Authentication.Facebook
- Microsoft.AspNetCore.Authentication.Google
- Microsoft.AspNetCore.Authentication.MicrosoftAccount
- Microsoft.AspNetCore.Authentication.OAuth
- Microsoft.AspNetCore.Authentication.OpenIdConnect
- Microsoft.AspNetCore.Authentication.Twitter
Autenticación: se ha cambiado la firma ExchangeCodeAsync de OAuthHandler
En ASP.NET Core 3.0, la firma de OAuthHandler.ExchangeCodeAsync
cambió de:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }
A:
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }
Versión introducida
3.0
Comportamiento anterior
Las cadenas code
y redirectUri
se pasaron como argumentos independientes.
Comportamiento nuevo
Code
y RedirectUri
son propiedades de OAuthCodeExchangeContext
que se pueden establecer mediante el constructor de OAuthCodeExchangeContext
. El nuevo tipo de OAuthCodeExchangeContext
es el único argumento que se pasa a OAuthHandler.ExchangeCodeAsync
.
Motivo del cambio
Este cambio permite proporcionar parámetros adicionales de forma no interrumpida. No es necesario crear sobrecargas nuevas de ExchangeCodeAsync
.
Acción recomendada
Construya un elemento OAuthCodeExchangeContext
con los valores adecuados de code
y redirectUri
. Se debe proporcionar una instancia de AuthenticationProperties. Esta instancia de OAuthCodeExchangeContext
única se puede pasar a OAuthHandler.ExchangeCodeAsync
en lugar de varios argumentos.
Categoría
ASP.NET Core
API afectadas
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
Autorización: la sobrecarga de AddAuthorization se ha movido a otro ensamblado
Se ha cambiado a AddAuthorizationCore
el nombre de los métodos AddAuthorization
principales que antes se encontraban en Microsoft.AspNetCore.Authorization
. Los métodos AddAuthorization
antiguos todavía existen, pero ahora se encuentran en el ensamblado Microsoft.AspNetCore.Authorization.Policy
. Las aplicaciones en las que se usen ambos métodos no se verán afectadas. Tenga en cuenta que Microsoft.AspNetCore.Authorization.Policy
ahora se incluye en el marco compartido en lugar de en un paquete independiente, tal como se describe en Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.
Versión introducida
3.0
Comportamiento anterior
Los métodos AddAuthorization
existían en Microsoft.AspNetCore.Authorization
.
Comportamiento nuevo
Los métodos AddAuthorization
existen en Microsoft.AspNetCore.Authorization.Policy
. AddAuthorizationCore
es el nuevo nombre de los métodos antiguos.
Motivo del cambio
AddAuthorization
es un nombre de método más indicado para agregar todos los servicios comunes necesarios para la autorización.
Acción recomendada
Agregue una referencia a Microsoft.AspNetCore.Authorization.Policy
o, en su lugar, use AddAuthorizationCore
.
Categoría
ASP.NET Core
API afectadas
Autorización: se ha quitado IAllowAnonymous de AuthorizationFilterContext.Filters
A partir de ASP.NET Core 3.0, MVC no agrega AllowAnonymousFilters para los atributos [AllowAnonymous] que se detectaron en los controladores y métodos de acción. Este cambio se dirige localmente para los derivados de AuthorizeAttribute, pero es un cambio importante en las implementaciones de IAsyncAuthorizationFilter y IAuthorizationFilter. Estas implementaciones contenidas en un atributo [TypeFilter] son una conocidas y compatibles para lograr la autorización basada en atributos fuertemente tipados cuando se requieren tanto la configuración como la inserción de dependencias.
Versión introducida
3.0
Comportamiento anterior
IAllowAnonymous aparecía en la colección AuthorizationFilterContext.Filters. La prueba de la presencia de la interfaz era un enfoque válido para invalidar o deshabilitar el filtro en métodos de controlador individuales.
Comportamiento nuevo
IAllowAnonymous
ya no aparece en la colección AuthorizationFilterContext.Filters
. Las implementaciones IAsyncAuthorizationFilter
que dependen del comportamiento anterior normalmente producen respuestas intermitentes HTTP 401 no autorizadas o HTTP 403 prohibidas.
Motivo del cambio
Se presentó una nueva estrategia de enrutamiento de puntos de conexión en ASP.NET Core 3.0.
Acción recomendada
Busque IAllowAnonymous
en los metadatos del punto de conexión. Por ejemplo:
var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}
Un ejemplo de esta técnica se encuentra en este método HasAllowAnonymous.
Categoría
ASP.NET Core
API afectadas
None
Autorización: las implementaciones de IAuthorizationPolicyProvider requieren un método nuevo
En ASP.NET Core 3.0, se ha agregado un nuevo método GetFallbackPolicyAsync
a IAuthorizationPolicyProvider
. El middleware de autorización usa esta directiva de reserva cuando no se especifica ninguna directiva.
Para obtener más información, consulte dotnet/aspnetcore#9759.
Versión introducida
3.0
Comportamiento anterior
Las implementaciones de IAuthorizationPolicyProvider
no requerían un método GetFallbackPolicyAsync
.
Comportamiento nuevo
Las implementaciones de IAuthorizationPolicyProvider
requieren un método GetFallbackPolicyAsync
.
Motivo del cambio
Se necesitaba un nuevo método para que el nuevo AuthorizationMiddleware
lo usara cuando no se especificara ninguna directiva.
Acción recomendada
Agregue el método GetFallbackPolicyAsync
a las implementaciones de IAuthorizationPolicyProvider
.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
Almacenamiento en caché: se ha quitado la propiedad CompactOnMemoryPressure
En la versión ASP.NET Core 3.0 se han quitado las API MemoryCacheOptions obsoletas.
Descripción del cambio
Este cambio es una continuación de aspnet/Caching#221. Para obtener información, vea dotnet/extensions#1062.
Versión introducida
3.0
Comportamiento anterior
La propiedad MemoryCacheOptions.CompactOnMemoryPressure
estaba disponible.
Comportamiento nuevo
Se ha quitado la propiedad MemoryCacheOptions.CompactOnMemoryPressure
.
Motivo del cambio
La compactación automática de la caché provocaba problemas. Para evitar un comportamiento inesperado, solo se debe compactar la caché cuando sea necesario.
Acción recomendada
Para compactar la caché, realice la conversión a un tipo heredado MemoryCache
y llame a Compact
cuando sea necesario.
Categoría
ASP.NET Core
API afectadas
MemoryCacheOptions.CompactOnMemoryPressure
Almacenamiento en caché: Microsoft.Extensions.Caching.SqlServer usa el paquete nuevo SqlClient
El paquete Microsoft.Extensions.Caching.SqlServer
usará el paquete nuevo Microsoft.Data.SqlClient
en lugar del System.Data.SqlClient
. Este cambio podría producir pequeños cambios en el comportamiento. Para obtener más información, vea Introducción al nuevo Microsoft.Data.SqlClient.
Versión introducida
3.0
Comportamiento anterior
El paquete Microsoft.Extensions.Caching.SqlServer
usaba el paquete System.Data.SqlClient
.
Comportamiento nuevo
Microsoft.Extensions.Caching.SqlServer
ahora usa el paquete Microsoft.Data.SqlClient
.
Motivo del cambio
Microsoft.Data.SqlClient
es un nuevo paquete que se ha creado a partir de System.Data.SqlClient
. A partir de ahora, aquí es donde se realizará todo el trabajo de las nuevas características.
Acción recomendada
Los clientes no deben preocuparse por este cambio importante, a menos que usaran los tipos que devolvía el paquete Microsoft.Extensions.Caching.SqlServer
y los convirtieran en tipos de System.Data.SqlClient
. Por ejemplo, si algún usuario estuviera convirtiendo un elemento DbConnection
al tipo de SqlConnection anterior, tendría que cambiar la conversión al nuevo tipo de Microsoft.Data.SqlClient.SqlConnection
.
Categoría
ASP.NET Core
API afectadas
None
Almacenamiento en caché: los tipos "pubternal" de ResponseCaching se han cambiado a internal
En ASP.NET Core 3.0, los tipos "pubternal" de ResponseCaching
han cambiado a internal
.
Además, las implementaciones predeterminadas de IResponseCachingPolicyProvider
y IResponseCachingKeyProvider
ya no se agregan a los servicios como parte del método AddResponseCaching
.
Descripción del cambio
In ASP.NET Core, los tipos "pubternal" se declaran como public
pero residen en un espacio de nombres con un sufijo .Internal
. Aunque estos tipos son públicos, no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Versión introducida
3.0
Comportamiento anterior
Estos tipos eran visibles públicamente, pero no eran compatibles.
Comportamiento nuevo
Estos tipos ahora son internal
.
Motivo del cambio
El ámbito de internal
refleja mejor la directiva no compatible.
Acción recomendada
Copiar los tipos que usa la aplicación o biblioteca.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
- Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.ResponseCachingMiddleware(RequestDelegate, IOptions<ResponseCachingOptions>, ILoggerFactory, IResponseCachingPolicyProvider, IResponseCache, IResponseCachingKeyProvider)
Protección de datos: uso de nuevas API de Azure Storage por parte de DataProtection.Blobs
Azure.Extensions.AspNetCore.DataProtection.Blobs
depende de las bibliotecas de Azure Storage. Estas bibliotecas han cambiado el nombre de los ensamblados, paquetes y espacios de nombres. A partir de ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs
utiliza las nuevas API y paquetes con prefijo Azure.Storage.
.
Si tiene preguntas sobre las API de Azure Storage, utilice https://github.com/Azure/azure-storage-net. Para obtener información sobre esta incidencia, consulte dotnet/aspnetcore#19570.
Versión introducida
3.0
Comportamiento anterior
El paquete hacía referencia al paquete NuGet WindowsAzure.Storage
.
El paquete hace referencia al paquete NuGet Microsoft.Azure.Storage.Blob
.
Comportamiento nuevo
El paquete hace referencia al paquete NuGet Azure.Storage.Blob
.
Motivo del cambio
Este cambio permite a Azure.Extensions.AspNetCore.DataProtection.Blobs
migrar a los paquetes de Azure Storage recomendados.
Acción recomendada
Si todavía necesita usar las API de Azure Storage anteriores con ASP.NET Core 3.0, agregue una dependencia directa al paquete WindowsAzure.Storage o Microsoft.Azure.Storage. Este paquete se puede instalar junto con las nuevas API de Azure.Storage
.
En muchos casos, la actualización solo implica cambiar las instrucciones using
para usar los espacios de nombres nuevos:
- 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;
Categoría
ASP.NET Core
API afectadas
None
Hospedaje: se ha quitado AspNetCoreModule V1 del conjunto de hospedaje de Windows
A partir de ASP.NET Core 3.0, el conjunto de hospedaje de Windows no incluirá AspNetCoreModule (ANCM) V1.
ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.
Para obtener información, vea dotnet/aspnetcore#7095.
Versión introducida
3.0
Comportamiento anterior
ANCM V1 está incluido en el conjunto de hospedaje de Windows.
Comportamiento nuevo
ANCM V1 no está incluido en el conjunto de hospedaje de Windows.
Motivo del cambio
ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.
Acción recomendada
Use ANCM V2 con aplicaciones de ASP.NET Core 3.0.
Si se requiere ANCM V1, se puede instalar mediante el conjunto de hospedaje de Windows ASP.NET Core 2.1 o 2.2.
Este cambio interrumpirá las aplicaciones de ASP.NET Core 3.0 que:
- Participen del uso de ANCM V1 con
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
. - Tengan un archivo web.config personalizado con
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
.
Categoría
ASP.NET Core
API afectadas
None
Hospedaje: el host genérico restringe la inserción del constructor de Startup
Los únicos tipos que admite el host genérico para la inserción del constructor de la clase Startup
son IHostEnvironment
, IWebHostEnvironment
e IConfiguration
. Las aplicaciones que usan WebHost
no se ven afectadas.
Descripción del cambio
Antes de ASP.NET Core 3.0, se podía usar la inserción de constructores para tipos arbitrarios en el constructor de la clase Startup
. En ASP.NET Core 3.0, se ha cambiado la plataforma de la pila web a la biblioteca de host genéricos. Puede ver el cambio en el archivo Program.cs de las plantillas:
ASP.NET Core 2.x:
ASP.NET Core 3.0:
Host
usa un contenedor de inserción de dependencias (DI) para compilar la aplicación. WebHost
usa dos contenedores: uno para el host y otro para la aplicación. Como resultado, el constructor de Startup
ya no admite la inserción de servicios personalizados. Solo se pueden insertar IHostEnvironment
, IWebHostEnvironment
e IConfiguration
. Este cambio evita problemas de DI, como la creación duplicada de un servicio singleton.
Versión introducida
3.0
Motivo del cambio
Este cambio es consecuencia del cambio de plataforma de la pila web a la biblioteca de host genéricos.
Acción recomendada
Inserte los servicios en la firma del método Startup.Configure
. Por ejemplo:
public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
Categoría
ASP.NET Core
API afectadas
None
Hospedaje: redireccionamiento de HTTPS habilitado para aplicaciones fuera de proceso de IIS
La versión 13.0.19218.0 del módulo ASP.NET Core (ANCM) para el hospedaje a través de IIS fuera de proceso habilita una característica de redireccionamiento de HTTPS existente para aplicaciones ASP.NET Core 3.0 y 2.2.
Para obtener información, vea dotnet/AspNetCore#15243.
Versión introducida
3.0
Comportamiento anterior
La plantilla de proyecto de ASP.NET Core 2.1 incorporó por primera vez compatibilidad con métodos de middleware de HTTPS como UseHttpsRedirection y UseHsts. La habilitación del redireccionamiento de HTTPS exigía la adición de configuración, ya que las aplicaciones en desarrollo no usan el puerto predeterminado 443. La seguridad de transporte estricta de HTTP (HSTS) solo está activa si la solicitud ya usa HTTPS. Localhost se omite de forma predeterminada.
Comportamiento nuevo
En ASP.NET Core 3.0, el escenario de HTTPS de IIS se ha mejorado. Con la mejora, una aplicación puede detectar los puertos HTTPS del servidor y hacer que UseHttpsRedirection
funcione de forma predeterminada. El componente en proceso ha logrado la detección de puertos con la característica IServerAddresses
, que solo afecta a las aplicaciones ASP.NET Core 3.0, dado que a la biblioteca en proceso se le asigna la versión del marco de trabajo. El componente fuera de proceso ha cambiado para agregar automáticamente la variable de entorno ASPNETCORE_HTTPS_PORT
. Este cambio afecta a las aplicaciones ASP.NET Core 2.2 y 3.0, ya que el componente fuera de proceso se comparte de forma global. Las aplicaciones ASP.NET Core 2.1 no se ven afectadas porque usan una versión anterior de ANCM de forma predeterminada.
El comportamiento anterior se modificó en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) a fin de invertir los cambios de comportamiento en ASP.NET Core 2.x. Estos cambios solo afectan a aplicaciones fuera de proceso de IIS.
Como se ha explicado anteriormente, la instalación de ASP.NET Core 3.0.0 tenía el efecto secundario de activar también el middleware de UseHttpsRedirection
en las aplicaciones ASP.NET Core 2.x. Se ha realizado un cambio en ANCM en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) que consiste en que su instalación ya no tiene este efecto en las aplicaciones ASP.NET Core 2.x. La variable de entorno ASPNETCORE_HTTPS_PORT
que ANCM rellenaba en ASP.NET Core 3.0.0 se ha cambiado a ASPNETCORE_ANCM_HTTPS_PORT
en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3). UseHttpsRedirection
también se ha actualizado en estas versiones para comprender las variables antiguas y nuevas. ASP.NET Core 2.x no se va a actualizar. Por eso, revierte al comportamiento anterior de estar deshabilitado de forma predeterminada.
Motivo del cambio
Funcionalidad mejorada de ASP.NET Core 3.0.
Acción recomendada
No es necesario hacer nada si se quiere que todos los clientes usen HTTPS. Para permitir que algunos clientes empleen HTTP, siga uno de los pasos siguientes:
Quite las llamadas a
UseHttpsRedirection
yUseHsts
del métodoStartup.Configure
del proyecto y vuelva a implementar la aplicación.En el archivo web.config, establezca la variable de entorno
ASPNETCORE_HTTPS_PORT
en una cadena vacía. Este cambio puede producirse directamente en el servidor sin volver a implementar la aplicación. Por ejemplo:<aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" > <environmentVariables> <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" /> </environmentVariables> </aspNetCore>
UseHttpsRedirection
todavía se puede:
- Activar de forma manual en ASP.NET Core 2.x al establecer la variable de entorno
ASPNETCORE_HTTPS_PORT
en el número de puerto correcto (443 en la mayoría de los escenarios de producción). - Desactivar en ASP.NET Core 3.x al definir
ASPNETCORE_ANCM_HTTPS_PORT
con un valor de cadena vacía. Este valor se establece de la misma manera que en el ejemplo deASPNETCORE_HTTPS_PORT
anterior.
Los equipos que ejecutan aplicaciones ASP.NET Core 3.0.0 deben instalar el runtime de ASP.NET Core 3.0.1 antes de instalar el ANCM de ASP.NET Core 3.1.0 (versión preliminar 3). De este modo se garantiza que UseHttpsRedirection
siga funcionando según lo previsto para las aplicaciones ASP.NET Core 3.0.
En Azure App Service, ANCM se implementa conforme a una programación independiente del runtime debido a su naturaleza global. ANCM se implementó en Azure con estos cambios tras la implementación de ASP.NET Core 3.0.1 y 3.1.0.
Categoría
ASP.NET Core
API afectadas
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Hospedaje: los tipos IHostingEnvironment e IApplicationLifetime se han marcado como obsoletos y se han reemplazado
Se han introducido tipos nuevos para reemplazar los tipos de IHostingEnvironment
y IApplicationLifetime
existentes.
Versión introducida
3.0
Comportamiento anterior
Había dos tipos de IHostingEnvironment
y IApplicationLifetime
distintos de Microsoft.Extensions.Hosting
y Microsoft.AspNetCore.Hosting
.
Comportamiento nuevo
Los tipos antiguos se han marcado como obsoletos y se han reemplazado por tipos nuevos.
Motivo del cambio
Cuando Microsoft.Extensions.Hosting
se presentó en ASP.NET Core 2.1, algunos tipos como IHostingEnvironment
y IApplicationLifetime
se copiaron de Microsoft.AspNetCore.Hosting
. Algunos cambios de ASP.NET Core 3.0 provocan que las aplicaciones incluyan los espacios de nombres Microsoft.Extensions.Hosting
y Microsoft.AspNetCore.Hosting
. Cualquier uso de estos tipos duplicados produce un error del compilador de "referencia ambigua" cuando se hace referencia a ambos espacios de nombres.
Acción recomendada
Reemplazados los usos de los tipos anteriores por los tipos recién introducidos, como se indica a continuación:
Tipos obsoletos (advertencia):
- Microsoft.Extensions.Hosting.IHostingEnvironment
- Microsoft.AspNetCore.Hosting.IHostingEnvironment
- Microsoft.Extensions.Hosting.IApplicationLifetime
- Microsoft.AspNetCore.Hosting.IApplicationLifetime
- Microsoft.Extensions.Hosting.EnvironmentName
- Microsoft.AspNetCore.Hosting.EnvironmentName
Tipos nuevos:
- Microsoft.Extensions.Hosting.IHostEnvironment
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
- Microsoft.Extensions.Hosting.IHostApplicationLifetime
- Microsoft.Extensions.Hosting.Environments
Los nuevos métodos de extensión IsDevelopment
y IsProduction
de IHostEnvironment
se encuentran en el espacio de nombres Microsoft.Extensions.Hosting
. Es posible que sea necesario agregar ese espacio de nombres al proyecto.
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Hosting.EnvironmentName
- Microsoft.AspNetCore.Hosting.IApplicationLifetime
- Microsoft.AspNetCore.Hosting.IHostingEnvironment
- Microsoft.Extensions.Hosting.EnvironmentName
- Microsoft.Extensions.Hosting.IApplicationLifetime
- Microsoft.Extensions.Hosting.IHostingEnvironment
Hospedaje: se ha quitado ObjectPoolProvider de las dependencias de WebHostBuilder
Para aumentar la naturaleza de pago por uso de ASP.NET Core, se ha quitado ObjectPoolProvider
del conjunto principal de dependencias. Ahora componentes específicos que dependen de ObjectPoolProvider
lo agregan por sí mismos.
Para obtener información, vea dotnet/aspnetcore#5944.
Versión introducida
3.0
Comportamiento anterior
WebHostBuilder
proporciona ObjectPoolProvider
de forma predeterminada en el contenedor de DI.
Comportamiento nuevo
WebHostBuilder
ya no proporciona ObjectPoolProvider
de forma predeterminada en el contenedor de DI.
Motivo del cambio
Este cambio se ha realizado para aumentar la naturaleza de pago por uso de ASP.NET Core.
Acción recomendada
Si el componente requiere ObjectPoolProvider
, tendrá que agregarlo a las dependencias mediante IServiceCollection
.
Categoría
ASP.NET Core
API afectadas
None
HTTP: se ha quitado la extensibilidad de DefaultHttpContext
Como parte de las mejoras de rendimiento de ASP.NET Core 3.0, se ha quitado la extensibilidad de DefaultHttpContext
. La clase ahora es sealed
. Para obtener más información, consulte dotnet/aspnetcore#6504.
Si en las pruebas unitarias se usa Mock<DefaultHttpContext>
, use Mock<HttpContext>
o new DefaultHttpContext()
en su lugar.
Para obtener información, vea dotnet/aspnetcore#6534.
Versión introducida
3.0
Comportamiento anterior
Las clases se pueden derivar de DefaultHttpContext
.
Comportamiento nuevo
Las clases se pueden derivar de DefaultHttpContext
.
Motivo del cambio
La extensibilidad se proporcionó inicialmente para permitir la agrupación de HttpContext
, pero incorporaba una complejidad innecesaria e impedía otras optimizaciones.
Acción recomendada
Si usa Mock<DefaultHttpContext>
en las pruebas unitarias, empiece a usar Mock<HttpContext>
en su lugar.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Http.DefaultHttpContext
HTTP: las constantes HeaderNames se han cambiado a static readonly
A partir de ASP.NET Core 3.0 Preview 5, los campos de Microsoft.Net.Http.Headers.HeaderNames se han cambiado de const
a static readonly
.
Para obtener información, vea dotnet/aspnetcore#9514.
Versión introducida
3.0
Comportamiento anterior
Estos campos solían ser const
.
Comportamiento nuevo
Ahora estos campos son static readonly
.
Motivo del cambio
El cambio:
- Impide que los valores se inserten en los límites de los ensamblados, lo que permite corregirlos según sea necesario.
- Permite comprobaciones de igualdad de referencia más rápidas.
Acción recomendada
Vuelva a compilar para la versión 3.0. El código fuente que use estos campos de las maneras siguientes ya no podrá hacerlo:
- Como un argumento de atributo
- Como un objeto
case
en una instrucciónswitch
- Al definir otra instancia de
const
Para solucionar el cambio importante, use constantes de nombre de encabezado autodefinidas o literales de cadena.
Categoría
ASP.NET Core
API afectadas
Microsoft.Net.Http.Headers.HeaderNames
HTTP: cambios en la infraestructura del cuerpo de respuesta
La infraestructura que respalda un cuerpo de respuesta HTTP ha cambiado. Si usa HttpResponse
directamente, no debe realizar ningún cambio en el código. Siga leyendo si ajusta o reemplaza HttpResponse.Body
, o si accede a HttpContext.Features
.
Versión introducida
3.0
Comportamiento anterior
Había tres API asociadas al cuerpo de respuesta HTTP:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
Comportamiento nuevo
Si reemplaza HttpResponse.Body
, reemplaza todo el elemento IHttpResponseBodyFeature
por un contenedor en torno a la secuencia dada mediante StreamResponseBodyFeature
con el fin de proporcionar implementaciones predeterminadas para todas las API esperadas. Al volver a establecer la secuencia original, este cambio se revierte.
Motivo del cambio
La motivación es combinar las API del cuerpo de la respuesta en una única interfaz de características nueva.
Acción recomendada
Use IHttpResponseBodyFeature
donde anteriormente usaba IHttpResponseFeature.Body
, IHttpSendFileFeature
o IHttpBufferingFeature
.
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
- Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
- Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
HTTP: cambio a Ninguno de algunos valores predeterminados de cookie de SameSite
SameSite
es una opción para cookies que puede ayudar a mitigar algunos ataques de falsificación de solicitud entre sitios (CSRF). Cuando esta opción se presentó inicialmente, se usaron valores predeterminados incoherentes en varias API de ASP.NET Core. La incoherencia ha generado unos resultados confusos. A partir de ASP.NET Core 3.0, estos valores predeterminados están organizados de mejor forma. Debe aceptar participar en esta característica individualmente para cada componente.
Versión introducida
3.0
Comportamiento anterior
Las API de ASP.NET Core similares usaban diferentes valores predeterminados de SameSiteMode. Un ejemplo de la incoherencia se percibe en HttpResponse.Cookies.Append(String, String)
y HttpResponse.Cookies.Append(String, String, CookieOptions)
, que tenían como valor predeterminado SameSiteMode.None
y SameSiteMode.Lax
, respectivamente.
Comportamiento nuevo
Todas las API afectadas tienen como valor predeterminado SameSiteMode.None
.
Motivo del cambio
El valor predeterminado se ha cambiado para que SameSite
fuera una característica de participación opcional.
Acción recomendada
Cada componente que emite cookies debe decidir si SameSite
es adecuado para sus escenarios. Revise el uso de las API afectadas y vuelva a configurar SameSite
según sea necesario.
Categoría
ASP.NET Core
API afectadas
HTTP: se ha deshabilitado la E/S sincrónica en todos los servidores
A partir de ASP.NET Core 3.0, las operaciones de servidor sincrónicas están deshabilitadas de forma predeterminada.
Descripción del cambio
AllowSynchronousIO
es una opción en cada servidor que habilita o deshabilita las API de E/S sincrónicas, como HttpRequest.Body.Read
, HttpResponse.Body.Write
y Stream.Flush
. Estas API han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación. A partir de ASP.NET Core 3.0, versión preliminar 3, estas operaciones sincrónicas están deshabilitadas de forma predeterminada.
Servidores afectados:
- Kestrel
- HttpSys
- IIS en proceso
- TestServer
Se esperan errores parecidos a los siguientes:
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.
Cada servidor tiene una opción AllowSynchronousIO
que controla este comportamiento y el valor predeterminado para todos ellos ahora es false
.
El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal. Por ejemplo:
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Si tiene problemas con una elemento TextWriter
u otra secuencia que llama a una API sincrónica en Dispose
, llame a la nueva API de DisposeAsync
en su lugar.
Para obtener información, vea dotnet/aspnetcore#7644.
Versión introducida
3.0
Comportamiento anterior
De manera predeterminada, solo se permitían HttpRequest.Body.Read
, HttpResponse.Body.Write
y Stream.Flush
.
Comportamiento nuevo
Estas API sincrónicas no están permitidas de forma predeterminada:
Se esperan errores parecidos a los siguientes:
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.
Motivo del cambio
Estas API sincrónicas han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación. A partir de ASP.NET Core 3.0, versión preliminar 3, las operaciones sincrónicas están deshabilitadas de forma predeterminada.
Acción recomendada
Use las versiones asincrónicas de los métodos. El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal.
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Categoría
ASP.NET Core
API afectadas
Identidad: se ha quitado la sobrecarga del método AddDefaultUI
A partir de ASP.NET Core 3.0, ya no existe la sobrecarga del método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework).
Versión introducida
3.0
Motivo del cambio
Este cambio fue el resultado de la adopción de la característica de recursos web estáticos.
Acción recomendada
Llame a IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) en lugar de a la sobrecarga que toma dos argumentos. Si usa Bootstrap 3, agregue también la línea siguiente a un elemento <PropertyGroup>
del archivo de proyecto:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
Categoría
ASP.NET Core
API afectadas
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
Identidad: se ha cambiado la versión de Bootstrap predeterminada de la interfaz de usuario
A partir de ASP.NET Core 3.0, la interfaz de usuario de Identity tiene como valor predeterminado el uso de la versión 4 de Bootstrap.
Versión introducida
3.0
Comportamiento anterior
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
era la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
.
Comportamiento nuevo
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
es la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
.
Motivo del cambio
Bootstrap 4 se lanzó durante el periodo de tiempo de ASP.NET Core 3.0.
Acción recomendada
En el caso de que use la interfaz de usuario predeterminada de Identity y la haya agregado en Startup.ConfigureServices
, este cambio le afectará, como se muestra en el ejemplo siguiente:
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
Realice una de las siguientes acciones:
Migre su aplicación para usar Bootstrap 4 usando la guía de migración.
Actualice
Startup.ConfigureServices
para forzar el uso de Bootstrap 3. Por ejemplo:services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
Categoría
ASP.NET Core
API afectadas
None
Identidad: SignInAsync produce una excepción para la identidad no autenticada
De forma predeterminada, SignInAsync
produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated
es false
.
Versión introducida
3.0
Comportamiento anterior
SignInAsync
acepta entidades de seguridad e identidades, incluidas las identidades en las que IsAuthenticated
es false
.
Comportamiento nuevo
De forma predeterminada, SignInAsync
produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated
es false
. Hay una nueva marca para suprimir este comportamiento, pero el comportamiento predeterminado ha cambiado.
Motivo del cambio
El comportamiento anterior era problemático porque, de forma predeterminada, [Authorize]
/ RequireAuthenticatedUser()
rechazó estas entidades de seguridad.
Acción recomendada
En ASP.NET Core 3.0, versión preliminar 6, hay una marca de RequireAuthenticatedSignIn
en AuthenticationOptions
que es true
de forma predeterminada. Establezca esta marca en false
para restaurar el comportamiento anterior.
Categoría
ASP.NET Core
API afectadas
None
Identidad: el constructor SignInManager acepta un nuevo parámetro
A partir de ASP.NET Core 3.0, se ha agregado un nuevo parámetro IUserConfirmation<TUser>
al constructor SignInManager
. Para obtener más información, consulte dotnet/aspnetcore#8356.
Versión introducida
3.0
Motivo del cambio
La motivación del cambio consistió en agregar compatibilidad con nuevos flujos de correo electrónico o de confirmación en Identity.
Acción recomendada
Si crea manualmente un elemento SignInManager
, proporcione una implementación de IUserConfirmation
o capte una de la inserción de dependencias que se va a proporcionar.
Categoría
ASP.NET Core
API afectadas
Identidad: la interfaz de usuario usa la característica de recursos web estáticos
ASP.NET Core 3.0 ha presentado una característica de recursos web estáticos y la interfaz de usuario de Identity la ha adoptado.
Descripción del cambio
Como resultado de la interfaz de usuario de Identity que adopta la característica de recursos web estáticos:
- La selección del marco se realiza mediante el uso de la propiedad
IdentityUIFrameworkVersion
en el archivo del proyecto. - Bootstrap 4 es el marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity. Bootstrap 3 ha alcanzado el final del ciclo de vida y debe considerar la posibilidad de migrar a una versión compatible.
Versión introducida
3.0
Comportamiento anterior
El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity era Bootstrap 3. El marco de la interfaz de usuario se puede configurar mediante un parámetro para la llamada al método AddDefaultUI
en Startup.ConfigureServices
.
Comportamiento nuevo
El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity es Bootstrap 4. El marco de la interfaz de usuario debe configurarse en el archivo del proyecto, en lugar de en la llamada al método AddDefaultUI
.
Motivo del cambio
La adopción de la característica de recursos web estáticos requiere que la configuración del marco de la interfaz de usuario se mueva a MSBuild. La decisión sobre qué marco se debe insertar es una decisión en tiempo de compilación, no una decisión en runtime.
Acción recomendada
Revise la interfaz de usuario del sitio para garantizar que los nuevos componentes de Bootstrap 4 son compatibles. En caso necesario, use la propiedad IdentityUIFrameworkVersion
de MSBuild para revertir a Bootstrap 3. Agregue la propiedad a un elemento <PropertyGroup>
en el archivo del proyecto:
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
Categoría
ASP.NET Core
API afectadas
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
Kestrel: se han quitado los adaptadores de conexión
Como parte de la migración de las API de "pubternal" a public
, se ha quitado de Kestrel el concepto de un elemento IConnectionAdapter
. Los adaptadores de conexión se han reemplazado por el middleware de conexión, que es similar al middleware HTTP en la canalización de ASP.NET Core, pero para conexiones de nivel inferior. HTTPS y el registro de conexiones se han movido de los adaptadores de conexión al middleware de conexión. Estos métodos de extensión deberían seguir funcionando sin problemas, pero los detalles de implementación han cambiado.
Para obtener más información, vea dotnet/aspnetcore#11412. Para obtener información, vea dotnet/aspnetcore#11475.
Versión introducida
3.0
Comportamiento anterior
Los componentes de extensibilidad de Kestrel se creaban mediante el uso de IConnectionAdapter
.
Comportamiento nuevo
Los componentes de extensibilidad de Kestrel se crean como middleware.
Motivo del cambio
Este cambio está pensado para proporcionar una arquitectura de extensibilidad más flexible.
Acción recomendada
Convierta las implementaciones de IConnectionAdapter
para usar el nuevo patrón de middleware, tal como se muestra aquí.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Kestrel: se ha quitado un ensamblado HTTPS vacío
Se ha quitado el ensamblado Microsoft.AspNetCore.Server.Kestrel.Https.
Versión introducida
3.0
Motivo del cambio
En ASP.NET Core 2.1, el contenido de Microsoft.AspNetCore.Server.Kestrel.Https
se ha movido a Microsoft.AspNetCore.Server.Kestrel.Core. Este cambio se realizado de forma no interrumpida mediante el uso de atributos de [TypeForwardedTo]
.
Acción recomendada
- Las bibliotecas que hacen referencia a
Microsoft.AspNetCore.Server.Kestrel.Https
2.0 deben actualizar todas las dependencias de ASP.NET Core a 2.1 o una versión posterior. De lo contrario, se pueden interrumpir cuando se cargan en una aplicación ASP.NET Core 3.0. - Las aplicaciones y bibliotecas que tienen como destino ASP.NET Core 2.1 y versiones posteriores deben quitar las referencias directas al paquete NuGet
Microsoft.AspNetCore.Server.Kestrel.Https
.
Categoría
ASP.NET Core
API afectadas
None
Kestrel: se han movido los encabezados de finalizador de solicitud a una nueva recopilación
En versiones anteriores, Kestrel agregaba encabezados de finalizador fragmentados de HTTP/1.1 en la recopilación de encabezados de solicitud cuando el cuerpo de la solicitud se leía al final. Este comportamiento provocó problemas de ambigüedad entre encabezados y finalizadores. Se tomó la decisión de mover los finalizadores a una nueva recopilación.
Los finalizadores de solicitudes HTTP/2 no estaban disponibles en ASP.NET Core 2.2, pero ahora también están disponibles en esta nueva recopilación en ASP.NET Core 3.0.
Se han agregado métodos nuevos de extensión de solicitud para tener acceso a estos finalizadores.
Los finalizadores de HTTP/1.1 están disponibles una vez que se ha leído todo el cuerpo de la solicitud.
Los finalizadores de HTTP/2 están disponibles una vez que se han recibido del cliente. El cliente no enviará los finalizadores hasta que el servidor haya almacenado en búfer como mínimo el cuerpo de la solicitud completo. Es posible que deba leer el cuerpo de la solicitud para liberar espacio en búfer. Los finalizadores siempre están disponibles si lee el cuerpo de la solicitud hasta el final. Los finalizadores marcan el final del cuerpo.
Versión introducida
3.0
Comportamiento anterior
Los encabezados de finalizador de solicitud se agregarán a la recopilación HttpRequest.Headers
.
Comportamiento nuevo
Los encabezados de finalizador de solicitud no están presentes en la recopilación HttpRequest.Headers
. Use los métodos de extensión siguientes en HttpRequest
para tener acceso a ellos:
GetDeclaredTrailers()
: obtiene el encabezado de "finalizador" de la solicitud que muestra los finalizadores que se esperan después del cuerpo.SupportsTrailers()
: indica si la solicitud admite la recepción de encabezados de finalizador.CheckTrailersAvailable()
: determina si la solicitud admite finalizadores y si están disponible para lectura.GetTrailer(string trailerName)
: obtiene el encabezado de finalización solicitado de la respuesta.
Motivo del cambio
Los finalizadores son una característica clave en escenarios como gRPC. Combinar los finalizadores en los encabezados de solicitud ha sido confuso para los usuarios.
Acción recomendada
Use los métodos de extensión relacionados con el finalizador en HttpRequest
para tener acceso a los finalizadores.
Categoría
ASP.NET Core
API afectadas
Kestrel: las abstracciones de transporte se han quitado y se han hecho públicas
Como parte del desplazamiento de las API de "pubternal", las API de la capa de transporte de Kestrel se exponen como una interfaz pública en la biblioteca de Microsoft.AspNetCore.Connections.Abstractions
.
Versión introducida
3.0
Comportamiento anterior
- Las abstracciones relacionadas con el transporte estaban disponibles en la biblioteca de
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
. - La propiedad
ListenOptions.NoDelay
estaba disponible.
Comportamiento nuevo
- La interfaz de
IConnectionListener
se presentaba en la biblioteca deMicrosoft.AspNetCore.Connections.Abstractions
para exponer la funcionalidad más usada de la biblioteca de...Transport.Abstractions
. NoDelay
está ahora disponible en opciones de transporte (LibuvTransportOptions
ySocketTransportOptions
).SchedulingMode
ya no está disponible.
Motivo del cambio
ASP.NET Core 3.0 se ha desplazado de las API de "pubternal".
Acción recomendada
Categoría
ASP.NET Core
API afectadas
None
Localización: ResourceManagerWithCultureStringLocalizer y WithCulture se han marcado como obsoletos
La clase ResourceManagerWithCultureStringLocalizer y el miembro de interfaz WithCulture suelen ser fuentes de confusión para los usuarios de localización, en particular al crear su propia implementación de IStringLocalizer
. Estos elementos proporcionan al usuario la impresión de que una instancia de IStringLocalizer
es "por lenguaje y por recurso". En realidad, las instancias solo deben ser "por recurso". El lenguaje que se busca lo determina el CultureInfo.CurrentUICulture
en tiempo de ejecución. Para eliminar el origen de confusión, las API se marcaron como obsoletas en ASP.NET Core 3.0. Las API se quitarán en una versión futura.
Para obtener el contexto, consulte dotnet/aspnetcore#3324. Para obtener información, vea dotnet/aspnetcore#7756.
Versión introducida
3.0
Comportamiento anterior
Los métodos no se marcaban como Obsolete
.
Comportamiento nuevo
Los métodos se marcan como Obsolete
.
Motivo del cambio
Las API representan un caso de uso que no se recomienda. Ha habido confusión sobre el diseño de la localización.
Acción recomendada
La recomendación es usar ResourceManagerStringLocalizer
en su lugar. Permita que CurrentCulture
establezca la referencia cultural. Si no es una opción, cree y use una copia de ResourceManagerWithCultureStringLocalizer.
Categoría
ASP.NET Core
API afectadas
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Registro: la clase DebugLogger se ha convertido en interna
Antes de ASP.NET Core 3.0, el modificador de acceso de DebugLogger
era public
. En ASP.NET Core 3.0, el modificador de acceso se ha cambiado a internal
.
Versión introducida
3.0
Motivo del cambio
El cambio se realiza para:
- Aplicar la coherencia con otras implementaciones de registrador como
ConsoleLogger
. - Reducir la superficie de la API.
Acción recomendada
Use el método de extensión AddDebug de ILoggingBuilder
para habilitar el registro de depuración. DebugLoggerProvider también sigue siendo public
en caso de que el servicio se tenga que registrar de forma manual.
Categoría
ASP.NET Core
API afectadas
Microsoft.Extensions.Logging.Debug.DebugLogger
MVC: se ha recortado el sufijo Async de los nombres de acción de controlador
Como parte de la solución de dotnet/aspnetcore#4849, en ASP.NET Core MVC se recorta el sufijo Async
de los nombres de acción de forma predeterminada. A partir de ASP.NET Core 3.0, este cambio afecta tanto al enrutamiento como a la generación de vínculos.
Versión introducida
3.0
Comportamiento anterior
Tenga en cuenta el siguiente controlador de ASP.NET Core MVC:
public class ProductController : Controller
{
public async IActionResult ListAsync()
{
var model = await DbContext.Products.ToListAsync();
return View(model);
}
}
La acción es enrutable mediante Product/ListAsync
. La generación de vínculos requiere que se especifique el sufijo Async
. Por ejemplo:
<a asp-controller="Product" asp-action="ListAsync">List</a>
Comportamiento nuevo
En ASP.NET Core 3.0, la acción es enrutable mediante Product/List
. El código de generación de vínculos debe omitir el sufijo Async
. Por ejemplo:
<a asp-controller="Product" asp-action="List">List</a>
Este cambio no afecta a los nombres especificados mediante el atributo [ActionName]
. El nuevo comportamiento se puede deshabilitar si se establece MvcOptions.SuppressAsyncSuffixInActionNames
en false
en Startup.ConfigureServices
:
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Motivo del cambio
Por convención, los métodos asincrónicos de .NET tienen el sufijo Async
. Pero cuando un método define una acción de MVC, no es recomendable usar el sufijo Async
.
Acción recomendada
Si la aplicación depende de que las acciones de MVC conserven el sufijo Async
del nombre, elija una de las mitigaciones siguientes:
- Use el atributo
[ActionName]
para conservar el nombre original. - Establezca
MvcOptions.SuppressAsyncSuffixInActionNames
enfalse
enStartup.ConfigureServices
para deshabilitar totalmente el cambio de nombre:
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Categoría
ASP.NET Core
API afectadas
None
MVC: JsonResult se ha trasladado a Microsoft.AspNetCore.Mvc.Core
JsonResult
se ha trasladado al ensamblado Microsoft.AspNetCore.Mvc.Core
. Este tipo se ha usado para definirse en Microsoft.AspNetCore.Mvc.Formatters.Json. Se ha agregado un atributo [TypeForwardedTo] de nivel de ensamblado a Microsoft.AspNetCore.Mvc.Formatters.Json
para solucionar este problema en la mayoría de los usuarios. Las aplicaciones que usan bibliotecas de terceros pueden encontrar problemas.
Versión introducida
3.0 Preview 6
Comportamiento anterior
Una aplicación que usa una biblioteca basada en la versión 2.2 se compila correctamente.
Comportamiento nuevo
Una aplicación que usa una biblioteca basada en la versión 2.2 produce un error en la compilación. Se proporciona un error que contiene una variación del texto siguiente:
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'
Para obtener un ejemplo de este tipo de problema, consulte dotnet/aspnetcore#7220.
Motivo del cambio
Los cambios en el nivel de plataforma de la composición de ASP.NET Core como se describe en aspnet/Announcements#325.
Acción recomendada
Es posible que sea necesario volver a compilar las bibliotecas compiladas con la versión 2.2 de Microsoft.AspNetCore.Mvc.Formatters.Json
para solucionar el problema de todos los consumidores. Si se ve afectado, póngase en contacto con el autor de la biblioteca. Solicite volver a compilar la biblioteca para tener como destino ASP.NET Core 3.0.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.JsonResult
MVC: herramienta de precompilación en desuso
En ASP.NET Core 1.1, se presentó el paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
(herramienta de precompilación MVC) para agregar compatibilidad con la compilación en tiempo de publicación de archivos Razor (archivos .cshtml). En ASP.NET Core 2.1, se presentó el SDK de Razor para ampliar las características de la herramienta de precompilación. El SDK de Razor agregaba compatibilidad con los archivos Razor en tiempo de compilación y publicación. El SDK comprueba la exactitud de los archivos .cshtml en tiempo de compilación mientras mejora el tiempo de inicio de la aplicación. El SDK de Razor está activado de forma predeterminada y no se requiere ningún gesto para empezar a usarlo.
En ASP.NET Core 3.0, se quitó la herramienta de precompilación MVC de ASP.NET Core 1.1. Las versiones anteriores del paquete seguirán recibiendo correcciones de seguridad y de errores importantes en la versión de revisión.
Versión introducida
3.0
Comportamiento anterior
El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
se usaba para compilar previamente las vistas de Razor de MVC.
Comportamiento nuevo
El SDK de Razor es compatible de forma nativa con esta funcionalidad. El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
ya no está actualizado.
Motivo del cambio
El SDK de Razor proporciona más funcionalidad y comprueba la exactitud de los archivos .cshtml en tiempo de compilación. El SDK también mejora el tiempo de inicio de la aplicación.
Acción recomendada
Para los usuarios de ASP.NET Core 2.1 o versiones posteriores, actualice para usar la compatibilidad nativa con la precompilación en el SDK de Razor. Si los errores o las características que faltan impiden la migración al SDK de Razor, abra una incidencia en dotnet/aspnetcore.
Categoría
ASP.NET Core
API afectadas
None
MVC: los tipos "pubternal" se han cambiado a internal
En ASP.NET Core 3.0, todos los tipos "pubternal" de MVC se actualizaron para ser public
en un espacio de nombres compatible o internal
, según correspondiera.
Descripción del cambio
In ASP.NET Core, los tipos "pubternal" se declaran como public
pero residen en un espacio de nombres con un sufijo .Internal
. Aunque estos tipos son public
, no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Versión introducida
3.0
Comportamiento anterior
Algunos tipos de MVC eran public
pero en un espacio de nombres .Internal
. Estos tipos no tenían ninguna directiva compatible y estaban sujetos a cambios importantes.
Comportamiento nuevo
Todos estos tipos se actualizan para ser public
en un espacio de nombres compatible o que se marquen como internal
.
Motivo del cambio
El uso accidental de los tipos "pubternal" es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.
Acción recomendada
Si usa tipos que se han convertido realmente en public
y se han movido a un nuevo espacio de nombres compatible, actualice las referencias para que coincidan con los espacios de nombres nuevos.
Si utiliza tipos que se han marcado como internal
, deberá buscar una alternativa. Los tipos "pubternal" anteriores nunca se admitieron para uso público. Si hay tipos específicos en estos espacios de nombres que son fundamentales para las aplicaciones, registre una incidencia en dotnet/aspnetcore. Se pueden pensar ideas para hacer los tipos solicitados public
.
Categoría
ASP.NET Core
API afectadas
Este cambio incluye tipos en los espacios de nombres siguientes:
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: se han quitado las correcciones de compatibilidad (shim) con la API web
A partir de ASP.NET Core 3.0, el paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim
ya no está disponible.
Descripción del cambio
El paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim
(WebApiCompatShim) proporciona compatibilidad parcial en ASP.NET Core con ASP.NET 4.x Web API 2 para simplificar la migración de implementaciones existentes de API web a ASP.NET Core. Pero las aplicaciones que usan WebApiCompatShim no se benefician de las características relacionadas con la API que se distribuyen en versiones recientes de ASP.NET Core. Estas características incluyen la generación mejorada de especificaciones de Open API, el control de errores estandarizado y la generación de código de cliente. Para centrar mejor los esfuerzos de API en la versión 3.0, se ha quitado WebApiCompatShim. Las aplicaciones existentes en las que se usa WebApiCompatShim se deben migrar al modelo de [ApiController]
más reciente.
Versión introducida
3.0
Motivo del cambio
La corrección de compatibilidad (shim) de la API web era una herramienta de migración. Restringe el acceso de los usuarios a la nueva funcionalidad agregada en ASP.NET Core.
Acción recomendada
Quite el uso de esta corrección de compatibilidad y migre directamente a la funcionalidad similar en ASP.NET Core.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.WebApiCompatShim
Razor: API RazorTemplateEngine eliminada
Se ha quitado la API RazorTemplateEngine
y se ha reemplazado por Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
.
Para obtener información, vea la incidencia de GitHub dotnet/aspnetcore#25215.
Versión introducida
3.0
Comportamiento anterior
Un motor de plantillas se puede crear y usar para analizar y generar código para archivos de Razor.
Comportamiento nuevo
Se puede crear RazorProjectEngine
y se le puede proporcionar el mismo tipo de información que a RazorTemplateEngine
para analizar y generar código para archivos de Razor. RazorProjectEngine
también proporciona niveles de configuración adicionales.
Motivo del cambio
RazorTemplateEngine
estaba demasiado acoplado a las implementaciones existentes. Este acoplamiento tan estrecho daba lugar a más preguntas al intentar configurar correctamente una canalización de análisis y generación de Razor.
Acción recomendada
Use RazorProjectEngine
en lugar de RazorTemplateEngine
. Considere los ejemplos siguientes.
Creación y configuración de 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
});
Generación de código para un archivo de 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();
Categoría
ASP.NET Core
API afectadas
RazorTemplateEngine
RazorTemplateEngineOptions
Razor: la compilación en tiempo de ejecución se ha movido a un paquete
La compatibilidad con la compilación en entorno de ejecución de las vistas de Razor y Razor Pages se ha movido a un paquete independiente.
Versión introducida
3.0
Comportamiento anterior
La compilación en entorno de ejecución está disponible sin necesidad de paquetes adicionales.
Comportamiento nuevo
La funcionalidad se ha pasado al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.
Las siguientes API estaban disponibles anteriormente en Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
para admitir la compilación en entorno de ejecución. Las API ahora están disponibles mediante Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions
.
RazorViewEngineOptions.FileProviders
ahora esMvcRazorRuntimeCompilationOptions.FileProviders
RazorViewEngineOptions.AdditionalCompilationReferences
ahora esMvcRazorRuntimeCompilationOptions.AdditionalReferencePaths
Además, se ha quitado Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange
. La recompilación en los cambios de archivo está habilitada de forma predeterminada al hacer referencia al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
.
Motivo del cambio
Este cambio era necesario para quitar la dependencia de marco compartido de ASP.NET Core en Roslyn.
Acción recomendada
Las aplicaciones que requieren la compilación o recompilación en entorno de ejecución de archivos Razor deben realizar los pasos siguientes:
Agregar una referencia al paquete
Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
.Actualizar el método
Startup.ConfigureServices
del proyecto para incluir una llamada aAddRazorRuntimeCompilation
. Por ejemplo:services.AddMvc() .AddRazorRuntimeCompilation();
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Estado de sesión: se han quitado las API obsoletas
Se han quitado las API obsoletas para configurar las cookies de sesión. Para obtener más información, consulte aspnet/Announcements#257.
Versión introducida
3.0
Motivo del cambio
Este cambio exige coherencia entre las API para configurar las características que usan cookies.
Acción recomendada
Migre el uso de las API quitadas a sus reemplazos más recientes. Considere el ejemplo siguiente de 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;
});
}
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Builder.SessionOptions.CookieDomain
- Microsoft.AspNetCore.Builder.SessionOptions.CookieHttpOnly
- Microsoft.AspNetCore.Builder.SessionOptions.CookieName
- Microsoft.AspNetCore.Builder.SessionOptions.CookiePath
- Microsoft.AspNetCore.Builder.SessionOptions.CookieSecure
Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.App
A partir de ASP.NET Core 3.0, el marco compartido de ASP.NET Core (Microsoft.AspNetCore.App
) solo contiene ensamblados propios totalmente desarrollados, admitidos y mantenidos por Microsoft.
Descripción del cambio
Considere el cambio como la redefinición de los límites de la "plataforma" ASP.NET. A través de GitHub, cualquier usuario puede compilar el código fuente del marco compartido y seguirá ofreciendo a las aplicaciones las ventajas existentes de los marcos compartidos de .NET Core. Algunas ventajas son el tamaño de implementación más pequeño, la revisión centralizada y el tiempo de inicio más rápido.
Como parte del cambio, en Microsoft.AspNetCore.App
se han introducido algunos cambios importantes.
Versión introducida
3.0
Comportamiento anterior
Los proyectos hacían referencia a Microsoft.AspNetCore.App
mediante un elemento <PackageReference>
en el archivo de proyecto.
Además, Microsoft.AspNetCore.App
incluía los subcomponentes siguientes:
- Json.NET (
Newtonsoft.Json
) - Entity Framework Core (ensamblados con el prefijo
Microsoft.EntityFrameworkCore.
) - Roslyn (
Microsoft.CodeAnalysis
)
Comportamiento nuevo
Una referencia a Microsoft.AspNetCore.App
ya no requiere un elemento <PackageReference>
en el archivo de proyecto. El SDK de .NET Core admite un nuevo elemento denominado <FrameworkReference>
, que reemplaza el uso de <PackageReference>
.
Para obtener más información, vea dotnet/aspnetcore#3612.
Entity Framework Core se distribuye como paquetes NuGet. Este cambio alinea el modelo de envío con el resto de las bibliotecas de acceso a datos de .NET. Proporciona a Entity Framework Core la ruta más sencilla para continuar con la innovación al tiempo que admite las distintas plataformas .NET. La exclusión de Entity Framework Core del marco compartido no tiene ningún impacto en su estado como biblioteca desarrollada, admitida y mantenida por Microsoft. Continúa bajo la cobertura de la directiva de compatibilidad de .NET Core.
Json.NET y Entity Framework Core siguen funcionando con ASP.NET Core. Pero no se incluirán en el marco compartido.
Para obtener más información, vea El futuro de JSON en .NET Core 3.0. Vea también la lista completa de archivos binarios que se han quitado del marco compartido.
Motivo del cambio
Este cambio simplifica el consumo de Microsoft.AspNetCore.App
y reduce la duplicación entre paquetes NuGet y marcos compartidos.
Para obtener más información sobre la motivación de este cambio, vea esta entrada de blog.
Acción recomendada
A partir de ASP.NET Core 3.0, ya no es necesario que los proyectos consuman ensamblados en Microsoft.AspNetCore.App
como paquetes NuGet. Para simplificar la selección como destino y el uso del marco compartido de ASP.NET Core, ya no se generan muchos paquetes NuGet enviados desde ASP.NET Core 1.0. Las API que proporcionan esos paquetes siguen estando disponibles para las aplicaciones mediante el uso de un elemento <FrameworkReference>
para Microsoft.AspNetCore.App
. Entre los ejemplos de API comunes se incluyen Kestrel, MVC y Razor.
Este cambio no se aplica a todos los archivos binarios a los que se hace referencia a través de Microsoft.AspNetCore.App
en ASP.NET Core 2.x. Entre las excepciones destacables se incluyen las siguientes:
- Las bibliotecas de
Microsoft.Extensions
que todavía tienen .NET Standard como destino están disponibles como paquetes NuGet (vea https://github.com/dotnet/extensions). - API generadas por el equipo de ASP.NET Core que no forman parte de
Microsoft.AspNetCore.App
. Por ejemplo, los componentes siguientes están disponibles como paquetes NuGet:- Entity Framework Core
- API que proporcionan integración de terceros
- Características experimentales
- API con dependencias que no han podido cumplir los requisitos para ser incluidas en el marco compartido
- Extensiones para MVC que mantienen la compatibilidad con Json.NET. Se proporciona una API como paquete NuGet para admitir el uso de Json.NET y MVC. Consulte la guía de migración de ASP.NET Core para obtener más detalles.
- El cliente .NET de SignalR mantiene la compatibilidad con .NET Standard y se incluye como paquete NuGet. Está diseñado para usarse en muchos entornos de ejecución de .NET, como Xamarin y UWP.
Para obtener más información, vea Detección de la generación de paquetes para ensamblados de marco compartido en 3.0. Para obtener información, vea dotnet/aspnetcore#3757.
Categoría
ASP.NET Core
API afectadas
Marco compartido: se ha eliminado Microsoft.AspNetCore.All
A partir de ASP.NET Core 3.0, ya no se generan el metapaquete Microsoft.AspNetCore.All
y el marco compartido Microsoft.AspNetCore.All
correspondiente. Este paquete está disponible en ASP.NET Core 2.2 y seguirá recibiendo actualizaciones de mantenimiento en ASP.NET Core 2.1.
Versión introducida
3.0
Comportamiento anterior
Las aplicaciones podían usar el metapaquete Microsoft.AspNetCore.All
para seleccionar como destino el marco compartido Microsoft.AspNetCore.All
en .NET Core.
Comportamiento nuevo
En .NET Core 3.0 no se incluye un marco compartido Microsoft.AspNetCore.All
.
Motivo del cambio
En el metapaquete Microsoft.AspNetCore.All
se incluía un gran número de dependencias externas.
Acción recomendada
Migre el proyecto para usar el marco Microsoft.AspNetCore.App
. Los componentes que anteriormente estaban disponibles en Microsoft.AspNetCore.All
lo siguen estando en NuGet. Ahora esos componentes se implementan con la aplicación en lugar de incluirse en el marco compartido.
Categoría
ASP.NET Core
API afectadas
None
SignalR: se ha reemplazado HandshakeProtocol.SuccessHandshakeData
El campo HandshakeProtocol.SuccessHandshakeData se ha quitado y se ha reemplazado por un método auxiliar que genera una respuesta de protocolo de enlace correcta dado un protocolo IHubProtocol
específico.
Versión introducida
3.0
Comportamiento anterior
HandshakeProtocol.SuccessHandshakeData
era un campo public static ReadOnlyMemory<byte>
.
Comportamiento nuevo
HandshakeProtocol.SuccessHandshakeData
se ha reemplazado por un método GetSuccessfulHandshake(IHubProtocol protocol)
static
que devuelve un objeto ReadOnlyMemory<byte>
basado en el protocolo especificado.
Motivo del cambio
Se han agregado campos adicionales a la respuesta del protocolo de enlace que no son constantes y cambian en función del protocolo seleccionado.
Acción recomendada
Ninguno. Este tipo no está diseñado para su uso desde el código de usuario. Es public
, por lo que se puede compartir entre el servidor de SignalR y el cliente. También lo pueden usar clientes de SignalR personalizados escritos en .NET. Los usuarios de SignalR no deberían verse afectados por este cambio.
Categoría
ASP.NET Core
API afectadas
HandshakeProtocol.SuccessHandshakeData
SignalR: se han quitado los métodos ResetSendPing y ResetTimeout de HubConnection
Los métodos ResetSendPing
y ResetTimeout
se han quitado de la API HubConnection
de SignalR. Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2. Estos métodos no estarán disponibles a partir de ASP.NET Core 3.0, versión preliminar 4. Para obtener información, vea dotnet/aspnetcore#8543.
Versión introducida
3.0
Comportamiento anterior
Las API estaban disponibles.
Comportamiento nuevo
Las API se quitan.
Motivo del cambio
Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2.
Acción recomendada
No use estos métodos.
Categoría
ASP.NET Core
API afectadas
SignalR: se han cambiado los constructores de HubConnectionContext
Los constructores de HubConnectionContext
de SignalR han cambiado para aceptar un tipo de opciones, en lugar de varios parámetros, para agregar opciones con garantía de futuro. Este cambio reemplaza dos constructores por un único constructor que acepta un tipo de opciones.
Versión introducida
3.0
Comportamiento anterior
HubConnectionContext
tiene dos constructores:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
Comportamiento nuevo
Los dos constructores se han quitado y se han reemplazado por uno:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
Motivo del cambio
El nuevo constructor usa un nuevo objeto de opciones. Por tanto, las características de HubConnectionContext
se pueden expandir en el futuro sin crear más constructores y cambios importantes.
Acción recomendada
En lugar de usar el constructor siguiente:
HubConnectionContext connectionContext = new HubConnectionContext(
connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Use el constructor siguiente:
HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);
Categoría
ASP.NET Core
API afectadas
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory)
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory, TimeSpan)
SignalR: se ha cambiado el nombre del paquete de cliente de JavaScript
En ASP.NET Core 3.0, versión preliminar 7, el nombre del paquete de cliente de JavaScript de SignalR ha cambiado de @aspnet/signalr
a @microsoft/signalr
. El cambio de nombre refleja el hecho de que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.
Para reaccionar a este cambio, cambie las referencias en los archivos package.json, las instrucciones require
y las instrucciones import
de ECMAScript. No se cambiará ninguna API como parte de este cambio de nombre.
Para obtener información, vea dotnet/aspnetcore#11637.
Versión introducida
3.0
Comportamiento anterior
El paquete de cliente se llamaba @aspnet/signalr
.
Comportamiento nuevo
El paquete de cliente se llama @microsoft/signalr
.
Motivo del cambio
El cambio de nombre clarifica que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.
Acción recomendada
Cambie al paquete @microsoft/signalr
nuevo.
Categoría
ASP.NET Core
API afectadas
None
SignalR: los métodos UseSignalR y UseConnections se han marcado como obsoletos
Los métodos UseConnections
y UseSignalR
, y las clases ConnectionsRouteBuilder
y HubRouteBuilder
están marcados como obsoletos en ASP.NET Core 3.0.
Versión introducida
3.0
Comportamiento anterior
El enrutamiento del centro de conectividad de SignalR se configuraba mediante UseSignalR
o UseConnections
.
Comportamiento nuevo
La forma antigua de configurar el enrutamiento ha quedado obsoleta y se ha reemplazado por el enrutamiento del punto de conexión.
Motivo del cambio
El middleware se está trasladando al sistema de enrutamiento nuevo de puntos de conexión. La forma anterior de agregar middleware está obsoleta.
Acción recomendada
Reemplace UseSignalR
por UseEndpoints
:
Código anterior:
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Código nuevo:
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
Categoría
ASP.NET Core
API afectadas
- Microsoft.AspNetCore.Builder.ConnectionsAppBuilderExtensions.UseConnections(IApplicationBuilder, Action<ConnectionsRouteBuilder>)
- Microsoft.AspNetCore.Builder.SignalRAppBuilderExtensions.UseSignalR(IApplicationBuilder, Action<HubRouteBuilder>)
- Microsoft.AspNetCore.Http.Connections.ConnectionsRouteBuilder
- Microsoft.AspNetCore.SignalR.HubRouteBuilder
SPA: SpaServices y NodeServices se han marcado como obsoletos
El contenido de los siguientes paquetes NuGet no es necesario a partir de ASP.NET Core 2.1. Por lo tanto, los paquetes siguientes se marcan como obsoletos:
Por el mismo motivo, los módulos siguientes npm se han marcado como en desuso:
Los paquetes y módulos npm anteriores se quitarán más adelante en .NET 5.
Versión introducida
3.0
Comportamiento anterior
Los paquetes y módulos npm en desuso se diseñaron para integrar ASP.NET Core con varios marcos de aplicación de página única (SPA). Estos marcos incluyen React, and React con Redux.
Comportamiento nuevo
Existe un nuevo mecanismo de integración en el paquete de NuGet Microsoft.AspNetCore.SpaServices.Extensions. El paquete sigue siendo la base de las plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.
Motivo del cambio
ASP.NET Core admite la integración con varios marcos de aplicación de página única (SPA), como Angular, React y React con Redux. Inicialmente, la integración con estos marcos se logró con componentes específicos de ASP.NET Core que administraban escenarios como la representación previa y la integración del lado servidor con Webpack. Con el paso del tiempo, los estándares del sector cambiaron. Cada uno de los marcos de SPA lanzó sus propias interfaces de línea de comandos estándar. Por ejemplo, la CLI de Angular y create-react-app.
Cuando se publicó ASP.NET Core 2.1 en mayo de 2018, el equipo respondió al cambio en los estándares. Se proporcionó una manera más nueva y sencilla de integrarse con las cadenas de herramientas propias de los marcos de SPA. El nuevo mecanismo de integración existe en el paquete Microsoft.AspNetCore.SpaServices.Extensions
y sigue siendo la base de las plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.
Para aclarar que los componentes específicos de ASP.NET Core antiguos son irrelevantes y no se recomiendan, se realizan las acciones siguientes:
- El mecanismo de integración anterior a la versión 2.1 está marcado como obsoleto.
- Los paquetes npm compatibles se marcan como en desuso.
Acción recomendada
Si usa estos paquetes, actualice las aplicaciones para usar la funcionalidad:
- En el paquete
Microsoft.AspNetCore.SpaServices.Extensions
. - Que proporcionan los marcos de SPA que está usando.
Para habilitar características como la representación previa del lado servidor y la recarga de módulos frecuentes, consulte la documentación del marco de SPA correspondiente. La funcionalidad de Microsoft.AspNetCore.SpaServices.Extensions
no está obsoleta y seguirá siendo compatible.
Categoría
ASP.NET Core
API afectadas
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
SPA: SpaServices y NodeServices ya no vuelven al registrador de la consola
Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.
Versión introducida
3.0
Comportamiento anterior
Antes, Microsoft.AspNetCore.SpaServices
y Microsoft.AspNetCore.NodeServices
creaban de forma automática un registrador de consola cuando el registro no estaba configurado.
Comportamiento nuevo
Microsoft.AspNetCore.SpaServices
y Microsoft.AspNetCore.NodeServices
no mostrarán los registros de la consola a menos que el registro esté configurado.
Motivo del cambio
Existe la necesidad de alinearse con el modo de implementar el registro en otros paquetes de ASP.NET Core.
Acción recomendada
Si se requiere el comportamiento anterior, agregue services.AddLogging(builder => builder.AddConsole())
al método Setup.ConfigureServices
para configurar el registro de la consola.
Categoría
ASP.NET Core
API afectadas
None
Plataforma de destino: se ha quitado la compatibilidad con .NET Framework
A partir de ASP.NET Core 3.0, .NET Framework es un marco de destino que no se admite.
Descripción del cambio
.NET Framework 4.8 es la última versión principal de .NET Framework. Las nuevas aplicaciones de ASP.NET Core se deben compilar en .NET Core. A partir de NET Core 3.0, puede considerar a ASP.NET Core 3.0 una parte de .NET Core.
Los clientes que usen ASP.NET Core con .NET Framework pueden continuar utilizando la versión 2.1 LTS de forma totalmente compatible. La compatibilidad y el servicio para la versión 2.1 continuarán hasta el 21 de agosto de 2021. Esta fecha es tres años posterior a la declaración de la versión LTS de acuerdo a la Directiva de compatibilidad de .NET. La compatibilidad con los paquetes de ASP.NET Core 2.1 en .NET Framework se extenderá indefinidamente, de forma similar a la directiva de servicio para otros marcos de ASP.NET basados en paquetes.
Para más información sobre cómo migrar de .NET Framework a .NET Core, vea Portabilidad a .NET Core.
Los paquetes Microsoft.Extensions
(como el registro, la inserción de dependencias y la configuración) y Entity Framework Core no se ven afectados. Seguirán admitiendo .NET Standard.
Para más información sobre la motivación de este cambio, vea la entrada de blog original.
Versión introducida
3.0
Comportamiento anterior
Las aplicaciones ASP.NET Core se podían ejecutar en .NET Core o .NET Framework.
Comportamiento nuevo
Las aplicaciones ASP.NET Core solo se pueden ejecutar en .NET Core.
Acción recomendada
Realice una de las siguientes acciones:
- Mantenga la aplicación en ASP.NET Core 2.1.
- Migre la aplicación y las dependencias a .NET Core.
Categoría
ASP.NET Core
API afectadas
None
Bibliotecas de Core .NET
- Las API que notifican la versión ahora notifican la versión del producto y no la del archivo
- Las instancias personalizadas de EncoderFallbackBuffer no pueden retroceder de forma recursiva
- Cambios en el comportamientos de formato y análisis de punto flotante
- Las operaciones de análisis de punto flotante ya no producen un error ni una excepción OverflowException
- Se ha movido InvalidAsynchronousStateException a otro ensamblado
- Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode
- Se ha movido TypeDescriptionProviderAttribute a otro ensamblado
- ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes
- FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización
- El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación
Las API que notifican la versión ahora notifican la versión del producto y no la del archivo
Muchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, métodos como Environment.Version y RuntimeInformation.FrameworkDescription, y el cuadro de diálogo de las propiedades del archivo para los ensamblados de .NET Core reflejan la versión del archivo. A partir de .NET Core 3.0, reflejan la versión del producto.
En la ilustración siguiente se muestra la diferencia en la información sobre la versión del ensamblado System.Runtime.dll para .NET Core 2.2 (a la izquierda) y .NET Core 3.0 (a la derecha), tal y como se muestra en los cuadros de diálogo de las propiedades del archivo de Windows Explorer.
Versión introducida
3.0
Acción recomendada
Ninguno. Este cambio debería hacer que la comprobación de la versión sea intuitiva en lugar de difícil de entender.
Categoría
Bibliotecas de Core .NET
API afectadas
No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer
No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer. La implementación de EncoderFallbackBuffer.GetNextChar() debe traducirse en una secuencia de caracteres que se pueda convertir a la codificación de destino. De lo contrario, se produce una excepción.
Descripción del cambio
Durante una operación de transcodificación de caracteres a bytes, el runtime detecta secuencias UTF-16 de formato incorrecto o no convertibles y proporciona esos caracteres al método EncoderFallbackBuffer.Fallback. El método Fallback
determina los caracteres que han de sustituirse por los datos originales no convertibles y estos caracteres se drenan llamando a EncoderFallbackBuffer.GetNextChar en un bucle.
El runtime intenta luego transcodificar estos caracteres de sustitución en la codificación de destino. Si esta operación se realiza correctamente, el runtime continúa con la transcodificación desde donde se quedó en la cadena de entrada original.
Antes, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() pueden devolver secuencias de caracteres que no se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, el runtime vuelve a invocar el método EncoderFallbackBuffer.Fallback con los caracteres de sustitución, esperando que el método EncoderFallbackBuffer.GetNextChar() devuelva una nueva secuencia de sustitución. Este proceso continúa hasta que el runtime ve finalmente una sustitución convertible de formato correcto o hasta que se alcanza un número máximo de repeticiones.
A partir de .NET Core 3.0, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() deben devolver secuencias de caracteres que se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, se produce una ArgumentException. El runtime ya no realizará llamadas recursivas a la instancia de EncoderFallbackBuffer.
Este comportamiento solo se aplica cuando se cumplen las tres condiciones siguientes:
- El runtime detecta una secuencia UTF-16 de formato incorrecto o una secuencia UTF-16 que no se puede convertir en la codificación de destino.
- Se ha especificado un EncoderFallback personalizado.
- El EncoderFallback personalizado intenta sustituir una nueva secuencia UTF-16 con formato incorrecto o no convertible.
Versión introducida
3.0
Acción recomendada
La mayoría de los desarrolladores no tienen que realizar ninguna acción.
Si una aplicación usa un objeto EncoderFallback personalizado con una clase EncoderFallbackBuffer, asegúrese de que la implementación de EncoderFallbackBuffer.Fallback rellena el búfer de reserva con datos UTF-16 de formato correcto que se puedan convertir directamente en la codificación de destino cuando el runtime invoque por primera vez el método Fallback.
Categoría
Bibliotecas de Core .NET
API afectadas
Cambios en los comportamientos de formato y análisis de los números de punto flotante
Los comportamientos de formato y análisis de los números de punto flotante (de los tipos Double y Single) ahora son compatibles con IEEE. Esto garantiza que el comportamiento de los tipos de punto flotante en .NET coincide con el de otros lenguajes compatibles con IEEE. Por ejemplo, double.Parse("SomeLiteral")
siempre debe coincidir con lo que C# genera para double x = SomeLiteral
.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, dar formato con Double.ToString y Single.ToString, y realizar análisis con Double.Parse, Double.TryParse, Single.Parse y Single.TryParse no es compatible con IEEE. Como resultado, no es posible garantizar que un valor realizará todo el proceso con una cadena de formato estándar o personalizado compatible. En algunas entradas, se puede producir un error al intentar analizar un valor con formato y, en otras, el valor analizado no es igual que el valor original.
A partir de .NET Core 3.0, las operaciones de análisis y formato de punto flotante son compatibles con IEEE 754.
En la tabla siguiente se muestran dos fragmentos de código y cómo cambia la salida entre .NET Core2.2 y .NET Core 3.1.
Fragmento de código | Salida en .NET Core 2.2 | Salida en .NET Core 3.1 |
---|---|---|
Console.WriteLine((-0.0).ToString()); |
0 | -0 |
var value = -3.123456789123456789; Console.WriteLine(value == double.Parse(value.ToString())); |
False |
True |
Para obtener más información, vea la entrada de blog Mejoras de formato y análisis de punto flotante en .NET Core 3.0.
Versión introducida
3.0
Acción recomendada
La sección Impacto potencial en el código existente de la entrada de blog Mejoras en el análisis y el formato de los puntos flotantes en .NET Core 3.0 sugiere algunos cambios que puede hacer en su código si desea mantener el comportamiento anterior.
- Para algunas diferencias de formato, puede obtener un comportamiento equivalente al anterior especificando una cadena de formato diferente.
- En el caso de las diferencias de análisis, no hay ningún mecanismo para volver al comportamiento anterior.
Categoría
Bibliotecas de Core .NET
API afectadas
Las operaciones de análisis de punto flotante ya no producen un error o lanzan una excepción OverflowException
Los métodos de análisis de punto flotante ya no lanzan una OverflowException o devuelven false
cuando analizan una cadena cuyo valor numérico está fuera del rango del tipo de punto flotante Single o Double.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, los métodos Double.Parse y Single.Parse lanzan una OverflowException para los valores que se encuentran fuera del rango de su tipo respectivo. Los métodos Double.TryParse y Single.TryParse devuelven false
para las representaciones de cadena de valores numéricos fuera del rango.
A partir de .NET Core 3.0, los métodos Double.Parse, Double.TryParse, Single.Parse y Single.TryParse ya no producen errores al analizar cadenas numéricas fuera del rango. En su lugar, los métodos de análisis de Double devuelven Double.PositiveInfinity para los valores que superan Double.MaxValue y Double.NegativeInfinity para los valores menores que Double.MinValue. Del mismo modo, los métodos de análisis de Single devuelven Single.PositiveInfinity para los valores que superan Single.MaxValue y Single.NegativeInfinity para los valores menores que Single.MinValue.
Este cambio se ha realizado para mejorar el cumplimiento de la norma IEEE 754:2008.
Versión introducida
3.0
Acción recomendada
Este cambio puede afectar al código de alguna de estas dos formas:
El código depende del controlador para que OverflowException se ejecute cuando se produce un desbordamiento. En este caso, debe quitar la instrucción
catch
y colocar cualquier código necesario en una instrucciónIf
que compruebe si Double.IsInfinity o Single.IsInfinity estrue
.El código presupone que los valores de punto flotante no son
Infinity
. En este caso, debe agregar el código necesario para comprobar los valores de punto flotante dePositiveInfinity
yNegativeInfinity
.
Categoría
Bibliotecas de Core .NET
API afectadas
Se ha movido InvalidAsynchronousStateException a otro ensamblado
La clase InvalidAsynchronousStateException se ha movido.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, la clase InvalidAsynchronousStateException se encuentra en el ensamblado System.ComponentModel.TypeConverter.
A partir de .NET Core 3.0, se encuentra en el ensamblado System.ComponentModel.Primitives.
Versión introducida
3.0
Acción recomendada
Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar InvalidAsynchronousStateException mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, actualice el ensamblado al que se hace referencia en la llamada de método para reflejar la nueva ubicación del ensamblado del tipo.
Categoría
Bibliotecas de Core .NET
API afectadas
Ninguno.
Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode
Cuando la clase UTF8Encoding encuentra una secuencia de bytes UTF-8 con formato incorrecto durante una operación de transcodificación de byte a carácter, reemplaza esa secuencia por un carácter "�" (CARÁCTER DE REEMPLAZO DE U+FFFD) en la cadena de salida. .NET Core 3.0 se diferencia de las versiones anteriores de .NET Core y de .NET Framework en que sigue los procedimientos recomendados de Unicode para realizar este reemplazo durante la operación de transcodificación.
Esto forma parte de un trabajo mayor para mejorar el control de UTF-8 en .NET, que los nuevos tipos System.Text.Unicode.Utf8 y System.Text.Rune incluyen. Se asignó una mecánica de control de errores mejorada al tipo UTF8Encoding para que genere una salida coherente con los tipos recién incorporados.
Descripción del cambio
A partir de .NET Core 3.0, al transcodificar bytes en caracteres, la clase UTF8Encoding realiza la sustitución de caracteres en función de los procedimientos recomendados de Unicode. El mecanismo de sustitución que se usa se describe en The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) en el apartado titulado U+FFFD Substitution of Maximal Subparts.
Este comportamiento solo se aplica cuando la secuencia de bytes de entrada contiene datos UTF-8 con formato incorrecto. Además, si la instancia de UTF8Encoding se ha construido con throwOnInvalidBytes: true
, la instancia de UTF8Encoding
continuará produciéndose en una entrada no válida en lugar de realizar el reemplazo de U+FFFD. Para obtener más información sobre el constructor UTF8Encoding
, vea UTF8Encoding(Boolean, Boolean).
En la siguiente tabla se muestra el impacto de este cambio con una entrada de 3 bytes no válida:
Entrada de 3 bytes con formato incorrecto | Salida antes de .NET Core 3.0 | Salida a partir de .NET Core 3.0 |
---|---|---|
[ ED A0 90 ] |
[ FFFD FFFD ] (salida de 2 caracteres) |
[ FFFD FFFD FFFD ] (salida de 3 caracteres) |
La salida de 3 caracteres es la preferida, según la tabla 3-9 del PDF del estándar Unicode vinculado anteriormente.
Versión introducida
3.0
Acción recomendada
No se requiere ninguna acción por parte del desarrollador.
Categoría
Bibliotecas de Core .NET
API afectadas
Se ha movido TypeDescriptionProviderAttribute a otro ensamblado
La clase TypeDescriptionProviderAttribute se ha movido.
Descripción del cambio
En .NET Core 2.2 y en versiones anteriores, la clase TypeDescriptionProviderAttribute se encuentra en el ensamblado System.ComponentModel.TypeConverter.
A partir de .NET Core 3.0, se encuentra en el ensamblado System.ObjectModel.
Versión introducida
3.0
Acción recomendada
Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar el tipo TypeDescriptionProviderAttribute mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, el ensamblado al que se hace referencia en la llamada al método debe actualizarse para reflejar la nueva ubicación del ensamblado del tipo.
Categoría
Windows Forms
API afectadas
Ninguno.
ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes
Los archivos zip muestran tanto el tamaño comprimido como el tamaño no comprimido en el directorio central y en el encabezado local. Los propios datos de entrada también indican su tamaño. En .NET Core 2.2 y versiones anteriores, nunca se comprobó la coherencia de estos valores. A partir de .NET Core 3.0, ahora son.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, ZipArchiveEntry.Open() funciona correctamente aunque el encabezado local no concuerde con el encabezado central del archivo zip. Los datos se descomprimen hasta que se alcanza el final del flujo comprimido, aunque su longitud supere el tamaño de archivo sin comprimir que se muestra en el directorio central/encabezado local.
A partir de .NET Core 3.0, el método ZipArchiveEntry.Open() comprueba que el encabezado local y el encabezado central coinciden en el tamaño comprimido y no comprimido de una entrada. Si no coinciden, el método produce una InvalidDataException si el encabezado local del archivo o el tamaño de la lista de descriptores de datos que no están en desacuerdo con el directorio central del archivo zip. Al leer una entrada, los datos descomprimidos se truncan hasta el tamaño de archivo sin comprimir que se muestra en el encabezado.
Este cambio se realizó para asegurarse de que un ZipArchiveEntryrepresenta correctamente el tamaño de sus datos y que solo se lee esa cantidad de datos.
Versión introducida
3.0
Acción recomendada
Vuelva a empaquetar los archivos ZIP que presentan estos problemas.
Categoría
Bibliotecas de Core .NET
API afectadas
- ZipArchiveEntry.Open()
- ZipFileExtensions.ExtractToDirectory
- ZipFileExtensions.ExtractToFile
- ZipFile.ExtractToDirectory
FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización
A partir de .NET Core 3.0, se produce una excepción si intenta establecer un valor en un campo InitOnly estático al llamar a System.Reflection.FieldInfo.SetValue.
Descripción del cambio
En .NET Framework y en versiones de .NET Core anteriores a la 3.0, podía establecer el valor de un campo estático constante una vez inicializado (readonly en C#) mediante una llamada a System.Reflection.FieldInfo.SetValue. Con todo, al establecer este tipo de campo de esta manera, se producía un comportamiento imprevisible en función de la plataforma de destino y la configuración de optimización.
En .NET Core 3.0 y versiones posteriores, al llamar a SetValue en un campo InitOnly estático, se produce una excepción System.FieldAccessException.
Sugerencia
Un campo InitOnly es uno que solo se puede establecer en el momento en que se declara o en el constructor de la clase contenedora. En otras palabras, es constante después de inicializarse.
Versión introducida
3.0
Acción recomendada
Inicialice los campos InitOnly estáticos en un constructor estático. Esto se aplica a los tipos dinámicos y no dinámicos.
Como alternativa, puede quitar el atributo FieldAttributes.InitOnly del campo y después llamar a FieldInfo.SetValue.
Categoría
Bibliotecas de Core .NET
API afectadas
- FieldInfo.SetValue(Object, Object)
- FieldInfo.SetValue(Object, Object, BindingFlags, Binder, CultureInfo)
El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación
Al llamar a un método de extensión que toma IEnumerable<T>
en un elemento GroupCollection, se debe eliminar la ambigüedad del tipo mediante una conversión.
Descripción del cambio
A partir de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa IEnumerable<KeyValuePair<String,Group>>
, además de los otros tipos que implementa, incluido IEnumerable<Group>
. Esto produce ambigüedad al llamar a un método de extensión que toma un elemento IEnumerable<T>. Si llama a un método de extensión como este en una instancia de GroupCollection, por ejemplo, Enumerable.Count, verá el error del compilador siguiente:
CS1061: "GroupCollection" no contiene una definición para "Count" ni se encuentra ningún método de extensión accesible "Count" que acepte un primer argumento del tipo "GroupCollection" (¿falta una directiva de uso o una referencia de ensamblado?) .
En versiones anteriores de .NET, no había ambigüedad ni ningún error del compilador.
Versión introducida
3.0
Motivo del cambio
Se trató de un cambio importante involuntario. Dado que no es algo nuevo de ahora, no tenemos previsto revertirlo. Además, un cambio de este tipo sería importante en sí mismo.
Acción recomendada
En el caso de instancias de GroupCollection, elimine la ambigüedad de las llamadas a métodos de extensión que aceptan un elemento IEnumerable<T>
con una conversión.
// Without a cast - causes CS1061.
match.Groups.Count(_ => true)
// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);
Categoría
Bibliotecas de Core .NET
API afectadas
Los métodos de extensión que aceptan un elemento IEnumerable<T> se ven afectados. Por ejemplo:
- System.Collections.Immutable.ImmutableArray.ToImmutableArray<TSource>(IEnumerable<TSource>)
- System.Collections.Immutable.ImmutableDictionary.ToImmutableDictionary
- System.Collections.Immutable.ImmutableHashSet.ToImmutableHashSet
- System.Collections.Immutable.ImmutableList.ToImmutableList<TSource>(IEnumerable<TSource>)
- System.Collections.Immutable.ImmutableSortedDictionary.ToImmutableSortedDictionary
- System.Collections.Immutable.ImmutableSortedSet.ToImmutableSortedSet
- System.Data.DataTableExtensions.CopyToDataTable
- Gran parte de los métodos
System.Linq.Enumerable
, por ejemplo, System.Linq.Enumerable.Count - System.Linq.ParallelEnumerable.AsParallel
- System.Linq.Queryable.AsQueryable
Criptografía
- Ya no se admite la sintaxis BEGIN TRUSTED CERTIFICATE en Linux
- EnvelopedCms usa de forma predeterminada el cifrado AES-256
- Ha aumentado el tamaño mínimo de la generación de claves RSAOpenSsl
- .NET Core 3.0 prefiere OpenSSL 1.1.x a OpenSSL 1.0.x
- Transformación del bloque final solo durante el proceso de escritura mediante CryptoStream.Dispose
Ya no se admite la sintaxis "BEGIN TRUSTED CERTIFICATE" en certificados raíz de Linux
Los certificados raíz de Linux y otros sistemas similares a Unix (a excepción de macOS) se pueden presentar de dos formas: el encabezado PEM BEGIN CERTIFICATE
estándar y el encabezado PEM BEGIN TRUSTED CERTIFICATE
específico de OpenSSL. La última sintaxis permite una configuración adicional que ha provocado problemas de compatibilidad con la clase System.Security.Cryptography.X509Certificates.X509Chain de .NET Core. El motor de cadena ya no carga el contenido del certificado raíz BEGIN TRUSTED CERTIFICATE
a partir de .NET Core 3.0.
Descripción del cambio
Anteriormente, las sintaxis BEGIN CERTIFICATE
y BEGIN TRUSTED CERTIFICATE
se usaban para rellenar la lista de confianza raíz. Si se ha usado la sintaxis BEGIN TRUSTED CERTIFICATE
y se han especificado opciones adicionales en el archivo, es posible que X509Chain haya informado de que la confianza de cadena no se permite explícitamente (X509ChainStatusFlags.ExplicitDistrust). Con todo, si el certificado también se había especificado con la sintaxis BEGIN CERTIFICATE
en un archivo cargado anteriormente, se permitía la confianza de cadena.
A partir de .NET Core 3.0, ya no se lee el contenido de BEGIN TRUSTED CERTIFICATE
. Si el certificado no se especifica también mediante una sintaxis BEGIN CERTIFICATE
estándar, X509Chain informa de que la raíz no es de confianza (X509ChainStatusFlags.UntrustedRoot).
Versión introducida
3.0
Acción recomendada
La mayoría de las aplicaciones no se ven afectadas por este cambio, pero las aplicaciones que no pueden ver ambos orígenes del certificado raíz por problemas de permisos pueden experimentar errores inesperados de UntrustedRoot
después de actualizarse.
Muchas distribuciones de Linux escriben certificados raíz en dos ubicaciones: un directorio con un certificado por archivo y una concatenación de un archivo. En algunas distribuciones, el directorio con un certificado por archivo usa la sintaxis BEGIN TRUSTED CERTIFICATE
mientras que la concatenación de archivos usa la sintaxis BEGIN CERTIFICATE
estándar. Asegúrese de que los certificados raíz personalizados se agregan como BEGIN CERTIFICATE
en al menos una de estas ubicaciones y que la aplicación puede leer ambas ubicaciones.
El directorio típico es /etc/ssl/certs/ y el archivo concatenado típico es /etc/ssl/cert.pem. Use el comando openssl version -d
para determinar la raíz específica de la plataforma, que puede ser diferente de /etc/ssl/ . Por ejemplo, en Ubuntu 18.04, el directorio es /usr/lib/ssl/certs/ y el archivo es /usr/lib/ssl/cert.pem. A pesar de esto, /usr/lib/ssl/certs/ es un vínculo simbólico a /etc/ssl/certs/ y /usr/lib/ssl/cert.pem no existe.
$ 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
Categoría
Criptografía
API afectadas
EnvelopedCms utiliza de forma predeterminada el cifrado AES-256
El algoritmo de cifrado simétrico predeterminado que usa EnvelopedCms
ha cambiado de TripleDES a AES-256.
Descripción del cambio
En versiones anteriores, cuando se usa EnvelopedCms para cifrar datos sin especificar un algoritmo de cifrado simétrico a través de una sobrecarga de constructor, los datos se cifran con el algoritmo TripleDES/3DES/3DEA/DES3-EDE.
A partir de .NET Core 3.0 (a través de la versión 4.6.0 del paquete NuGet System.Security.Cryptography.Pkcs), el algoritmo predeterminado se ha cambiado a AES-256 para la modernización de algoritmos y para mejorar la seguridad de opciones predeterminadas. Si el certificado del destinatario de un mensaje tiene una clave pública Diffie-Hellman (no de cliente de empresa), es posible que se produzca un error CryptographicException en la operación de cifrado debido a limitaciones de la plataforma subyacente.
En el siguiente código de ejemplo, los datos se cifran con TripleDES si se ejecutan en .NET Core 2.2 o anterior. Si se ejecutan en .NET Core 3.0 o posterior, se cifran con AES-256.
EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();
Versión introducida
3.0
Acción recomendada
Si el cambio le afecta negativamente, puede restaurar el cifrado TripleDES especificando explícitamente el identificador del algoritmo de cifrado en un constructor de EnvelopedCms que incluya un parámetro del tipo AlgorithmIdentifier, por ejemplo:
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();
Categoría
Criptografía
API afectadas
Ha aumentado el tamaño mínimo de la generación de claves RSAOpenSsl
El tamaño mínimo para generar nuevas claves RSA en Linux ha aumentado de 384 bits a 512 bits.
Descripción del cambio
A partir de .NET Core 3.0, el tamaño mínimo de clave permitido que notifica la propiedad LegalKeySizes
en instancias de RSA desde RSA.Create, RSAOpenSsl y RSACryptoServiceProvider en Linux ha aumentado de 384 a 512.
Por consiguiente, .NET Core 2.2 y versiones anteriores, una llamada de método como RSA.Create(384)
se realiza correctamente. En .NET Core 3.0 y versiones posteriores, la llamada de método RSA.Create(384)
produce una excepción que indica que el tamaño es demasiado pequeño.
Este cambio se realizó porque OpenSSL, que realiza las operaciones criptográficas en Linux, ha aumentado su mínimo entre las versiones 1.0.2 y 1.1.0. .NET Core 3.0 prefiere OpenSSL 1.1. x a 1.0. x, y la versión mínima notificada se elevó para reflejar esta nueva limitación de dependencia más alta.
Versión introducida
3.0
Acción recomendada
Si llama a cualquiera de las API afectadas, asegúrese de que el tamaño de las claves generadas no sea inferior al mínimo del proveedor.
Nota:
El RSA de 384 bits ya se considera inseguro (al igual que el RSA de 512 bits). Las recomendaciones modernas, como NIST Special Publication 800-57 Part 1 Revision 4, sugieren 2048 bits como tamaño mínimo para las claves recién generadas.
Categoría
Criptografía
API afectadas
.NET Core 3.0 prefiere OpenSSL 1.1.x a OpenSSL 1.0.x
.NET Core para Linux, que funciona en varias distribuciones de Linux, puede admitir OpenSSL 1.0.x y OpenSSL 1.1.x. .NET Core 2.1 y .NET Core 2.2 buscan 1.0.x primero y luego recurren a 1.1.x; .NET Core 3.0 busca 1.1.x primero. Este cambio se realizó para agregar compatibilidad con nuevos estándares criptográficos.
Este cambio puede afectar a las bibliotecas o aplicaciones que llevan a cabo la interoperabilidad de la plataforma con los tipos de interoperabilidad específicos de OpenSSL en .NET Core.
Descripción del cambio
En .NET Core 2.2 y versiones anteriores, el runtime prefiere cargar OpenSSL 1.0.x a 1.1.x. Esto significa que los tipos IntPtr y SafeHandle para la interoperabilidad con OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10.
A partir de .NET Core 3.0, el runtime prefiere cargar OpenSSL 1.1.x a OpenSSL 1.0.x, por lo que los tipos IntPtr y SafeHandle para la interoperabilidad con OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1. Por consiguiente, las bibliotecas y aplicaciones que interactúan directamente con OpenSSL pueden tener punteros incompatibles con los valores expuestos en .NET Core cuando se actualiza desde .NET Core 2.1 o.NET Core 2.2.
Versión introducida
3.0
Acción recomendada
Las bibliotecas y aplicaciones que realizan operaciones directas con OpenSSL deben tener cuidado de asegurarse de que usan la misma versión de OpenSSL que el runtime de .NET Core.
Todas las bibliotecas o aplicaciones que usan los valores IntPtr o SafeHandle de los tipos criptográficos de .NET Core directamente con OpenSSL deben comparar la versión de la biblioteca que usan con la nueva propiedad SafeEvpPKeyHandle.OpenSslVersion para asegurarse de que los punteros son compatible.
Categoría
Criptografía
API afectadas
- SafeEvpPKeyHandle
- RSAOpenSsl(IntPtr)
- RSAOpenSsl(SafeEvpPKeyHandle)
- RSAOpenSsl.DuplicateKeyHandle()
- DSAOpenSsl(IntPtr)
- DSAOpenSsl(SafeEvpPKeyHandle)
- DSAOpenSsl.DuplicateKeyHandle()
- ECDsaOpenSsl(IntPtr)
- ECDsaOpenSsl(SafeEvpPKeyHandle)
- ECDsaOpenSsl.DuplicateKeyHandle()
- ECDiffieHellmanOpenSsl(IntPtr)
- ECDiffieHellmanOpenSsl(SafeEvpPKeyHandle)
- ECDiffieHellmanOpenSsl.DuplicateKeyHandle()
- X509Certificate.Handle
Transformación del bloque final solo durante el proceso de escritura mediante CryptoStream.Dispose
El método CryptoStream.Dispose, que se usa para finalizar operaciones CryptoStream
, ya no intenta transformar el bloque final durante la lectura.
Descripción del cambio
En versiones anteriores de .NET, si un usuario realizaba una lectura incompleta al usar CryptoStream en el modo Read, el método Dispose podía producir una excepción (por ejemplo, al usar AES con espaciado interno). Se producía la excepción porque se intentaba transformar el bloque final, pero los datos estaban incompletos.
En .NET Core 3.0 y versiones posteriores, Dispose ya no intenta transformar el bloque final durante la lectura, lo que permite hacer lecturas incompletas.
Motivo del cambio
Este cambio permite las lecturas incompletas de la secuencia de cifrado cuando se cancela una operación de red, sin necesidad de capturar una excepción.
Versión introducida
3.0
Acción recomendada
La mayoría de las aplicaciones no se verán afectadas por este cambio.
Si su aplicación detectaba anteriormente una excepción en caso de una lectura incompleta, puede eliminar ese bloque catch
.
Si su aplicación usaba la transformación del bloque final en operaciones hash, puede que tenga que asegurarse de que se lee toda la secuencia antes de eliminar el bloque.
Categoría
Criptografía
API afectadas
Entity Framework Core
Cambios importantes de Entity Framework Core
Globalización
La configuración regional de “C” se asigna a la configuración regional invariable
.NET Core 2.2 y las versiones anteriores dependen del comportamiento predeterminado de ICU, el cual asigna la configuración regional de “C” a la configuración regional en_US_POSIX. La configuración regional en_US_POSIX tiene un comportamiento de intercalación no deseado, porque no admite comparaciones de cadenas que no distinguen mayúsculas de minúsculas. Algunas distribuciones de Linux establecían la configuración regional de “C” como la configuración regional predeterminada, por lo que los usuarios experimentaban un comportamiento inesperado.
Descripción del cambio
A partir de .NET Core 3.0, la asignación de la configuración regional de “C” ha cambiado para usar la configuración regional invariable en lugar de en_US_POSIX. La configuración regional de “C” con la asignación invariable también se aplica a Windows para mantener la coherencia.
La asignación de “C” a la referencia cultural en_US_POSIX causaba confusión entre los clientes porque en_US_POSIX no admite operaciones de ordenación y búsqueda de cadenas que no distinguen mayúsculas de minúsculas. Dado que la configuración regional de “C” se usa como configuración regional predeterminada en algunas de las distribuciones de Linux, los clientes experimentaron este comportamiento no deseado en estos sistemas operativos.
Versión introducida
3.0
Acción recomendada
Nada más aparte de conocer este cambio. Este cambio solo afecta a las aplicaciones que usan la asignación de configuración regional de “C”.
Categoría
Globalización
API afectadas
Este cambio afecta a todas las API de intercalación y de referencia cultural.
MSBuild
Cambio de nombre de archivo de manifiesto del recurso
A partir de .NET Core 3.0, en el caso predeterminado, MSBuild genera un nombre de archivo de manifiesto diferente para los archivos de recursos.
Versión introducida
3.0
Descripción del cambio
Antes de .NET Core 3.0, si no se especificaban los metadatos LogicalName
, ManifestResourceName
o DependentUpon
para un elemento de EmbeddedResource
del archivo del proyecto, MSBuild generaba un nombre de archivo de manifiesto con el patrón <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources
. Si RootNamespace
no está definido en el archivo del proyecto, se toma como valor predeterminado el nombre del proyecto. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx en el directorio raíz del proyecto era suproject.Form1.Resources.
A partir de .NET Core 3.0, si un archivo de recursos está ubicado conjuntamente con un archivo de código fuente del mismo nombre (por ejemplo, Form1.resx y Form1.cs), MSBuild usa la información de tipo del archivo de código fuente para generar el nombre del archivo de manifiesto con el patrón <Namespace>.<ClassName>.resources
. El espacio de nombres y el nombre de clase se extraen del primer tipo del archivo de código fuente ubicado conjuntamente. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx que se ubica conjuntamente con un archivo de código fuente denominado Form1.cs es myNameSpace.Form1.Resources. Lo más importante que hay que tener en cuenta es que la primera parte del nombre de archivo es diferente en versiones anteriores de .NET Core (myNameSpace en lugar de MyProject).
Nota
Si tiene los metadatos LogicalName
, ManifestResourceName
o DependentUpon
especificados en un elemento EmbeddedResource
del archivo del proyecto, este cambio no afecta a ese archivo de recursos.
Este cambio importante se presentó con la incorporación de la propiedad EmbeddedResourceUseDependentUponConvention
a los proyectos de .NET Core. De forma predeterminada, los archivos de recursos no se enumeran explícitamente en un archivo de proyecto de .NET Core, por lo que no tienen metadatos DependentUpon
para especificar cómo nombrar el archivo .resources generado. Cuando EmbeddedResourceUseDependentUponConvention
se establece en true
, que es el valor predeterminado, MSBuild busca un archivo de código fuente ubicado conjuntamente y extrae un espacio de nombres y un nombre de clase de ese archivo. Si establece EmbeddedResourceUseDependentUponConvention
en false
, MSBuild genera el nombre del manifiesto según el comportamiento anterior, que combina RootNamespace
y la ruta de acceso relativa del archivo.
Acción recomendada
En la mayoría de los casos, no se requiere ninguna acción por parte del desarrollador y la aplicación seguirá funcionando. Sin embargo, si este cambio invalida la aplicación, puede:
Cambiar el código para que espere el nuevo nombre de manifiesto.
Rechazar la nueva convención de nomenclatura mediante el establecimiento de
EmbeddedResourceUseDependentUponConvention
enfalse
en el archivo del proyecto.<PropertyGroup> <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention> </PropertyGroup>
Categoría
MSBuild
API afectadas
N/D
Redes
El valor predeterminado de HttpRequestMessage.Version ha cambiado a 1.1
El valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version ha cambiado de 2.0 a 1.1.
Versión introducida
3.0
Descripción del cambio
En las versiones 1.0 a 2.0 de .NET Core, el valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version es 1.1. A partir de la versión 2.1 de .NET Core, se ha cambiado a 2.1.
A partir de la versión 3.0 de .NET Core, el número de versión predeterminado devuelto por la propiedad System.Net.Http.HttpRequestMessage.Version es, una vez más, 1.1.
Acción recomendada
Actualice el código si depende de que la propiedad System.Net.Http.HttpRequestMessage.Version devuelva un valor predeterminado de 2.0.
Categoría
Redes