Eventos
Compilación de Intelligent Apps
17 mar, 21 - 21 mar, 10
Únase a la serie de reuniones para crear soluciones de inteligencia artificial escalables basadas en casos de uso reales con compañeros desarrolladores y expertos.
Regístrese ahoraCambios 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.
- 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 los miembros obsoletos y los modificadores de compatibilidad en ASP.NET Core 2.2.
3.0
Mejora de la superficie de API a lo largo del tiempo.
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.
ASP.NET Core
Los tipos y miembros siguientes se marcaron como obsoletos para ASP.NET Core 2.1 y 2.2:
Tipos
Microsoft.AspNetCore.Diagnostics.Views.WelcomePageMicrosoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValueMicrosoft.AspNetCore.DiagnosticsViewPage.Views.BaseViewMicrosoft.AspNetCore.DiagnosticsViewPage.Views.HelperResultMicrosoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21WrapperMicrosoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21WrapperMicrosoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProviderMicrosoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinderMicrosoft.AspNetCore.Routing.IRouteValuesAddressMetadataMicrosoft.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.OutputFormatterCanWriteContextMicrosoft.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.FormCollectionModelBinderMicrosoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinderMicrosoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinderMicrosoft.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.XmlDataContractSerializerInputFormatterMicrosoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatterMicrosoft.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.CookieDomainMicrosoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieNameMicrosoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePathMicrosoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSslMicrosoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQueryMicrosoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponsesMicrosoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieNameMicrosoft.AspNetCore.Mvc.CookieTempDataProviderOptions.DomainMicrosoft.AspNetCore.Mvc.CookieTempDataProviderOptions.PathMicrosoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributesMicrosoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormatMicrosoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypesMicrosoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFiltersMicrosoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresentMicrosoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodesMicrosoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicyMicrosoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumTypeMicrosoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttributeMicrosoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefixMicrosoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreasMicrosoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequestsMicrosoft.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)
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.
3.0
Las API afectadas se marcan con el modificador de acceso public y existen en los espacios de nombres *.Internal.
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.
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.
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.
C#
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.
C#
HttpContext.Request.EnableBuffering();
ASP.NET Core
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.InternalMicrosoft.AspNetCore.Builder.InternalMicrosoft.AspNetCore.DataProtection.Cng.InternalMicrosoft.AspNetCore.DataProtection.InternalMicrosoft.AspNetCore.Hosting.InternalMicrosoft.AspNetCore.Http.InternalMicrosoft.AspNetCore.Mvc.Core.InfrastructureMicrosoft.AspNetCore.Mvc.Core.InternalMicrosoft.AspNetCore.Mvc.Cors.InternalMicrosoft.AspNetCore.Mvc.DataAnnotations.InternalMicrosoft.AspNetCore.Mvc.Formatters.InternalMicrosoft.AspNetCore.Mvc.Formatters.Json.InternalMicrosoft.AspNetCore.Mvc.Formatters.Xml.InternalMicrosoft.AspNetCore.Mvc.InternalMicrosoft.AspNetCore.Mvc.ModelBinding.InternalMicrosoft.AspNetCore.Mvc.Razor.InternalMicrosoft.AspNetCore.Mvc.RazorPages.InternalMicrosoft.AspNetCore.Mvc.TagHelpers.InternalMicrosoft.AspNetCore.Mvc.ViewFeatures.InternalMicrosoft.AspNetCore.Rewrite.InternalMicrosoft.AspNetCore.Routing.InternalMicrosoft.AspNetCore.Server.Kestrel.Core.Adapter.InternalMicrosoft.AspNetCore.Server.Kestrel.Core.Internal.HttpMicrosoft.AspNetCore.Server.Kestrel.Core.Internal.InfrastructureMicrosoft.AspNetCore.Server.Kestrel.Https.Internal
Google está empezando a apagar el inicio de sesión de Google+ en las aplicaciones a partir del 28 de enero de 2019.
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.
Todas las versiones. Este cambio es externo a ASP.NET Core.
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.
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.
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:
C#
.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.
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.
C#
.AddOpenIdConnect("Google", o =>
{
o.ClientId = Configuration["Authentication:Google:ClientId"];
o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
o.Authority = "https://accounts.google.com";
o.ResponseType = OpenIdConnectResponseType.Code;
o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
La propiedad Authentication en desuso se ha quitado en HttpContext.
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.
3.0
Las API de ASP.NET Core 1.0 se han reemplazado por métodos de extensión en Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Consulte la guía de migración.
ASP.NET Core
- Microsoft.AspNetCore.Http.Authentication.AuthenticateInfo
- Microsoft.AspNetCore.Http.Authentication.AuthenticationManager
- Microsoft.AspNetCore.Http.Authentication.AuthenticationProperties
- Microsoft.AspNetCore.Http.Features.Authentication.AuthenticateContext
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeBehavior
- Microsoft.AspNetCore.Http.Features.Authentication.ChallengeContext
- Microsoft.AspNetCore.Http.Features.Authentication.DescribeSchemesContext
- Microsoft.AspNetCore.Http.Features.Authentication.IAuthenticationHandler
- Microsoft.AspNetCore.Http.Features.Authentication.IHttpAuthenticationFeature.Handler
- Microsoft.AspNetCore.Http.Features.Authentication.SignInContext
- Microsoft.AspNetCore.Http.Features.Authentication.SignOutContext
- Microsoft.AspNetCore.Http.HttpContext.Authentication
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.
3.0
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 deClaimActionse 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
JObjectporJsonElement. La propiedadUsery el métodoRunClaimActionsse han actualizado para que coincidan. - Success(JObject) ahora acepta un parámetro de tipo
JsonDocumenten lugar deJObject. La propiedadResponsese ha actualizado para que coincida.OAuthTokenResponseahora es descartable y se eliminará medianteOAuthHandler. Las implementaciones de OAuth derivadas que invalidanExchangeCodeAsyncno necesitan desecharJsonDocumentoOAuthTokenResponse. - UserInformationReceivedContext.User ha cambiado de
JObjectaJsonDocument. - TwitterCreatingTicketContext.User ha cambiado de
JObjectaJsonElement. - El último parámetro de TwitterHandler.CreateTicketAsync(ClaimsIdentity,AuthenticationProperties,AccessToken,JObject) se ha cambiado de
JObjectaJsonElement. El método de reemplazo es TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).
ASP.NET Core
- Microsoft.AspNetCore.Authentication.Facebook
- Microsoft.AspNetCore.Authentication.Google
- Microsoft.AspNetCore.Authentication.MicrosoftAccount
- Microsoft.AspNetCore.Authentication.OAuth
- Microsoft.AspNetCore.Authentication.OpenIdConnect
- Microsoft.AspNetCore.Authentication.Twitter
En ASP.NET Core 3.0, la firma de OAuthHandler.ExchangeCodeAsync cambió de:
C#
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }
A:
C#
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }
3.0
Las cadenas code y redirectUri se pasaron como argumentos independientes.
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.
Este cambio permite proporcionar parámetros adicionales de forma no interrumpida. No es necesario crear sobrecargas nuevas de ExchangeCodeAsync.
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.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
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.
3.0
Los métodos AddAuthorization existían en Microsoft.AspNetCore.Authorization.
Los métodos AddAuthorization existen en Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore es el nuevo nombre de los métodos antiguos.
AddAuthorization es un nombre de método más indicado para agregar todos los servicios comunes necesarios para la autorización.
Agregue una referencia a Microsoft.AspNetCore.Authorization.Policy o, en su lugar, use AddAuthorizationCore.
ASP.NET Core
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.
3.0
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.
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.
Se presentó una nueva estrategia de enrutamiento de puntos de conexión en ASP.NET Core 3.0.
Busque IAllowAnonymous en los metadatos del punto de conexión. Por ejemplo:
C#
var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}
Un ejemplo de esta técnica se encuentra en este método HasAllowAnonymous.
ASP.NET Core
None
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.
3.0
Las implementaciones de IAuthorizationPolicyProvider no requerían un método GetFallbackPolicyAsync.
Las implementaciones de IAuthorizationPolicyProvider requieren un método GetFallbackPolicyAsync.
Se necesitaba un nuevo método para que el nuevo AuthorizationMiddleware lo usara cuando no se especificara ninguna directiva.
Agregue el método GetFallbackPolicyAsync a las implementaciones de IAuthorizationPolicyProvider.
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
En la versión ASP.NET Core 3.0 se han quitado las API MemoryCacheOptions obsoletas.
Este cambio es una continuación de aspnet/Caching#221. Para obtener información, vea dotnet/extensions#1062.
3.0
La propiedad MemoryCacheOptions.CompactOnMemoryPressure estaba disponible.
Se ha quitado la propiedad MemoryCacheOptions.CompactOnMemoryPressure.
La compactación automática de la caché provocaba problemas. Para evitar un comportamiento inesperado, solo se debe compactar la caché cuando sea necesario.
Para compactar la caché, realice la conversión a un tipo heredado MemoryCache y llame a Compact cuando sea necesario.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
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.
3.0
El paquete Microsoft.Extensions.Caching.SqlServer usaba el paquete System.Data.SqlClient.
Microsoft.Extensions.Caching.SqlServer ahora usa el paquete Microsoft.Data.SqlClient.
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.
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.
ASP.NET Core
None
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.
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.
3.0
Estos tipos eran visibles públicamente, pero no eran compatibles.
Estos tipos ahora son internal.
El ámbito de internal refleja mejor la directiva no compatible.
Copiar los tipos que usa la aplicación o biblioteca.
ASP.NET Core
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponseMicrosoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRulesMicrosoft.AspNetCore.ResponseCaching.Internal.IResponseCacheMicrosoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntryMicrosoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProviderMicrosoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProviderMicrosoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCacheMicrosoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContextMicrosoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProviderMicrosoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider- Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.ResponseCachingMiddleware(RequestDelegate, IOptions<ResponseCachingOptions>, ILoggerFactory, IResponseCachingPolicyProvider, IResponseCache, IResponseCachingKeyProvider)
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.
3.0
El paquete hacía referencia al paquete NuGet WindowsAzure.Storage.
El paquete hace referencia al paquete NuGet Microsoft.Azure.Storage.Blob.
El paquete hace referencia al paquete NuGet Azure.Storage.Blob.
Este cambio permite a Azure.Extensions.AspNetCore.DataProtection.Blobs migrar a los paquetes de Azure Storage recomendados.
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:
diff
- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;
ASP.NET Core
None
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.
3.0
ANCM V1 está incluido en el conjunto de hospedaje de Windows.
ANCM V1 no está incluido en el conjunto de hospedaje de Windows.
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.
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" />.
ASP.NET Core
None
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.
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.
3.0
Este cambio es consecuencia del cambio de plataforma de la pila web a la biblioteca de host genéricos.
Inserte los servicios en la firma del método Startup.Configure. Por ejemplo:
C#
public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
ASP.NET Core
None
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.
3.0
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.
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.
Funcionalidad mejorada de ASP.NET Core 3.0.
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
UseHttpsRedirectionyUseHstsdel métodoStartup.Configuredel proyecto y vuelva a implementar la aplicación.En el archivo web.config, establezca la variable de entorno
ASPNETCORE_HTTPS_PORTen una cadena vacía. Este cambio puede producirse directamente en el servidor sin volver a implementar la aplicación. Por ejemplo:XML<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_PORTen 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_PORTcon un valor de cadena vacía. Este valor se establece de la misma manera que en el ejemplo deASPNETCORE_HTTPS_PORTanterior.
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.
ASP.NET Core
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.
3.0
Había dos tipos de IHostingEnvironment y IApplicationLifetime distintos de Microsoft.Extensions.Hosting y Microsoft.AspNetCore.Hosting.
Los tipos antiguos se han marcado como obsoletos y se han reemplazado por tipos nuevos.
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.
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.
ASP.NET Core
- Microsoft.AspNetCore.Hosting.EnvironmentName
- Microsoft.AspNetCore.Hosting.IApplicationLifetime
- Microsoft.AspNetCore.Hosting.IHostingEnvironment
- Microsoft.Extensions.Hosting.EnvironmentName
- Microsoft.Extensions.Hosting.IApplicationLifetime
- Microsoft.Extensions.Hosting.IHostingEnvironment
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.
3.0
WebHostBuilder proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.
WebHostBuilder ya no proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.
Este cambio se ha realizado para aumentar la naturaleza de pago por uso de ASP.NET Core.
Si el componente requiere ObjectPoolProvider, tendrá que agregarlo a las dependencias mediante IServiceCollection.
ASP.NET Core
None
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.
3.0
Las clases se pueden derivar de DefaultHttpContext.
Las clases se pueden derivar de DefaultHttpContext.
La extensibilidad se proporcionó inicialmente para permitir la agrupación de HttpContext, pero incorporaba una complejidad innecesaria e impedía otras optimizaciones.
Si usa Mock<DefaultHttpContext> en las pruebas unitarias, empiece a usar Mock<HttpContext> en su lugar.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
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.
3.0
Estos campos solían ser const.
Ahora estos campos son static readonly.
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.
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
caseen 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.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
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.
3.0
Había tres API asociadas al cuerpo de respuesta HTTP:
IHttpResponseFeature.BodyIHttpSendFileFeature.SendFileAsyncIHttpBufferingFeature.DisableResponseBuffering
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.
La motivación es combinar las API del cuerpo de la respuesta en una única interfaz de características nueva.
Use IHttpResponseBodyFeature donde anteriormente usaba IHttpResponseFeature.Body, IHttpSendFileFeature o IHttpBufferingFeature.
ASP.NET Core
- Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
- Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
- Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
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.
3.0
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.
Todas las API afectadas tienen como valor predeterminado SameSiteMode.None.
El valor predeterminado se ha cambiado para que SameSite fuera una característica de participación opcional.
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.
ASP.NET Core
A partir de ASP.NET Core 3.0, las operaciones de servidor sincrónicas están deshabilitadas de forma predeterminada.
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:
C#
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.
3.0
De manera predeterminada, solo se permitían HttpRequest.Body.Read, HttpResponse.Body.Write y Stream.Flush.
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.
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.
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.
C#
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
ASP.NET Core
A partir de ASP.NET Core 3.0, ya no existe la sobrecarga del método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework).
3.0
Este cambio fue el resultado de la adopción de la característica de recursos web estáticos.
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:
XML
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
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.
3.0
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); era la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);.
La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); es la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);.
Bootstrap 4 se lanzó durante el periodo de tiempo de ASP.NET Core 3.0.
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:
C#
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.ConfigureServicespara forzar el uso de Bootstrap 3. Por ejemplo:C#services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
ASP.NET Core
None
De forma predeterminada, SignInAsync produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated es false.
3.0
SignInAsync acepta entidades de seguridad e identidades, incluidas las identidades en las que IsAuthenticated es false.
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.
El comportamiento anterior era problemático porque, de forma predeterminada, [Authorize] / RequireAuthenticatedUser() rechazó estas entidades de seguridad.
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.
ASP.NET Core
None
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.
3.0
La motivación del cambio consistió en agregar compatibilidad con nuevos flujos de correo electrónico o de confirmación en Identity.
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.
ASP.NET Core
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.
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
IdentityUIFrameworkVersionen 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.
3.0
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.
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.
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.
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:
XML
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
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.
3.0
Los componentes de extensibilidad de Kestrel se creaban mediante el uso de IConnectionAdapter.
Los componentes de extensibilidad de Kestrel se crean como middleware.
Este cambio está pensado para proporcionar una arquitectura de extensibilidad más flexible.
Convierta las implementaciones de IConnectionAdapter para usar el nuevo patrón de middleware, tal como se muestra aquí.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Se ha quitado el ensamblado Microsoft.AspNetCore.Server.Kestrel.Https.
3.0
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].
- Las bibliotecas que hacen referencia a
Microsoft.AspNetCore.Server.Kestrel.Https2.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.
ASP.NET Core
None
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.
3.0
Los encabezados de finalizador de solicitud se agregarán a la recopilación HttpRequest.Headers.
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.
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.
Use los métodos de extensión relacionados con el finalizador en HttpRequest para tener acceso a los finalizadores.
ASP.NET Core
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.
3.0
- Las abstracciones relacionadas con el transporte estaban disponibles en la biblioteca de
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions. - La propiedad
ListenOptions.NoDelayestaba disponible.
- La interfaz de
IConnectionListenerse presentaba en la biblioteca deMicrosoft.AspNetCore.Connections.Abstractionspara exponer la funcionalidad más usada de la biblioteca de...Transport.Abstractions. NoDelayestá ahora disponible en opciones de transporte (LibuvTransportOptionsySocketTransportOptions).SchedulingModeya no está disponible.
ASP.NET Core 3.0 se ha desplazado de las API de "pubternal".
ASP.NET Core
None
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.
3.0
Los métodos no se marcaban como Obsolete.
Los métodos se marcan como Obsolete.
Las API representan un caso de uso que no se recomienda. Ha habido confusión sobre el diseño de la localización.
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.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizerMicrosoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
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.
3.0
El cambio se realiza para:
- Aplicar la coherencia con otras implementaciones de registrador como
ConsoleLogger. - Reducir la superficie de la API.
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.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
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.
3.0
Tenga en cuenta el siguiente controlador de ASP.NET Core MVC:
C#
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:
CSHTML
<a asp-controller="Product" asp-action="ListAsync">List</a>
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:
CSHTML
<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:
C#
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
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.
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.SuppressAsyncSuffixInActionNamesenfalseenStartup.ConfigureServicespara deshabilitar totalmente el cambio de nombre:
C#
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
None
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.
3.0 Preview 6
Una aplicación que usa una biblioteca basada en la versión 2.2 se compila correctamente.
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:
Output
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.
Los cambios en el nivel de plataforma de la composición de ASP.NET Core como se describe en aspnet/Announcements#325.
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
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.
3.0
El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation se usaba para compilar previamente las vistas de Razor de MVC.
El SDK de Razor es compatible de forma nativa con esta funcionalidad. El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation ya no está actualizado.
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.
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.
ASP.NET Core
None
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.
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.
3.0
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.
Todos estos tipos se actualizan para ser public en un espacio de nombres compatible o que se marquen como internal.
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.
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.
ASP.NET Core
Este cambio incluye tipos en los espacios de nombres siguientes:
Microsoft.AspNetCore.Mvc.Cors.InternalMicrosoft.AspNetCore.Mvc.DataAnnotations.InternalMicrosoft.AspNetCore.Mvc.Formatters.InternalMicrosoft.AspNetCore.Mvc.Formatters.Json.InternalMicrosoft.AspNetCore.Mvc.Formatters.Xml.InternalMicrosoft.AspNetCore.Mvc.InternalMicrosoft.AspNetCore.Mvc.ModelBinding.InternalMicrosoft.AspNetCore.Mvc.Razor.InternalMicrosoft.AspNetCore.Mvc.RazorPages.InternalMicrosoft.AspNetCore.Mvc.TagHelpers.InternalMicrosoft.AspNetCore.Mvc.ViewFeatures.Internal
A partir de ASP.NET Core 3.0, el paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim ya no está disponible.
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.
3.0
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.
Quite el uso de esta corrección de compatibilidad y migre directamente a la funcionalidad similar en ASP.NET Core.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
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.
3.0
Un motor de plantillas se puede crear y usar para analizar y generar código para archivos de Razor.
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.
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.
Use RazorProjectEngine en lugar de RazorTemplateEngine. Considere los ejemplos siguientes.
C#
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
});
C#
RazorProjectItem item = projectEngine.FileSystem.GetItem(
@"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);
// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();
ASP.NET Core
RazorTemplateEngineRazorTemplateEngineOptions
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.
3.0
La compilación en entorno de ejecución está disponible sin necesidad de paquetes adicionales.
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.FileProvidersahora esMvcRazorRuntimeCompilationOptions.FileProvidersRazorViewEngineOptions.AdditionalCompilationReferencesahora 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.
Este cambio era necesario para quitar la dependencia de marco compartido de ASP.NET Core en Roslyn.
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.ConfigureServicesdel proyecto para incluir una llamada aAddRazorRuntimeCompilation. Por ejemplo:C#services.AddMvc() .AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Se han quitado las API obsoletas para configurar las cookies de sesión. Para obtener más información, consulte aspnet/Announcements#257.
3.0
Este cambio exige coherencia entre las API para configurar las características que usan cookies.
Migre el uso de las API quitadas a sus reemplazos más recientes. Considere el ejemplo siguiente de Startup.ConfigureServices:
C#
public void ConfigureServices(ServiceCollection services)
{
services.AddSession(options =>
{
// Removed obsolete APIs
options.CookieName = "SessionCookie";
options.CookieDomain = "contoso.com";
options.CookiePath = "/";
options.CookieHttpOnly = true;
options.CookieSecure = CookieSecurePolicy.Always;
// new API
options.Cookie.Name = "SessionCookie";
options.Cookie.Domain = "contoso.com";
options.Cookie.Path = "/";
options.Cookie.HttpOnly = true;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});
}
ASP.NET Core
- Microsoft.AspNetCore.Builder.SessionOptions.CookieDomain
- Microsoft.AspNetCore.Builder.SessionOptions.CookieHttpOnly
- Microsoft.AspNetCore.Builder.SessionOptions.CookieName
- Microsoft.AspNetCore.Builder.SessionOptions.CookiePath
- Microsoft.AspNetCore.Builder.SessionOptions.CookieSecure
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.
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.
3.0
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)
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.
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.
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.Extensionsque 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.
ASP.NET Core
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.
3.0
Las aplicaciones podían usar el metapaquete Microsoft.AspNetCore.All para seleccionar como destino el marco compartido Microsoft.AspNetCore.All en .NET Core.
En .NET Core 3.0 no se incluye un marco compartido Microsoft.AspNetCore.All.
En el metapaquete Microsoft.AspNetCore.All se incluía un gran número de dependencias externas.
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.
ASP.NET Core
None
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.
3.0
HandshakeProtocol.SuccessHandshakeData era un campo public static ReadOnlyMemory<byte>.
HandshakeProtocol.SuccessHandshakeData se ha reemplazado por un método GetSuccessfulHandshake(IHubProtocol protocol)static que devuelve un objeto ReadOnlyMemory<byte> basado en el protocolo especificado.
Se han agregado campos adicionales a la respuesta del protocolo de enlace que no son constantes y cambian en función del protocolo seleccionado.
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.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
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.
3.0
Las API estaban disponibles.
Las API se quitan.
Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2.
No use estos métodos.
ASP.NET Core
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.
3.0
HubConnectionContext tiene dos constructores:
C#
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
Los dos constructores se han quitado y se han reemplazado por uno:
C#
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
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.
En lugar de usar el constructor siguiente:
C#
HubConnectionContext connectionContext = new HubConnectionContext(
connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Use el constructor siguiente:
C#
HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);
ASP.NET Core
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory)
- HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory, TimeSpan)
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.
3.0
El paquete de cliente se llamaba @aspnet/signalr.
El paquete de cliente se llama @microsoft/signalr.
El cambio de nombre clarifica que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.
Cambie al paquete @microsoft/signalr nuevo.
ASP.NET Core
None
Los métodos UseConnections y UseSignalR, y las clases ConnectionsRouteBuilder y HubRouteBuilder están marcados como obsoletos en ASP.NET Core 3.0.
3.0
El enrutamiento del centro de conectividad de SignalR se configuraba mediante UseSignalR o UseConnections.
La forma antigua de configurar el enrutamiento ha quedado obsoleta y se ha reemplazado por el enrutamiento del punto de conexión.
El middleware se está trasladando al sistema de enrutamiento nuevo de puntos de conexión. La forma anterior de agregar middleware está obsoleta.
Reemplace UseSignalR por UseEndpoints:
Código anterior:
C#
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Código nuevo:
C#
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
ASP.NET Core
- Microsoft.AspNetCore.Builder.ConnectionsAppBuilderExtensions.UseConnections(IApplicationBuilder, Action<ConnectionsRouteBuilder>)
- Microsoft.AspNetCore.Builder.SignalRAppBuilderExtensions.UseSignalR(IApplicationBuilder, Action<HubRouteBuilder>)
- Microsoft.AspNetCore.Http.Connections.ConnectionsRouteBuilder
- Microsoft.AspNetCore.SignalR.HubRouteBuilder
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.
3.0
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.
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.
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.
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.Extensionsno está obsoleta y seguirá siendo compatible.
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.
3.0
Antes, Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices creaban de forma automática un registrador de consola cuando el registro no estaba configurado.
Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.
Existe la necesidad de alinearse con el modo de implementar el registro en otros paquetes de ASP.NET Core.
Si se requiere el comportamiento anterior, agregue services.AddLogging(builder => builder.AddConsole()) al método Setup.ConfigureServices para configurar el registro de la consola.
ASP.NET Core
None
A partir de ASP.NET Core 3.0, .NET Framework es un marco de destino que no se admite.
.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.
3.0
Las aplicaciones ASP.NET Core se podían ejecutar en .NET Core o .NET Framework.
Las aplicaciones ASP.NET Core solo se pueden ejecutar en .NET Core.
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.
ASP.NET Core
None
- 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
Muchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.
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.
3.0
Ninguno. Este cambio debería hacer que la comprobación de la versión sea intuitiva en lugar de difícil de entender.
Bibliotecas de Core .NET
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.
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.
3.0
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.
Bibliotecas de Core .NET
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.
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.
3.0
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.
Bibliotecas de Core .NET
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.
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.
3.0
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
catchy colocar cualquier código necesario en una instrucciónIfque 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 dePositiveInfinityyNegativeInfinity.
Bibliotecas de Core .NET
La clase InvalidAsynchronousStateException se ha movido.
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.
3.0
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.
Bibliotecas de Core .NET
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.
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 UTF8Encodingcontinuará 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.
3.0
No se requiere ninguna acción por parte del desarrollador.
Bibliotecas de Core .NET
La clase TypeDescriptionProviderAttribute se ha movido.
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.
3.0
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.
Windows Forms
Ninguno.
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.
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.
3.0
Vuelva a empaquetar los archivos ZIP que presentan estos problemas.
Bibliotecas de Core .NET
- ZipArchiveEntry.Open()
- ZipFileExtensions.ExtractToDirectory
- ZipFileExtensions.ExtractToFile
- ZipFile.ExtractToDirectory
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.
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.
3.0
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.
Bibliotecas de Core .NET
- FieldInfo.SetValue(Object, Object)
- FieldInfo.SetValue(Object, Object, BindingFlags, Binder, CultureInfo)
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.
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.
3.0
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.
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.
C#
// Without a cast - causes CS1061.
match.Groups.Count(_ => true)
// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);
Bibliotecas de Core .NET
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
- 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
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.
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).
3.0
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.
Bash
$ 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
Criptografía
El algoritmo de cifrado simétrico predeterminado que usa EnvelopedCms ha cambiado de TripleDES a AES-256.
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.
C#
EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();
3.0
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:
C#
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();
Criptografía
El tamaño mínimo para generar nuevas claves RSA en Linux ha aumentado de 384 bits a 512 bits.
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.
3.0
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.
Criptografía
.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.
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.
3.0
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.
Criptografía
- 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
El método CryptoStream.Dispose, que se usa para finalizar operaciones CryptoStream, ya no intenta transformar el bloque final durante la lectura.
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.
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.
3.0
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.
Criptografía
Cambios importantes de Entity Framework Core
.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.
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.
3.0
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”.
Globalización
Este cambio afecta a todas las API de intercalación y de referencia cultural.
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.
3.0
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.
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
EmbeddedResourceUseDependentUponConventionenfalseen el archivo del proyecto.XML<PropertyGroup> <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention> </PropertyGroup>
MSBuild
N/D
El valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version ha cambiado de 2.0 a 1.1.
3.0
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.
Actualice el código si depende de que la propiedad System.Net.Http.HttpRequestMessage.Version devuelva un valor predeterminado de 2.0.
Redes
.NET Core 3.0 introdujo un cambio en la forma en que los controles del editor de texto crean un System.Windows.DataObject al arrastrar texto a otro control. El cambio deshabilitado autoconversion, lo que hace que la operación mantenga los datos como DataFormats.Text o DataFormats.UnicodeText en lugar de convertirlos en DataFormats.StringFormat.
.NET Core 3.0
Windows Presentation Foundation
El tipo de datos de al System.Windows.DataObject arrastrar texto desde un control de editor de texto era DataFormats.StringFormat.
El tipo de datos de al System.Windows.DataObject arrastrar texto desde un control de editor de texto es DataFormats.Text o DataFormats.UnicodeText.
Este es un cambio de funcionamiento.
El cambio fue intencionado.
Este cambio se revierte en .NET 7. Actualice a .NET 7 o posterior.
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
Comentarios de .NET
.NET es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Recursos adicionales
Cursos
Módulo
Protección de una aplicación web de .NET mediante el marco de Identity de ASP.NET Core - Training
Obtenga información sobre cómo agregar la autenticación y la autorización a una aplicación web de .NET mediante el marco de Identity de ASP.NET Core.